is there a technical reason /tool fetch uses 1s intervals? mikrotik supports ms time

RouterOS Scripting
1

i'm trying to use /tool fetch to measure wan latency for a script.

every successful fetch is almost exactly 1 second, regardless of the destination.

i tested:

  • google
  • github
  • cloudflare
  • microsoft
  • a local http server on my lan (<1 ms away)

the local server still reports:

duration: 1s

i also measured elapsed time around /tool fetch using :timestamp/:tonsec, and it also comes out around 1010 ms.

interestingly, routeros clearly supports sub-millisecond elapsed timing:

:put [:time command={ :delay 250ms }]
00:00:00.250734

so it doesn't appear to be a timer precision limitation.

is this expected?

if so, could /tool fetch expose actual elapsed time in milliseconds (or tcp connect / tls / ttfb timing) so it can be used for latency measurements?

sample log:

2026-08-06 11:34:35 probe cloudflare.com: DoH=1011ms HEAD=1011ms
2026-08-06 11:35:36 probe microsoft.com: DoH=1012ms HEAD=2012ms
2026-08-06 11:36:43 probe github.com: DoH=8029ms HEAD=1009ms
2026-08-06 11:37:35 probe google.com: DoH=1011ms HEAD=1010ms
2026-08-06 11:38:35 probe apple.com: DoH=1012ms HEAD=1012ms
2026-08-06 11:39:35 probe cloudflare.com: DoH=1012ms HEAD=1012ms
2026-08-06 11:40:35 probe microsoft.com: DoH=1010ms HEAD=1011ms
2026-08-06 11:41:35 probe github.com: DoH=1011ms HEAD=1011ms
2026-08-06 11:42:35 probe google.com: DoH=1012ms HEAD=1010ms
2026-08-06 11:43:35 probe apple.com: DoH=1010ms HEAD=1011ms

later in the same run:

2026-08-06 13:08:39 probe cloudflare.com: DoH=3017ms HEAD=2010ms
2026-08-06 13:09:36 probe microsoft.com: DoH=1001ms HEAD=1010ms
2026-08-06 13:10:37 probe github.com: DoH=2013ms HEAD=1010ms
2026-08-06 13:11:36 probe google.com: DoH=1010ms HEAD=1011ms
2026-08-06 13:12:36 probe apple.com: DoH=1011ms HEAD=1011ms
2026-08-06 13:13:39 probe cloudflare.com: DoH=4020ms HEAD=1012ms
2

As the 1-second delay is also present when fetching HTTP only resources in LAN (no DNS lookup, no certificate check), my guess is that the delay was probably deliberately introduced to mitigate the situation where compromised RouterOS devices (there are plenty that have been taken over due to exposed management with no or weak passwords) being use for DDoS attacks.