[time-nuts] Network Time Puzzle

[Stewart Bryant]

Peter

If changing the ports changes the offset you are almost certainly seeing an ECMP (equal cost multi-path) effect.

In IP routing we try to spread the load across all available paths of the same notional cost (the sum of a set of link costs chosen by the network operator to try to tune  the traffic follows at the macro level). This is normally done by hashing the network layer five tuple (source address, destination address, ip type, source port and destination port). A depolarisation  factor is normally also introduced based on the identity of the router. Then the next hop is chosen by taking the hash modulo number of possible paths.

As the network changes, so does the path chosen. This is all best effort stuff and so you cannot rely on any consistency in the path.

The other artefact of the IP routing system that impacts NTP is that the path decision is unidirectional, so there is no attempt to make the out and the return paths congruent.

Stewart/G3YSX

Sent from my iPad

> On 26 May 2019, at 09:26, Peter Martinez via time-nuts <time-nuts at 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 at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.