On 21/11/2018 14.10, Stefan Seyfried wrote:
Am 21.11.18 um 14:00 schrieb Carlos E. R.:
On 21/11/2018 13.55, Stefan Seyfried wrote:
Am 21.11.18 um 13:33 schrieb Carlos E. R.:
Well, no, it seems systemd-timesyncd uses much more memory.
You are looking at the wrong field.
Nobody realy cares how much virtual memory a process has mapped / reserved, but instead how big its resident set size is.
I looked at the resident size :-)
Ok, I was confused by the "top" line.
76 chronyd 3024 systemd-timesyn
But something is fishy there. If even my pretty minimal example program uses 772kB (with 708kB shared) according to top,then I cannot imagine how chrony will work with just 76kb.
I don't know. But I guess it is waiting for an event to happen, then load the rest of the code. The "S" means it sleeping IIRC, so it matches. Ie, the clock is OK, and it is waiting some timer till checking the clock on internet again. Maybe after some hours running the systemd implementation does the same, dunno.
You are also using different tools on both machines (see the different output columns), so the results might not be comparable.
No, the testing was done on the same laptop, minutes of difference (you can see the uptime on the first line), and both times I used "top -b n1 | less". Once as user and the other as root by mistake, though. Why do you think it was different machines? :-?
It would of course be highly embarassing if a stupid sntp client like systemd-timesyncd really uses more memory than a full fledged ntp server implementation like chronyd. Judging from other systemd experiences, I would not be surprised, though.
:-} -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)