We can now see at which time a packet was received by the network
adapter, instead of having to measure user time after receiving
the packet in user space.
This means the destination timestamp is no longer affected by in-kernel
queuing delays, which can be tens of milliseconds when the system
is under load.
It also means that if ntpquery grows a message queue that waits on
replies from several requests, the time used processing one response
won't be incorrectly included in the destination timestamp of the
next response (in case two responses arrive at the network adapter
at roughly the same time).
NTP's calculations work better if send and receive latency are
about equal, and this only removes in-kernel queue delays and
context switch delays for the receiving packet. But the two
latencies aren't very equal anyways because $network. Also, maybe
we can add another API for setting the send time in the outgoing
packet in kernel space right before (or when) hitting the network
adapter and use that here too. So this still seems like progress.
Using a pool.ntp.org server seems nicer and more open-source-y,
but until our pool use is approved, let's put in a default value
that works.
(time.google.com serves smeared time instead of doing leap seconds.
pool.ntp.org doesn't serve smeared time. I intend to implement
client-side leap second smearing since nobody likes jumpy timestamps.
For now, we get this for free.)
This only queries a single NTP server, only does a point-to-point
request, doens't do any filtering, doesn't display the response
in any useful format, and is generally very bare-bones.
But maybe, over time it can learn to query more servers, do
filtering, run as a service that keeps state over time to
improve filtering, adjust system time, and maybe learn to
run as an NTP server then.
