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