Gary said: >James Browning via devel <devel@ntpsec.org> 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 1000000... 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, 1000000 samples. ns hits 10 6646 11 124028 12 410522 13 229036 14 177996 15 48724 16 259 17 535 18 1430 19 585 20 70 21 24 22 14 23 13 24 10 59 samples were bigger than 24. Histogram: CLOCK_REALTIME, 250 ns per bucket, 1000000 samples. ns hits 0 999949 2250 2 3250 1 3500 3 3750 3 4000 1 8250 1 8500 1 8750 20 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
