When the NTP measurement sends more than one NTP request packet in one measurement execution (the default is to send three packets), the second and further request packets are sent as soon as a response to the previous request has been received, i.e., typically within way less than a second. This violates at least one implementation's default rate limiting settings ("guard time"). As a result, only the first request yields any useful data. The second request typically elicits a RATE KoD response, further requests are typically ignored by the server.
I hereby raise the suggestion to space sending of requests within one measurement execution by at least two seconds, perhaps a bit more to be on the safe side, and to potentially make this a user-configurable setting. (Unfortunately, I don't understand enough of the probe's code to propose specific code changes myself.)
When the NTP measurement sends more than one NTP request packet in one measurement execution (the default is to send three packets), the second and further request packets are sent as soon as a response to the previous request has been received, i.e., typically within way less than a second. This violates at least one implementation's default rate limiting settings ("guard time"). As a result, only the first request yields any useful data. The second request typically elicits a RATE KoD response, further requests are typically ignored by the server.
I hereby raise the suggestion to space sending of requests within one measurement execution by at least two seconds, perhaps a bit more to be on the safe side, and to potentially make this a user-configurable setting. (Unfortunately, I don't understand enough of the probe's code to propose specific code changes myself.)
2024-04-17_ripe-atlas-probe-triggers-RATE.txt