Dashboard: System Status Memory % counts buffer/cache as used (shows 79%, true 63%)

[kateatlinksys]

Reproduce steps:

1. Login to Linksys Now.
2. Go to Dashboard > System Status > Monitor tab, read the Memory used MB / %.
3. Compare against /proc/meminfo on the device.

Actual result:
Memory reads 327 MB / 413 MB used → 79%. The 327 MB equals exactly MemTotal − MemFree (422528 − 88248 = 334280 kB ≈ 326 MB), i.e. it counts the ~105 MB of buffer/cache as "used". The Trends tab shows the same wrong figure (Memory line Avg 79%). (Distribution and Correlation tabs don't plot Memory.)

Expected result:
Memory should track (MemTotal − MemAvailable) / MemTotal = 262 MB → 63% — the same figure free/htop report — since buffer/cache is reclaimable, not truly used. GUI is inflating usage by ~16 percentage points.

Env.: M60DU-EU / Pinnacle 2.0 FW 1.2.2.26062820 / Linksys Now 2.5.0.700525

Log: GUI_systemstatus_error_0716.txt

/proc/meminfo — two reads on the same boot, 10 min apart, both give 79%:

Read	MemTotal	MemFree	MemAvailable	Total−Free (GUI)	Total−Available (correct)
1 (uptime 27m)	422528 kB	88248 kB	154628 kB	326 MB → 79%	262 MB → 63%
2 (uptime 38m)	422528 kB	86908 kB	153640 kB	328 MB → 79%	263 MB → 64%

Screenshot

[AustinChangLinksys]

🔍 Automated investigation (preliminary triage)

Line: 2.x / USP (TR-369)

Root cause:

• Trigger (data gap): The device only exposes Device.DeviceInfo.MemoryStatus.Total and Device.DeviceInfo.MemoryStatus.Free over USP/TR-181. MemoryStatus.Free maps to /proc/meminfo MemFree, NOT MemAvailable. There is no reclaimable/available-memory parameter in the queried tree, so the UI structurally cannot obtain the ~105 MB of reclaimable buffer/cache.
• UI defect: The dashboard computes used = Total − Free and presents it as "used %". By the Linux free/htop convention this overcounts, because reclaimable buffer/cache is treated as "used".

Evidence (from attached GUI_systemstatus_error_0716.txt):

1. The USP GET request only asks for Total + Free (no Available parameter exists in the request):

#1 GET →
  [ ... "Device.DeviceInfo.MemoryStatus.Total",
        "Device.DeviceInfo.MemoryStatus.Free", ... ]

2. The device response confirms Free == MemFree (matches the reporter's /proc/meminfo MemFree 88248 kB), not MemAvailable:

#1 GET ← (2228ms)
  { "Device.DeviceInfo.MemoryStatus.Total": "422528",
    "Device.DeviceInfo.MemoryStatus.Free": "88408", ... }

(This GET repeats 82 times over the session; Total is always 422528, Free hovers ~88xxx — the poll data is stable, so the discrepancy is purely a formula/data-source issue, not a transient error.)

3. The UI computation, lib/page/_shared/models/system_info_ui_model.dart:

int get memoryUsedKb => (totalMemory - freeMemory).clamp(0, totalMemory);
int get memoryPercent =>
    totalMemory > 0 ? (memoryUsedKb / totalMemory * 100).round() : 0;

So (422528 − 88408) / 422528 ≈ 79% — exactly the reported figure. To show ~63% the UI would need MemAvailable (154628 kB), which is not present in the TR-181 MemoryStatus tree the codegen queries.

Confidence: Medium — the formula/data-source root cause is confirmed in both the log and the code, but the correct fix is cross-layer: it depends on whether the firmware can expose MemAvailable (or Cached/Buffers/reclaimable) via TR-181 MemoryStatus. If it cannot, the UI can only relabel or approximate. Needs firmware-team confirmation on data-model availability.

---

Auto-generated triage by Austin's tooling, pending Austin's review. Not a fix commitment.