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.
NTP implementations exist that make different uses for the transmit time
stamp such as associating a random value to it, encoded (or unencoded)
indexing into an array for association, a magic number, or even a memory
pointer to the object instance associated with the request.
request = ( struct request * ) response.getOriginate();
if( requestMemory.associateAddress( request ) == EXIT_SUCCESS ) {
if( request->magic != 0xDEADBEEF ) {
return EXIT_FAILURE;
}
/* Process response, update peer statistics. */
}
On Tue, 29 Nov 2005, Nelson Minar wrote:
I run a pool.ntp.org server at 72.36.170.170. I've logged 72 days
worth of NTP packets and have boiled down the 18 gigs of traffic into
a database. I've done some preliminary analysis of the results.
There's a lot more detail to mine here and I hope to generate a nice
little report with pretty graphs and such. I'm interested in feedback
on what other data people would like to see. I'm particularly
interested in characterizing two things: how many abusive clients
there are, and how many clients are actually setting their clocks.
Basic analysis:
1.2M client requests / day, or 14 / second.
Standard deviation of requests/day is 255,000.
Ugly graph here:
http://www.nelson.monkey.org/~nelson/tmp/reqsPerDay.png
10,000 different IPs a day: 316,000 in 72 days.
10 IPs account for 13% of all traffic
100 IPs account for 33% of all traffic
1000 IPs account for 63% of all traffic
1100 IPs asked my server for time more than once / 128 seconds on average.
(this count is limited to IPs who stuck around more than a day.)
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. Ie: the time they report is
consistently off from my server by many seconds. I'm looking for a
good statistical way to characterize this.
Some boring details:
The samples are from around 8am on 2005-09-16 (UTC) to 2am 2005-11-28.
My server is at 72.36.170.170. My server was up continuously during
this time and has been serving time accurately and well. There was
about one hour of network congestion on November 9, but I don't think
I was dropped from the pool. It's a Stratum 3 clock in the USA
(Texas), synchronized to six peers.
There were about 217,000 other client requests that my parser didn't
understand, mostly badly formed requests. Those aren't present here.
Here are the database schema I have:
Raw requests
mysql> describe reqs;
+---------+----------------------+------+-----+-------------------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+----------------------+------+-----+-------------------+-------+
| ip | int(10) unsigned | YES | MUL | NULL | |
| ts | timestamp | YES | | CURRENT_TIMESTAMP | |
| offset | int(11) | YES | | NULL | |
| version | tinyint(3) unsigned | YES | | NULL | |
| stratum | tinyint(3) unsigned | YES | | NULL | |
| poll | smallint(5) unsigned | YES | | NULL | |
+---------+----------------------+------+-----+-------------------+-------+
Rollup of per client data
mysql> describe clients;
+-------------+----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+----------------------+------+-----+---------+-------+
| ip | int(10) unsigned | YES | | NULL | |
| requests | bigint(21) | NO | | 0 | |
| min_ts | timestamp | YES | | NULL | |
| max_ts | timestamp | YES | | NULL | |
| max_poll | smallint(5) unsigned | YES | | NULL | |
| max_version | tinyint(3) unsigned | YES | | NULL | |
| min_stratum | tinyint(3) unsigned | YES | | NULL | |
| min_offset | bigint(20) | YES | | NULL | |
| max_offset | bigint(20) | YES | | NULL | |
| avg_offset | decimal(14,4) | YES | | NULL | |
| sd_offset | decimal(24,4) | YES | | NULL | |
+-------------+----------------------+------+-----+---------+-------+
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
