RamSleuth — RAM telemetry + memory benchmark for Linux

A user testing RamSleuth, a Linux RAM telemetry and memory benchmark tool, found that the utility misreports memory channel mode and doubles MCLK to report 3600MT/s DDR4 as 7200MT/s. The user traced the channel-mode bug with DeepSeek V4.1 Flash to a collector that reads the DMI entry folder as a file, errors, and swallows the failure via a continue-on-error argument, reporting 0 and never triggering the override guard; a patched version now reports channel_mode: Some(DualSymmetric) and channel_trust: Some(Override) with dimm_count: 2. The user also reported UI bugs, including graphs and probe reports that fail to redraw the terminal region below them and a burn-in test elapsed counter that does not tick up.

Checking it out now: It’s now picking up the vcore reading Still thinks it’s single-channel though, digging into why now with DeepSeek. In the meantime, a couple UI notes: The graph function doesn’t re-draw the rest of the terminal window section below it, so those values just sit there, makes it hard to read. The probe report option also does this, only over-writing the blue border and the consent buttons, so it’s nigh impossible to read: On the burn-in test, the “ : elapsed” counter doesn’t tick up. I think that’s all the UI bugs I can find so far. I can’t upload .md files, so here’s a paste of the probe report in a hide section, so it won’t make everyone scroll a million years . probe-report Alright, DS figured it out. The collector looks at the dmi entry folder as a file, errors, the continue on error arg swallows it, so it reports 0. That way it never triggers the override guard. The test creates the mock entry as a file, so it passes. The parser is reading the wrong values on this system too. Here’s DS’s summary: DeepSeek V4.1 Flash’s Report The patched version reads correctly: channel mode: Some DualSymmetric channel trust: Some Override channel annotation: " Override: MCHBAR decoded Single-Channel dimm count: 2 }" And here’s the raw hex dumps and dmidecode: 17-0/raw hex dump And the probe-report after the patch: probe-report-2 Another small catch while reading the probe-report again, it doubles what it reads as MCLK and reports that as MT/s. So it thinks my 3600 “MHz” 1800Mhz, 3600MT/s DDR4 is running at 7200MT/s.