recent changes to TTM delayplots

Dear Test-Box hosts,

This is to inform you about two recent modifications we applied
to the delay plots published in the password protected part of
the TTM website. Note that these changes also apply to older plots
requested via the plots-on-demand interface.

1. Report number of changes in routing during the measurement period

   As you know, the test-boxes regularly carry out traceroute 
   measurements to get (a best approximation of) the routes followed
   by the TTM delay packets. The results are stored in a database
   which can be queried via http://www.ripe.net/cgi-bin/ttm/routing

   For quick reference and to easier correlate with delay measurements,
   results are also summarized in the delay plots: the top left graph
   shows variation of number of hops with time, the statistics listing
   on the right reports (towards the bottom) the number of different
   route vectors seen during the measurement period.

   Following suggestions made at the RIPE38 tt-wg meeting, we have 
   modified the plot code to also report, in the overall statistics
   section, the number of flaps between the observed routing vectors.
   This immediately gives an indication of the route's (in)stabality,
   which may help interpreting the plotted delay data.

   For example: http://www.ripe.net/cgi-bin/ttm/plots-on-demand?SRC=tt01.ripe.net&date_start=20010114&time_start=00%3A00&DST=tt47.ripe.net&date_end=20010115&time_end=00%3A00&mindelay=+150&maxdelay=+250&format=gif&SUBMIT=Submit

   shows that eventhough the route appears stable (always 18 hops in
   the top left graph), it actually flapped 118 times between 4 distinct
   route vectors.


2. Improved checks on clock accuracy

   In operating the cluster of test-boxes we noticed that in some cases
   a machine reboot caused problems to the synchronization of the local
   clock: although thought to be synchronized to GPS, the clock in reality
   got an offset of some 30ms which slowly, in a timeframe of several hours,
   converged back to zero. The problem is not fully understood and as of yet
   we have not been able to reliably reproduce it at the RIPE NCC.
   However, by checking an additional parameter of the time keeping software
   we can detect this situation and thus prevent such unsynchronized clocks
   from skewing the measurements. The delay plots for these periods will now
   mark the clock as invalid and will not show the one way delays.

For those who are interested, the source code of the modified program
is available from ftp://ftp.ripe.net/test-traffic/ROOT/delayplots/
The (also modified) supporting class library source can be found in
ftp://ftp.ripe.net/test-traffic/ROOT/libDelay/

With best regards,

-- Rene Wilhelm


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rene Wilhelm                    RIPE Network Coordination Centre
Email: wilhelm at ripe.net         Test Traffic Measurements
Phone: +31 20 535 4417          Amsterdam, the Netherlands
Fax:   +31 20 535 4445          http://www.ripe.net/ripencc/mem-services/ttm/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=