3 ms·

Doesn't jitter depend more on the network latency, rather than the real-timeliness of the process?

• mlyle 6y ago
  Jitter is the variation in latency of all sources. The latency of the A) delay in the original packet being sent + B) the latency of the network itself + C) latency of the ntp server receiving the packet + D) latency of the process answering the packet + E) latency of the kernel sending the response + F) the latency of the network itself for the return pack + G) the latency of the client receiving the return packet and giving it an accurate local time mark. On a uncongested LAN, B & F can be very low in absolute terms and low in variation. This server constrains C, D, & E to basically nothing. So only A & G-- the limitations of the client itself -- remain. How long does it take to receive the frame, get it to system RAM, dispatch an interrupt (which may be coalesced), service the interrupt, and context switch to/wake up the right client process? Alternatively, the network driver can capture a timestamp at the moment the packet is received, eliminating a lot of this variation. NTP clients assume half of the delay is client->server and half is server->client, for the purpose of computing offset. That is, they subtract half the roundtrip delay off the received time. So reducing delay in C, D, & E further reduces the amount that this guess can be wrong by.