This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] negative RTT?
- Previous message (by thread): [atlas] negative RTT?
- Next message (by thread): [atlas] NZ Registry Services, Aukland, New Zealand has joined RIPE Atlas anchors
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Robert Kisteleki
robert at ripe.net
Fri Apr 17 10:57:44 CEST 2015
On 2015-04-14 11:05, Paul Vlaar wrote: > On 14/4/15 10:58 AM, Philip Homburg wrote: >> This can be fixed by switching the measurement code to one of the >> alternative time sources in the Linux kernel that is not subject to >> these jumps. However that requires touching all time related code in the >> measurement code. > > Is there an established way to work around this on the receiving end? > > ~paul RIPE Atlas is way beyond the point where you can trust *all* results blindly. Even if the measurement code and time keeping is 100% correct, there are network glitches, funny middle boxes, power brownouts, solar flares, bit flips, packet eating midgets, etc. When interpreting results, we strongly encourage users to filter out outliers (e.g. top/bottom X percentile). Regards, Robert
- Previous message (by thread): [atlas] negative RTT?
- Next message (by thread): [atlas] NZ Registry Services, Aukland, New Zealand has joined RIPE Atlas anchors
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]