Go GC

[Hal Murray]

Gary said:
>James Browning via devel <devel at 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.