On 2/25/2016 10:29 PM, Weber wrote: > Thanks for the link. I'm not surprised that someone else already had the > idea. I was poking around and see that 1588 does something similar with > a "follow up" packet. >
I should have mentioned that this checksum trailer extension field is needed to get the idea to work for NTP. Unfortunately you can't have security or a MAC to do this as it needs to make changes to the timestamps and then add the extension field to fix the UDP checksum. Tal can say more. Danny > > On 2/25/2016 7:09 PM, Danny Mayer wrote: >> Already thought of so it's a good idea! See >> https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/ for >> details. >> >> Danny >> >> On 2/25/2016 4:52 PM, Weber wrote: >>> This may or may not be worthwhile, but I thought I'd throw it out there >>> and see what happens: >>> >>> Recent work testing some microsecond-accurate NTP servers lead me to an >>> idea that could improve accuracy of measurements made by ntpd. These NTP >>> servers have hardware timestamps on receive but that's not possible on >>> transmit w/o a custom NIC. I've seen this issue discussed before. >>> >>> The next best thing is to generate the transmit timestamp based on a >>> guess as to how long it takes the NIC to get on the wire and send the >>> packet. That works pretty well as long as there's no other network >>> traffic. In this situation, it is possible to make use of microsecond >>> accuracy in an NTP server. >>> >>> Now, add some typical network traffic and the time it takes the NIC to >>> get on the wire becomes unpredictable to the tune of 200us or more (for >>> 100 base-T Ethernet). The server's microsecond accuracy is largely lost >>> in the noise. >>> >>> The NIC generates an interrupt after the packet is sent which can result >>> in a fairly accurate trailing hardstamp. The problem is...the packet is >>> already gone and has the wrong transmit timestamp. >>> >>> Here's my idea: >>> >>> What if the poll response packet contained a flag or indication of some >>> sort which means "this is an approximate transmit timestamp". That >>> packet would then be immediately followed by a second response packet >>> with a more accurate transmit time. The second packet could be otherwise >>> identical to the first, or it could be a new flavor of packet that >>> contained only the transmit time (that would save on network bandwidth). >>> >>> The ntpd process would need to use the receive time of the first packet >>> (the one with an approximate tx timestamp) and merge in the following >>> accurate tx timestamp before performing the normal processing associated >>> with a poll response. >>> >>> Here are the pros and cons I can think of: >>> >>> Pros >>> >>> * Possible accuracy improvement of 1-2 orders of magnitude. I know ntpd >>> already does some work to try and filter out network delay variation so >>> the improvement might not be a full 2 orders of magnitude. >>> * Could potentially be made compatible backwards compatible with ntp 3/4 >>> protocols >>> >>> Cons >>> >>> * Increased network traffic >>> * Improvement to that level of accuracy might not be of interest to >>> anyone >>> * Could be a fair bit of work for at least a couple of folks >>> * I may have (or probably) missed some stuff regarding network behavior >>> that would reduce the level of improvement that could be realized. >>> * Perhaps this is less of an issue on G-bit Ethernet? >>> >>> Wondering if anyone thinks this idea is worth pursuing further...? >> >> > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
