In the meantime Ask has added my servers (ntp[1-3].home4u.ch) to the tr
zone. My graphs [1] show a lot of request peaks (starting after 29th
July 2012 22:00 CEST), which I did not had before in that frequency.
With the above calculation I expected to have around 12.5 requests /
second, which should correspond to 750 packets / minute in my graphs
(for average), but it is currently between 2800 and 3600 packets /
minute. This will probably still go up a little bit more, as not a full
day is measured. But it will also go down again, when some more servers
are added to the tr zone.
I believe the proper way to estimate the average request rate is to
estimate the total volume of requests for .tr and sum up all the
bandwidth figures of all the servers serving .tr, and divide the traffic
among the servers based on the bandwidth (weight) of the servers.
My guesstimate for the total volume of requests is around 3800/sec
(based on [1] and [2]) and the sum of bandwidth of all the servers
serving .tr is probably something like 7000Mbps now (counting both my
IPs even though only one of them is now in the pool, see below for more).
That means for every 100Mbps, you should be getting around 54pps
(3800*100/7000) on average. This is a ballpark figure, the actual values
can vary quite a bit.
However, the "average" is the important word here as there will be
traffic bursts. The traffic bursts will only become less frequent when
more servers are added, but it won't reduce the peak values. This is
because most traffic from Turkey originates from SNTP clients which
resolve the NTP server's IP every time the pool is queried, ie. unlike
ntpd which only resolves the hostname once and keeps using that IP
address until ntpd is restarted. Another concern is that I think the
offending Turk Telekom CPE is using only pool.ntp.org, not any of the
subdomains [0-3].pool.ntp.org. The traffic would be spread more evenly
if the [0-3] subdomains were used.
I'm currently verifying my "only pool.ntp.org is used" theory by
monitoring when my server is included in the tr zone for each of the
subdomains. Graphs [3,4,5,6,7]. To make the measurements a bit easier,
I've temporarily removed the 2nd IP address of my server from the pool.
It'll be reinstated when the tests have concluded. I believe the spikes
in traffic will correlate with the time when my server is included in
the main pool.ntp.org zone, and that the traffic amount doesn't change
substantially when my server is included in any of the
[0-3].pool.ntp.org zones. Let's see if I can spot a pattern.
For those concerned about traffic spikes (regardless of whether the
server is serving .tr clients or not) and running a stateful firewall,
I'd highly recommend configuring the stateful firewall not to track NTP
packets. For me the following two iptables commands do the trick:
iptables -t raw -A PREROUTING -i eth0 -p udp --dport 123 -j NOTRACK
iptables -t raw -A OUTPUT -p udp --sport 123 -j NOTRACK
If you're in the .tr NTP pool and want to test how your system handles
the traffic spikes, there's sadly an easy way to generate some extra
load. Just restart your ntpd. When the Turk Telekom clients notice that
your NTP server isn't synchronized, the clients will retry the query in
a few seconds. Multiply that by a few thousand clients and you'll get a
nice stream of queries until your server is synced. The clients will get
confused when they see something unexpected, like the server not being
in sync or there's an extra leap second announcement bit in the reply..
sigh.
[1] http://kameli.miuku.net/stats/ntppackets.html
[2] http://kameli.miuku.net/stats/participation.html
[3] http://kameli.miuku.net/stats/participation_.html
[4] http://kameli.miuku.net/stats/participation0.html
[5] http://kameli.miuku.net/stats/participation1.html
[6] http://kameli.miuku.net/stats/participation2.html
[7] http://kameli.miuku.net/stats/participation3.html
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
