Note: All the scattergrams below are behind the times. Only some of the upstream servers presented here are currently used.

All the upstream servers are stratum 1 timeservers and therefore their own offset (about a few microseconds) is negligible in these "offset versus delay" plots. An exceptions may exist though: for example a transient offset after a server restart or a server with some real not corrected offset (see this note).

The wedge scattergrams are usually plotted for a pair of a stratum 1 timeservers. In such a case both the apex and the wedge boundaries are sharp on a milisecond scale and a scattergram represents true picture of a network path quality (for more details and examples see the pages here). The situation is different for a client stratum 2. An offset scatter has two causes here - network latencies and the client own offset. Although any peer offset (taken from the peerstats file) can somewhat be corrected for our own offset (taken from the loopstats file), such a procedure hasn't been used here. The lx offset enlarged by its error estimate doesn't exceeded 1.09 ms during the measurement period.

An interpretation of a scattergram follows from the equations below, where 'up' is the travel time of a packet sent to the server.

'peerstats offset' = 'our own offset' + (up - down)/2 - 'server offset'  ;  delay = up + down

All samplesA slice

Note: One from the timeservers above runs behind of UTC by amount 1.0 ms all the time. It's a pity that this DCFp timeserver can't be used by a client with submilisecond accuracy (the network path is very stable as can be seen from the scattergram or from this peer plot). The NTPv4 doesn't allow any fudge factor on the client side.

K. Sandler, July '06