Hal Murray <halmur...@sonic.net>: > > >> That doesn't make sense. Where does your "one second apart" come from? > Why > >> is "currently has 2 threads" interesting? > > When do we poll at a less than one-secpmd interval? Most allocatopmns wo;l; > > ber associated with making a packet fra,e for he send, thn dealing with a > > response that comes bacl less than 100ms later. > > I was thinking of the server side. Pool servers can easily get 100s of > packets/second. I assume that means we have to write the server side so that > it doesn't do any allocations.
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. > 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. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel