Boyan Krosnov wrote:
I spent a couple of days putting together a somewhat detailed
statistical breakdown of all NTP traffic received at my pool.ntp.org
<http://pool.ntp.org> server in the last 4 months.
The result is here:
http://www.krosnov.org/pool.ntp.org/A%20pool.ntp.org%20traffic%20analysis%202007-05-27.pdf
Interesting data, Boyan, thank you for sharing it. I love this stuff. I
did a similar study in late November 2005; details and some data
downloads below.
For the NTP admins out there I think the data on page 9 and 13-21 is
likely to be most useful.
Page 9 shows the same pattern of abuse we've all seen. You're showing
that 13% of your traffic is coming from 1/10,000 of your clients. Back
in late 2005 I did a similar study and found 13% of my traffic was
coming from 1/100,000 of my clients. So maybe the distribution of
abusive clients is flattening a little bit, or more likely the
proportion of sane clients is increasing. I didn't do any analysis to
further characterize this trend, but I do still have some useful raw
data from back then if someone wanted to look for trends.
Page 21 shows a traffic growth curve with a suggestion that traffic
increases 500bps / month. I have a similar graph of traffic size here,
although I don't see as clear a trend in it.
http://www.somebits.com/~nelson/tmp/reqsPerDay.png
If I read your bandwidth numbers correctly, you're serving roughly
3,500,000 requests / day? Back then I saw about 1,500,000 requests / day.
You also have some interesting details about the odd behaviour of
various systems' IP implementations. I'm particularly curious about your
sawtooth pattern in the second graph of page 8. If I understand
correctly, what you've seen is that for packets with a TTL between 129
and 173, it's more likely that TTL is even than odd. There aren't that
many packets with that property, it might be interesting to extract all
of them and analyze them some more. I have one hypothesis: a TTL of
129-173 is weird because it's quite high, and yet also very low if the
system sets TTL to 256. Maybe those packets got trapped in some router
loop that happens to only release them after an even (or odd) number of
hops? It's a total guess though, it'd help a lot to know how many IPs
are showing that pattern and how often they do it.
For the record, here's the email I sent of my little analysis in fall of
2005. I don't have the raw packet captures anymore, but I still have the
database. I've made the 'clients' table described below available for
download, it's pretty small. The 'reqs' table is about 650 megs
compressed; I can make it available if you need it. The clients database
(in MySQL dump format) is here:
http://www.somebits.com/~nelson/tmp/ntp/
------------------------------------------------------
I run a pool.ntp.org <http://pool.ntp.org> server at 72.36.170.170
<http://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
<http://www.nelson.monkey.org/%7Enelson/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 <http://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
