Anomaly in NTP measurement data
Hi, In the data to date of an NTP measurement (#80845985), I find a single strange outlier with respect to the RTT value calculated: { "fw": 5090, "mver": "2.6.4", "lts": 281, "dst_name": "time2.cloud.tencent.com", "ttr": 0.413039, "dst_addr": "119.28.229.79", "src_addr": "45.11.104.146", "proto": "UDP", "af": 4, "li": "no", "version": 4, "mode": "server", "stratum": 2, "poll": 8, "precision": 1.19209E-7, "root-delay": 0.0000915527, "root-dispersion": 0.0249329, "ref-id": "647a24c4", "ref-ts": 3939345482.4404373, "result": [ { "origin-ts": 3939346062.989854, "receive-ts": 3939346062.999974, "transmit-ts": 3939346063.0000167, "final-ts": 3939346062.995442, "rtt": 4294967296.005545, "offset": -0.007347 } ], "msm_id": 80845985, "prb_id": 7030, "timestamp": 1730357262, "msm_name": "Ntp", "from": "45.11.104.146", "type": "ntp", "group_id": 80845985, "stored_timestamp": 1730357293 }, When I do the math by hand, the "rtt" value I get is 0.0055453, nicely matching the fractional part found in the measurement data. Does anyone have an explanation as to where the weird integer part might come from? Some overflow/underflow or other issue with decimal math on a binary machine? (I am not sufficiently versed in computer science to fully understand that topic, just that there are challenges in that area.) Thanks! Kind regards, R.
Hi, This indeed looks like a weird underflow/overflow bug -- 4294967296 in the RTT value happens to be 2^32... We'll see if we can find a bug around this. Regards, Robert On Sun, Nov 3, 2024 at 9:18 PM ripe--- via ripe-atlas <ripe-atlas@ripe.net> wrote:
Hi,
In the data to date of an NTP measurement (#80845985), I find a single strange outlier with respect to the RTT value calculated:
{ "fw": 5090, "mver": "2.6.4", "lts": 281, "dst_name": "time2.cloud.tencent.com", "ttr": 0.413039, "dst_addr": "119.28.229.79", "src_addr": "45.11.104.146", "proto": "UDP", "af": 4, "li": "no", "version": 4, "mode": "server", "stratum": 2, "poll": 8, "precision": 1.19209E-7, "root-delay": 0.0000915527, "root-dispersion": 0.0249329, "ref-id": "647a24c4", "ref-ts": 3939345482.4404373, "result": [ { "origin-ts": 3939346062.989854, "receive-ts": 3939346062.999974, "transmit-ts": 3939346063.0000167, "final-ts": 3939346062.995442, "rtt": 4294967296.005545, "offset": -0.007347 } ], "msm_id": 80845985, "prb_id": 7030, "timestamp": 1730357262, "msm_name": "Ntp", "from": "45.11.104.146", "type": "ntp", "group_id": 80845985, "stored_timestamp": 1730357293 },
When I do the math by hand, the "rtt" value I get is 0.0055453, nicely matching the fractional part found in the measurement data.
Does anyone have an explanation as to where the weird integer part might come from? Some overflow/underflow or other issue with decimal math on a binary machine? (I am not sufficiently versed in computer science to fully understand that topic, just that there are challenges in that area.)
Thanks!
Kind regards,
R. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
participants (2)
-
ripe@nurfuerspam.de
-
Robert Kisteleki