On Sep 17, 2007, at 12:58 PM, Jan Hoevers wrote:
>> It's not a great idea to use NAT in the path to an NTP server; it  
>> just
>> adds load and latency which have a negative effect upon the  
>> quality of
>> the time service being provided.  People who want to provide  
>> contribute
>> time services to the pool should make every effort to only use  
>> machines
>> which have statically assigned public IPs which are not behind a NAT
>> firewall/router.
>
> Sure I would like to give my ntp server its own public address, but it
> would quadruple the monthly cost of my connection. I'm surely not  
> going
> to pay that amount of money just to be a pool member.
> I think the pool would loose a lot of members if it banned NAT  
> routers.

I don't think anyone wants to ban people running NTPd behind NAT from  
being part of the pool.

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 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.

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):

47-ns1# ntpq -p pong
      remote           refid      st t when poll reach   delay    
offset  jitter
======================================================================== 
======
LOCAL(1)         .LOCL.          10 l   36   64  377    0.000     
0.000   0.000
+NAVOBS1.MIT.EDU .PSC.            1 u  114  512  377    9.916    
-2.051   2.103
-time0.apple.com 17.254.0.49      2 u   30  512  377   85.694    
-2.943   0.489
*avi-lis.gw.ligh .CDMA.           1 u  139  512  377    5.376    
-1.772   0.731
+ntp-1.cns.vt.ed 198.82.247.40    2 u   93  512  377   16.559    
-2.182   0.151
-pi.codefab.com  18.26.4.105      2 u  235  256  375    0.254    
-1.035   0.101
-shot.codefab.co 65.212.71.102    2 u  239  256  375    0.323    
-4.985   0.802
-ns1.pkix.net    208.184.49.9     2 u  226  256  375    0.306    
-0.008   0.111

48-ns1# ntpq -p pi
      remote           refid      st t when poll reach   delay    
offset  jitter
======================================================================== 
======
-time.nist.gov   .ACTS.           1 u   65  512  371   49.586     
4.355   6.124
*bonehed.lcs.mit .CDMA.           1 u  124  512  377    9.386    
-1.030   0.054
+hickory.cc.colu 128.59.39.48     2 u  277  512  377    4.962    
-1.054   0.055
-otc1.psu.edu    .WWV.            1 u 1564  512  370   43.929   
-29.996   1.768
+pong.codefab.co 209.51.161.238   2 u  254  256  376    0.376     
1.096   0.152
-shot.codefab.co 65.212.71.102    2 u  503  512  376    0.382    
-4.133   0.031
+ns1.pkix.net    208.184.49.9     2 u  190  512  336    0.334     
1.007   0.015

Regards,
-- 
-Chuck

PS: I wish this mailing list didn't remove the format=flowed MIME  
type; the tables above are properly formatted and fit within 78- 
characters, so they shouldn't be wrapped...

_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to