Re: [time-nuts] Network Time Puzzle
I would broaden your experiment to try many different remote servers. Maybe using different chunks of the global NTP pool (https://www.ntppool.org/en/use.html) It could be traffic shaping on your ISP , an ISP in the middle, or one on the remote end. It could be traffic prioritization from one of the above that lowers priority for ports > 1024 It could be weirdness from the network stack on your Windows XP clients. You might considering using something more modern. K5ROE Mike On 5/26/19 4:26 AM, Peter Martinez via time-nuts wrote: Greetings, Time Nuts, from a new member. I have two old Windows XP laptops on which I can lock the timing to GPS, which means I can read the time at which things happen to a few microseconds. I thought I would modify some of my old NTP software, both client and server, to make use of this and see how well the ntp system performs. It's all working fine, but in the course of trying to decide what to set for the "local port address", I discovered a strange effect. If I set the local port address of my ntp client to one value (somewhere between 49152 and 65535 for example), then query an ntp server on the internet, then change the local port to another value and do it again, the Time Offset and Round Trip Delay readings come back different. Change the port back and the offset/delay values go back to the original. Same on the other PC. But ONLY on some distant servers. Most of them don't show the effect. I have seen jumps of about 6.2msec in delay and 3.1msec in offset, but the offset might be positive or negative. This leads me to think that this wierd effect is a propagation delay occuring in one of the two paths, either the path from me to the server or from the server back to me. On some servers I have seen the delay jump by 12.4msec with no jump in the offset. This must be a 6.2 msec. delay in BOTH propagation delays. In this case, four different values of local port address can give rise to 4 different delay/offset combinations. A scatter plot of delay versus offset, with random port address, shows four dots in a diamond shape. Different delay values give different-sized diamonds. Routes with more than one such effect show even prettier patterns of superimposed diamonds. The effect is stable over time, at least for the length of time (weeks) I have been studying it. If this is real (and I am fairly sure it's not a bug at my end or at the servers), then it will impact on the accuracy which can be achieved with NTP. I ask myself "Why does the network do this?". Is there a valid reason for it, or is it a side-effect of something else? Has anyone else seen this effect? Is there anyone out there reading this who could modify an NTP client program so that the loal port address can be changed manually, and see if this is a widespread feature of the internet. If this effect didn't occur, NTP could be a lot better than it is now. Regards Peter Martinez G3PLX ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Network Time Puzzle
Steve: Many thanks for that link to your paper on NTP http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf I read the entire paper, not just figs 7 and 8, and it explains everything. I was beginning to doubt my own sanity because several authorities that I had consulted told me quite categorically that The Network would have no business looking at source port addresses within packets, and would have no reason to treat packets from some port addresses differently from packets from other port addresses. I had in particular consulted a named person at one organisation which operates ntp servers in Colorado and Maryland. I had spotted this effect first on ALL their servers and had not, at that time, seen it on any others, so I had good reason to ask them whether there could be something at their end which might be responsible. "No there isn't - our servers are OK" I was told, but nothing more. I could still make a valid point which could be of concern to writers of ntp client software. If a client used a fixed, constant, local port address, we can assume that routers in the internet (or at least those which do implement this load-spreading technique) would route all ntp traffic - from client to server and back - via the same path each time, so there would be no spread in offset times seen by the client. There might, of course, be some asymetry in the paths. By contrast, a client that used a different local port address for each query might see a different route each time and there would be a spread in offset times of the same order as the spread in propagation times of the routes in use. For example, I have seen, when querying servers in Colorado and Maryland from here (the UK), standard deviations in the derived offset, of about 100usec when I use a fixed local port address, and about 3 msec when I use a port address which either increments by 1 for each query or is chosen as a random number between 49152 and 65535 each time. I am not sure of the statistics, but I am not sure that randomizing the local port address has any useful advantages. Just for amusement I implemented a process whereby my client program starts with a randomized port address, but keeps a record of the port number of the query which gives the lowest round-trip-time during this "search" phase, then switches to this fixed port address thereafter. The offset thus achieved was always "better" than with any other random choice of fixed port address. Maybe this is going too far! Steve: Thanks again. VERY useful. Peter ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Network Time Puzzle
See figures 7 & 8 in http://leapsecond.com/ntp/NTP_Paper_Sommars_PTTI2017.pdf When a router forwards an NTP packet multiple potential egress links may have equal cost. In order to distribute the traffic across the egress links the router can use the IP addresses and UDP source/destination port numbers to select a link. Doing this reduces the likelihood of out-of-sequence packets. Instead of having N x 1 Gbps links between two adjacent routers it is preferable to have a single N Gbps link. The latter may not be available or cost effective. Similar behavior can be found at network layer 2 for link aggregation groups, see https://en.wikipedia.org/wiki/Link_aggregation . Steve Sommars On Sun, May 26, 2019 at 7:16 AM Peter Martinez via time-nuts < time-nuts@lists.febo.com> wrote: > Greetings, Time Nuts, from a new member. > > I have two old Windows XP laptops on which I can lock the timing to GPS, > which means I can read the time at which things happen to a few > microseconds. I thought I would modify some of my old NTP software, both > client and server, to make use of this and see how well the ntp system > performs. > > It's all working fine, but in the course of trying to decide what to set > for > the "local port address", I discovered a strange effect. If I set the > local > port address of my ntp client to one value (somewhere between 49152 and > 65535 for example), then query an ntp server on the internet, then change > the local port to another value and do it again, the Time Offset and Round > Trip Delay readings come back different. Change the port back and the > offset/delay values go back to the original. Same on the other PC. But > ONLY on some distant servers. Most of them don't show the effect. > > I have seen jumps of about 6.2msec in delay and 3.1msec in offset, but the > offset might be positive or negative. This leads me to think that this > wierd effect is a propagation delay occuring in one of the two paths, > either > the path from me to the server or from the server back to me. On some > servers I have seen the delay jump by 12.4msec with no jump in the offset. > This must be a 6.2 msec. delay in BOTH propagation delays. In this case, > four different values of local port address can give rise to 4 different > delay/offset combinations. A scatter plot of delay versus offset, with > random port address, shows four dots in a diamond shape. Different delay > values give different-sized diamonds. Routes with more than one such > effect > show even prettier patterns of superimposed diamonds. The effect is > stable > over time, at least for the length of time (weeks) I have been studying it. > > If this is real (and I am fairly sure it's not a bug at my end or at the > servers), then it will impact on the accuracy which can be achieved with > NTP. I ask myself "Why does the network do this?". Is there a valid > reason > for it, or is it a side-effect of something else? Has anyone else seen > this > effect? Is there anyone out there reading this who could modify an NTP > client program so that the loal port address can be changed manually, and > see if this is a widespread feature of the internet. If this effect > didn't > occur, NTP could be a lot better than it is now. > > Regards > Peter Martinez G3PLX > > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
