>> 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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
