Pre-launch: author identity, current technical sources, and platform-specific memory support remain unverified.

Manual 04 / worked scenario

Size Memory Around the Working Set

Capacity, channel population, module count, and spare slots answer different questions. Keep them separate.

Commercial relationship and funding details are not yet established; this pre-launch publication accepts no inquiries or placements.

Memory planning goes wrong when four questions collapse into one. Total capacity asks whether active data fits. Channel population concerns the platform’s data paths. Module count affects electrical loading and future expansion. Spare slots preserve an option, but only if a future compatible population is realistic.

Key takeaways

  • Measure the busiest ordinary session, not an empty desktop.
  • Add growth and uncertainty as labelled amounts.
  • Follow the board and processor documentation for slot order and supported populations.
  • An empty slot is useful only when the planned upgrade remains compatible.

Start with a timeline

Record memory use after the workload has settled. Include the operating environment, background services, active documents, caches, virtual machines, browser sessions, and the heaviest concurrent task that actually occurs. A single application’s stated requirement is not the system working set.

Watch for storage paging or compression as well as the headline used-memory figure. Once the system starts moving inactive pages or compressing aggressively, a task may still finish while interaction becomes uneven. That behaviour is evidence. Capture several ordinary days rather than one theatrical stress run.

Original asset: one busy workday

Illustrative concurrent memory ledger
Block at 14:30 Observed or estimated use Confidence
Operating environment and background 5.2 GB Observed range
Primary editor and project 8.6 GB Observed peak
Local virtual environment 6.0 GB Assigned ceiling
Browser and reference tools 3.7 GB Observed range
Short export overlap 4.1 GB Estimated
Concurrent total 27.6 GB Mixed evidence

The base total is 5.2 + 8.6 + 6.0 + 3.7 + 4.1 = 27.6 GB. Add 2.4 GB because two background services are expected during ownership, then apply a 15% uncertainty margin: (27.6 + 2.4) × 1.15 = 34.5 GB. That rules out a 32 GB target for this scenario. It does not prove one exact capacity is correct.

A 48 GB or 64 GB class may clear the estimate, depending on what the platform supports and how modules are sold locally. The larger option buys 29.5 GB above the planning line; the smaller buys 13.5 GB. Ask whether the extra margin has a named future workload. If not, that money may remove a stronger constraint elsewhere in the desktop allocation framework.

Channel population is not capacity

Populate the preferred slots exactly as the platform manual specifies. A platform may expose two memory channels while offering more physical slots. Filling every slot does not create more channels, and a large single module may leave one channel underused. Neither statement confirms the behaviour of a real board; topology and support vary.

More modules can increase electrical load on the memory controller and may reduce supported data rates. Mixed kits or later additions may share labels yet differ internally. Treat future expansion as a compatibility event, not a guaranteed snap-in upgrade. Record module specifications and the documented population rules when the first set is chosen.

Capacity pressure also has a time shape. A five-minute export overlap that reaches 34.5 GB is not equivalent to an eight-hour session at that level, yet both can interrupt work if paging begins. Mark duration beside each peak. If the rare spike can be scheduled after closing another workload, process change may be cheaper than capacity. If it arrives unpredictably during interactive work, margin carries more value.

Choose a population with an exit route

For the 34.5 GB planning line, compare two shapes: two larger modules leaving two slots open, or four smaller modules filling the board. The first preserves physical slots and may simplify electrical loading; the second might fit availability or cost. The correct shape depends on documented support, cooler clearance, and the realistic upgrade path.

Do not pay for an empty slot that cannot solve the forecast. If the next upgrade would require replacing all modules to retain a supported population, write that replacement cost now. The slot is physically empty, but the upgrade path is not additive.

Honest limitation: this scenario cannot establish supported speed, timing, voltage, rank layout, error handling, training behaviour, or firmware compatibility for a real platform. Specification sheets and calculations are educational; actual modules and boards vary.

Use the compatibility stop-check for slot order, cooler interference, and firmware assumptions. If memory growth is driven by larger local datasets, connect it to the storage and retention estimate rather than treating the two budgets separately. The proposed editorial standards explain why estimates keep their confidence labels.