GC timing

[Hal Murray]

>> What is the API for recvfrom()?  Do you pass in a buffer, like in C, or 
does
>> it return a newly allocated buffer?
> You pass in a buffer.  In theory we could maintain a buffer ring.  I'd want
> to see actual benchmarks showing frequent GCs before I'd believe it was
> necessary, though.

If you pass in a buffer, there is no reason to allocate anything in the case 
of a server processing a request so this whole discussion is a wild goose 
chase.


> At just 100s of packets per second I don't think there's any real problem
> with dynamic allocation.  Taking 96 byters as a typical query length (that
> includes auth and digest) let's round up to 1024 to account for allocation
> overhead and to make the calculation convenient. 

> A memory gigabyte is 2^20 of these packets.  That's 1048576 seconds of
> traffic, or 291 hours, or 12 days and change.  Even if your system has just a
> GiB of headroom, you're only going to trigger a GC due to queries about that
> often. I don't think we get to numbers that even approach being worrying
> until two magnitudes up from here. 

Two orders of magnitude is 10K packets/second.  That's in the interesting 
range.  Our current code can do 400K non-auth packets/second.  That's only 40% 
of wire speed on a gigabit link.  NTS is 90K packets/sec, 25% of wire speed.

Memory speeds are ballpark of 20 GB/sec.  So if you have a GB of headroom, it 
will take at least 50 ms just to scan that.

NIST servers are running 10E10 packets/day.  That's averaging 115K 
packets/second.

https://tf.nist.gov/general/pdf/2818.pdf


-- 
These are my opinions.  I hate spam.