Chuck Swiger wrote on 17-9-2007 22:38: > I don't think anyone wants to ban people running NTPd behind NAT from > being part of the pool. Ok. I hate NAT just like you, but I think we can agree that we'll have to live with it for some years to come. > However, it's worth noting that this isn't the preferred configuration, > either. Especially for those people whose NAT implementation tries to > do stateful tracking of the UDP traffic with a limited number of "slots" > available, as those devices tend to lose pretty badly when faced with a > traffic peak from the normal pool rotation.... I completely agree. This was why I started to study how many slots I had in use. After cranking the table up to 100,000 slots I can easily handle the peaks I'm seeing from the pool. I believe that confirmes more or less that the state table size is the bottleneck in "consumer grade" NAT devices. Of course this large table is a quick and dirty solution. I'm experimenting now off-line with a stateless setup, but I haven't got it working yet. This might be a solution for pool members with a single ip address, although it requires an extra host to act as nat router of course. >> I see little harm in a stateless NAT setup, no tables to overflow, just >> the latency of an extra hop. Doesn't have to be more than 0.5 ms, >> probably even less, and it's symmetrical. That doesn't hurt the quality >> of the provided time service. > This depends on your implementation of NAT, and how busy the device is. > I'm familiar with several NAT devices which add somewhere around 10 ms > of latency, although newer routers and machines running at HZ=1000 or > greater tend to offer around 1ms of latency. I'm seeing 0.5 ms here on my soekris+pfsense and I expect to get it down in a stateless setting, because that involves less processing. I'm amazed about that 10 ms, apparently it varies more than I thought. > It does help that the latency is symmetric, that's certainly a valid point. >> What is the rtt to your closest ntp server? Around 14 ms in my case. > Excluding the ones which are peers on my local subnet, I've got two > which are ~5 ms away, and another two which are 9 to 10 ms away > (http://www.pool.ntp.org/user/cswiger): I'm loosing 7 ms in my ppp link alone... But let's say that 10 ms is nice for a nearby server. Can you agree with me that adding a (symmetric) millisecond to that is less undesirable than dropping thousands of requests (and much more probably) during a pool burst?
regards, Jan _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
