1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
# perf
The figures the conky dashboard used to show, as a drawer page of cards, one
per row; the page scrolls. CPU load with a bar per core, the CPU model and
RAM; every temperature as a tile; the Arc B580's VRAM and fan (no
utilisation, xe exposes none); download and upload over the last minute, the
LAN address and the public IP; the five mounts with their usage; and
`~/.cache` with its five largest children. `Perf.qml` reads them; `Perf.js`
holds the parsing, tested by `node desktop/modules/perf/test_perf.js`.
The tile shows CPU and RAM, and a dot for the worst of these, yellow or red:
| Input | Yellow | Red |
| --- | --- | --- |
| each temperature | its warn | its crit |
| RAM | 85% | 95% |
| each disk | 90% | 95% |
| public IP | | differs from the pinned one |
CPU load is left out, since spikes would flicker it. There is no hysteresis,
so a sensor sitting on its threshold can toggle the dot. The pin beside the
public IP stores the address shown as `perf.pinnedIp` in
`$XDG_STATE_HOME/keystone/desktop.json`; the check exists because the VPN
into the LAN depends on the ISP's fixed address. The fetch is
`curl -4 https://ipinfo.io/ip` every 30 minutes from the last attempt, into
`~/.cache/udt/pubip.txt`, the file conky's sampler used. A failed fetch is
never a mismatch: the old value goes stale after 4 hours and shows as a dash.
Everything is sampled always, including per-core load, the network rate,
VRAM (a scan of every fdinfo, ~14ms every 2s) and the fan, so the page opens
on the last minute of network history instead of an empty graph. The mount list, `br0`, the GPU name and the 12 GiB VRAM
size are constants in `Perf.qml`.
The CPU card ends with the five heaviest processes, by CPU or by RAM (a
toggle in the card, not saved). They come from one `top -b -d2` that runs only
while the page is open. A frame is published once top's output goes quiet,
and the first is skipped because top computes it over each process's whole
life, so rows appear about 2s after opening. CPU is per core, as top shows it, so a
busy process can exceed 100%.
The cache card runs `du -B1 -d1` once each time the page opens, 28ms over
2 GiB, instead of reading conky's 15-minute `cachesize.txt`. The largest
child is yellow, red when it holds over half the total, as conky had it.
|
