Gary said:
>James Browning via devel wrote:
>> It would appear there is a way to turn off GC under runtime/,
> How? Link?
https://pkg.go.dev/runtime/debug#SetGCPercent
It's not clear to me how to take advantage of that. You still have to turn it
on occasionally or your world will fill up with garbage.
I poked around a bit. I'm pretty sure that we can write a server that doesn't
generate any garbage when processing a normal client request. The APIs for
recvmsg/sendto don't allocate anything. If we split ntpd into client side and
server side, I think we can write the server code such that the GC never runs.
Or maybe never needs to run and we have to explicitly tell it not to bother
trying.
Logging stuff would probably generate garbage. The server side doesn't need
to do that.
Gary said:
> Hal said:
>> There are lots of ways to inject timing bumps before we get to
>> garbage collecting. cache, scheduler, interrupts, CPU speed, ...
> Any that work?
What do you mean by "work"?
I don't know how to avoid any of the above. Note that there are 2 levels of
interrupt. The firmware steals a few cycles every now and then for things
that it doesn't trust the OS to get right. The main example is checking the
temperature and turning the CPU clock down if things are too hot.
Then there are interrupts that get passed to the OS. You can fight that
somewhat by manually assigning work to CPUs. But the scheduler still has to
run occasionally and if your workload doesn't use the whole CPU, that CPU is
likely to slow down when you are waiting for work.
I did a bit of hacking with attic/clocks.c
On this machine, the average time to read the clock is 13 ns.
Within a burst of a million samples, there is usually a few in the 10-15
microsecond range.
Occasinally, there is something in the 60-70 microseconds range. They are
rare enough that it's easy to miss one in a million sample pairs of reading
the clock.
Slowest from each batch of 100...
11331 18540 11282 11341 11306 11311 11307 11316 11307 11322
16188 14920 11322 11293 13337 13025 32270 11352 21706 11313
32463 22764 11812 11308 11319 60664 11301 14530 20428 11319
14973 11308 11287 14181 13127 11320 11298 11312 12053 15081
17762 17329 11279 12430 11299 16946 14470 14745 13816 11323
Slowest was 60664
Histogram: CLOCK_REALTIME, 1 ns per bucket, 100 samples.
ns hits
10 6646
11124028
12410522
13229036
14177996
15 48724
16 259
17 535
18 1430
19 585
2070
2124
2214
2313
2410
59 samples were bigger than 24.
Histogram: CLOCK_REALTIME, 250 ns per bucket, 100 samples.
ns hits
049
2250 2
3250 1
3500 3
3750 3
4000 1
8250 1
8500 1
875020
9000 1
9250 1
10250 1
11000 9
11250 4
13250 1
2 samples were bigger than 13250.
Slowest was 14424.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
https://lists.ntpsec.org/mailman/listinfo/devel
