[Transmit path] > No, I'd much rather put in a GC lockout on the critical region than > complicate the protocol.
That works if the environment has a GC lockout. Is that a column on your features list? > ntpd spends enough time in I/O waits that I do not think latency spikes will > otherwise induce any problems above measurement noise. I don't think the I/O waits are important. We need to work correctly when the server is overloaded. The key idea is that the server contributes 2 time stamps, the difference is how long the packet spent on the server, either waiting to get processed and/or actually getting processed say because the crypto takes a lot of CPU cycles. We should measure the time from grabbing the time stamp to sending the packet. That might include some crypto. We might get better results by adjusting the time stamp to compensate for that. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
