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 samples||A 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
K. Sandler, July '06