If they are consistently off, it's probably an SNTP client. Perhaps a
Windows box running an SNTP client or the Windows Time Service; or ntpdate
synchronizing to your box (insert many other SNTP clients here).
If their time is consistently off between requests, and their requests are
fairly consistent, you can calculate the oscillation of each individual
piece of hardware and graph the oscillation of those clients as well as
know the exact number of hardware units querying your NTP service from
that given IP address with a fairly high level of accuracy.
I've seen, and read, techniques that use the timestamp associated with
RFC1323 to determine the oscillation frequency as a means of finger
printing and even authentication.
I'm not sure what you can do with the data you are collecting but one
thought does comes to mind; seed your prng with it. ;)
On Tue, 29 Nov 2005, Nelson Minar wrote:
Paul-Andrew Joseph Miseiko wrote:
I am assuming your statement: "A preliminary check of what time the clients
are reporting to me suggests a distressing number of clients are not
actually setting their clocks to the time I give them." Is based on the
transmit time stamp associated with a request. This time stamp does not
have to be a valid representation of the clients time; in fact it is more
suitable to associate a request/response pair.
Yes, you are right, I am using the transmit timestamp and measuring the delta
from what time my server thinks it received the packet as "offset". You're
right, this isn't guaranteed to be a meaningful time. Do you have any idea
how many implementations send something other than a normal timestamp when
making a request? Any way to characterize the implementations? I definitely
see clients with completely insane transmit timestamps.
But I also see a lot of clients with sensible but depressing timestamps.
Folks who are consistently a few seconds off. I'll append part of a time
series of requests from one IP address which is varying between 11 seconds
and 65 seconds off my server's time. The pattern is consistent enough that I
think the client really is sending me what its notion of time is, it's just
got the wrong time. And apparently it's not setting its clock based on what
I'm telling it, either. At least this client isn't an abuser; it only sent
248 requests over six weeks. Most clients I've sampled have this pattern.
I've seen very few clients that converge to my server's time, indeed few that
seem to be setting their clocks at all.
I'm still working on how to characterize this behaviour. There are a bunch of
complications in the data. Transmit timestamps may not actually be time
stamps. Network delay is skewing the offsets I'm seeing. And sometimes
multiple hosts share a single IP. Makes for noisy data.
Here's the info on one client:
| ip | requests | min_ts | max_ts |
max_poll | max_version | min_stratum | min_offset | max_offset | avg_offset |
sd_offset |
+------------+----------+---------------------+---------------------+----------+-------------+-------------+------------+------------+------------+------------+
| 12.17.249.58 | 248 | 2005-09-17 00:56:07 | 2005-11-07 15:20:14 |
17 | 3 | 0 | 10598 | 68247 | 32945.1976 |
23932.2076 |
And a bit of the time series:
| 2005-10-20 23:01:49 | 11919 |
| 2005-10-21 01:58:26 | 64045 |
| 2005-10-21 02:15:30 | 64039 |
| 2005-10-21 02:32:34 | 63967 |
| 2005-10-21 02:41:06 | 64057 |
| 2005-10-21 02:45:22 | 64063 |
| 2005-10-21 02:47:30 | 64046 |
| 2005-10-21 02:48:34 | 64061 |
| 2005-10-21 02:49:06 | 63954 |
| 2005-10-23 21:21:22 | 65315 |
| 2005-10-23 21:38:26 | 65320 |
| 2005-10-23 21:55:30 | 65314 |
| 2005-10-23 22:04:02 | 65329 |
| 2005-10-23 22:08:18 | 65321 |
| 2005-10-23 22:10:26 | 65330 |
| 2005-10-23 22:11:30 | 65319 |
| 2005-10-23 22:12:02 | 65332 |
| 2005-10-24 08:42:15 | 11833 |
| 2005-10-24 08:59:19 | 11834 |
| 2005-10-24 09:16:24 | 11835 |
| 2005-10-24 09:24:56 | 11836 |
| 2005-10-24 09:29:12 | 11836 |
| 2005-10-24 09:31:20 | 11836 |
| 2005-10-24 09:32:24 | 11836 |
| 2005-10-24 09:32:56 | 11836 |
| 2005-10-24 23:59:45 | 65823 |
Looking at this I'd guess there's two different computers being used at
different times of day, and one is 11.8 seconds off while the other is 64-65
seconds off. Beats me, but that sure isn't what I'd hoped for!
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
