-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ and Design Decisions
Straight answers to the "why not just..." questions this tool's design invites, and the reasoning behind each choice.
Because a mixed kit's individual modules were each validated by their vendor in isolation, not as a set. This project's own reference kit's box speed is "DDR4-3200 CL16" on every stick — but only two of the four actually carry an embedded profile proving that, and the other two have none at all (see XMP Profiles Explained). The printed number describes what one module can do on its own; it says nothing about what happens when four modules of differing internal characteristics share one channel.
Because "see what happens" either works, silently trains at a lower common denominator with no explanation of why, or fails to boot — none of which tell you what specifically is limiting you or by how much. This tool exists to answer that question in advance, from data, rather than by trial and error on hardware that may already be in a fragile state (the whole "accidentally booted" scenario this tool is written for).
Because BIOS doesn't support per-slot timings — one value gets applied system-wide. A per-module timing table alone would leave you to do the max-across-modules math yourself, by hand, across 15 parameters and however many candidate frequencies you're considering. That's exactly the error-prone step this tool automates (see Worst Case Methodology for the one place doing this naively actually produced a wrong answer during development).
The decoder does bit-level struct unpacking — nibble-packed 12-bit
fields, signed fine-timebase corrections, 16-bit little-endian pairs —
plus floating-point nanosecond arithmetic with careful rounding, then a
CRC-16 bit-loop. Bash's arithmetic handles the bitwise part fine, but has
no native floating point; every nanosecond computation would have to
route through awk or bc subprocesses instead, which is materially
harder to review line-by-line for correctness than direct Python. Given
the entire point of publishing this tool is that someone else can audit
the numbers, that outweighed the (real, but small) cost of a Python
interpreter start. In practice it isn't even an extra dependency: the
tool uses only the standard library, and python3 ships by default on
essentially every desktop Linux distribution.
Two reasons. First, there's no portable, standard way to write BIOS settings from Linux userspace across arbitrary motherboards — anything attempting it would necessarily be board-specific, fragile, and far riskier than a tool that only reads and prints. Second, and more importantly: the entire value of this tool is that its read path can be byte-verified, CRC-checked, and unit-tested against known-good fixtures. A write path touching BIOS/UEFI configuration would carry a categorically different risk profile (a bad write can brick a boot, not just print a wrong number), and this project's whole design philosophy is built around "never confidently do something we can't verify."
Because the scenario this tool is written for — a mixed kit that only
boots marginally, or not at all in some configurations — is precisely
where you may not be able to read every module's SPD live in one boot.
Being able to cat .../eeprom > stick.bin one module at a time (in this
machine across reboots, or in a different machine entirely) and combine
the dumps afterward is the difference between this tool being useful in
exactly the situation it's named for, or only useful once the hard part
is already solved.
Because the environment this tool is most likely to actually be run in —
a system that just barely booted, being diagnosed from whatever console
is available — may be a serial console, VGA text mode, or a minimal
rescue shell with no guaranteed Unicode font support and no guaranteed
terminal width beyond the historical 80-column default. Unicode
box-drawing characters (┌─┐) look nicer in a modern terminal emulator
but can render as garbage glyphs in exactly the constrained environment
where this tool's target user is most likely to need it.
Because those are the #1 and #2 reasons a mixed kit fails to POST at all, as opposed to merely underperforming — see Module Type and ECC Compatibility. A tool that computes a beautiful, precise timing table is not very useful to someone whose actual problem is an architectural incompatibility no timing setting can fix.
Because they are, and saying so plainly is cheaper and more honest than letting a reader assume every number in the tool's output carries the same certainty. See Command Rate and tCWL for exactly which values these are and where each estimate comes from.
Because whether two specific slots share a memory channel is a motherboard trace-layout fact that SPD — a per-module EEPROM — has no way to know. Guessing wrong here would produce a table that looks authoritative but silently encodes a false assumption; not guessing at all is the more honest failure mode.