From sean at ripe.net Wed Jul 11 17:01:39 2001 From: sean at ripe.net (Sean Young) Date: Wed, 11 Jul 2001 17:01:39 +0200 Subject: Test, please ignore Message-ID: <20010711170139.K26421@x16.ripe.net> Dear Test-Box hosts, This mailing list, which is meant for all parties hosting a test-traffic measurement box, is now automagically generated from a database. This mail is to test the new setup and to ask for feedback, if you're not receiving this at the right email address. In case of any error, please reply to tt-ops at ripe.net. Regards, Sean Young From wilhelm at ripe.net Tue Jul 24 13:36:33 2001 From: wilhelm at ripe.net (Rene Wilhelm) Date: Tue, 24 Jul 2001 13:36:33 +0200 Subject: recent changes to TTM delayplots Message-ID: <200107241136.NAA23505@kantoor.ripe.net> 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/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From marks at ripe.net Thu Jul 26 11:25:17 2001 From: marks at ripe.net (Mark Santcroos) Date: Thu, 26 Jul 2001 11:25:17 +0200 Subject: removal of gated Message-ID: <20010726112517.E499@laptop.6bone.nl> Dear Test-Box operators, Since the start of the TTM project, testboxes have been equipped with the gated daemon. The gated daemon's main purpose is the dynamic configuration of the gateway address. For both technical and security reasons we would like to stop running it. As far as we know, none of the testboxes use this functionality as they all have their gateway address statically configured. However, to prevent errors or uncontrolled testboxes, we will keep it running for at least a month to give testbox operators the change to speak up. So if you have any arguments in favor of running gated, please let us know and we will consider them. You can send your reply either back to the list or to: tt-ops at ripe.net. Thank you in advance. With best regards, Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM