[ntp:questions] Why is NTPD adjusting the system clock when in LOCAL(0) mode?
Hello: I wrote a clock simulator program that, among other things, outputs the current time adjustment every second. The only active lines in NTPD's conf file are: # your local system clock, could be used as a backup # (this is only useful if you need to distribute time no matter how good or bad it is) server 127.127.1.0 iburst minpoll 4 maxpoll 4 # but it should operate at a high stratum level to let the clients know and force them to # use any other timesource they may have. fudge 127.127.1.0 stratum 12 Yet NTPD is constantly changing the curTimeAdjustment. Here is the evidence from my program: CTA: 156003 CTA: 156004 CTA: 156003 . I know that NTPD is doing this because when I stop it, my simulator outputs CTA: 156001 CTA: 156001 CTA: 156001 . until I restart NTPD, at which time it goes back to speeding up the system time. On what basis could NTPD possibly adjust the system time when it is using the local clock as its only time source? What standard is NTPD comparing the time to? I am running Windows 7 64-bit and the version of NTPD I am using is ntpd 4.2.4p7@copenhagen-o May 22 11:25:36 (UTC+02:00) 2009 (3). Thanks in advance for your help. Charles Elliott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin firmware update - GPS 18x 5Hz software version 3.20
You may want to watch for several days. Previous 18x LVC firmware (3.60) drifted on my system from 0.5 to 1.4 seconds over a span of 6 days. I've been running a beta version of 3.70 for several weeks with no problems. On Wed, Jun 15, 2011 at 4:09 PM, Kasper Pedersen ngfil...@kasperkp.dkwrote: On 06/15/2011 08:10 AM, David J Taylor wrote: http://www8.garmin.com/support/agree.jsp?id=4065utm_source=feedburnerutm_medium=feedutm_campaign=Feed%3A+garmin%2FVKiE+%28Garmin+|+Software+Updates%29 Although for the 5Hz model, GPS 18x 5Hz, this firmware update includes: * Improved NMEA output timing stability I tested 18x-LVC 3.70 The NMEA message starts at ~0.5s, and this time contains the correct second value. So it appears to be good. (running 115200 if this matters) /Kasper Pedersen ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp client ipv6 support
On 6/15/2011 10:16 PM, Atul Gupta wrote: Hi Steve, Thanks for your response. Its difficult for me to move to ntp-4.2.6p3. Does ntp-4.2.4 doesn't support ipv6 ? I have seen the release notes and it says that it does support. Do i need to configure with some option to enable ipv6 multicast support? NTP needs nothing to support IPv6, it's done so for many years. Your O/S may. What O/S and version are you using? What's your difficulty with upgrading NTP? There was at one point a problem in NTP with multicast on some O/S's but that was fixed a long time ago. We regularly use multicastclient FF05::101 on the servers at UDel and elsewhere so it's not the current version of NTP that's the problem. Move to the latest released version to test that. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why is NTPD adjusting the system clock when in LOCAL(0) mode?
On Wed, Jun 15, 2011 at 8:21 AM, Charles Elliott elliott...@verizon.net wrote: Yet NTPD is constantly changing the curTimeAdjustment. Here is the evidence from my program: CTA: 156003 CTA: 156004 CTA: 156003 The adjustment seems to be by 1 and it goes up and down. I'd guess this is a round off from a floating value. Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why is NTPD adjusting the system clock when in LOCAL(0) mode?
Chris Albertson wrote: On Wed, Jun 15, 2011 at 8:21 AM, Charles Elliottelliott...@verizon.net wrote: Yet NTPD is constantly changing the curTimeAdjustment. Here is the evidence from my program: CTA: 156003 CTA: 156004 CTA: 156003 The adjustment seems to be by 1 and it goes up and down. I'd guess this is a round off from a floating value. Almost correct: It is a us approximation to a ns value, so ntpd aggregates the offset between the current correction and the ideal value and adjusts to compensate. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp client ipv6 support
Over the years, netperf has encountered a number of funnies in various implementations of getaddrinfo(), necessitating some kludges in netperf to work-around them. It might be worthwhile to write a little test program that calls getaddrinfo() in a manner similar to ntp, and call getaddrinfo with several different flavors of IPv6 address. rick jones -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server specs
unruh un...@wormhole.physics.ubc.ca wrote: On 2011-06-15, Chris Albertson albertson.ch...@gmail.com wrote: One hundred?? Best to use a decentralized design. Buy 100 rs442 to rs232 receiver chips. You can place then in a box on the back of each of the 100 computers. The specs say one 442 driver can connect to ten receivers. So you'd need a ten port distribution system to drive 10 buses. Please remind us why you can't use NTP. It would be less work to buy a 100 port Eithernet hub. You can get very good timing with NTP on a short run of 100BaseT But terrible on 1000BaseT. I know it is a convenient shorthand to use the link-technology name, but is it really that 1000BaseT as specified by the IEEE is terrible, or the *implementation* specifics of various, perhaps many network interface cards supporting 1000BaseT? I'm thinking, specifically of interrupt coalescing. rick jones -- The computing industry isn't as much a game of Follow The Leader as it is one of Ring Around the Rosy or perhaps Duck Duck Goose. - Rick Jones these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server specs
On 2011-06-16, Rick Jones rick.jon...@hp.com wrote: unruh un...@wormhole.physics.ubc.ca wrote: On 2011-06-15, Chris Albertson albertson.ch...@gmail.com wrote: One hundred?? Best to use a decentralized design. Buy 100 rs442 to rs232 receiver chips. You can place then in a box on the back of each of the 100 computers. The specs say one 442 driver can connect to ten receivers. So you'd need a ten port distribution system to drive 10 buses. Please remind us why you can't use NTP. It would be less work to buy a 100 port Eithernet hub. You can get very good timing with NTP on a short run of 100BaseT But terrible on 1000BaseT. I know it is a convenient shorthand to use the link-technology name, but is it really that 1000BaseT as specified by the IEEE is terrible, or the *implementation* specifics of various, perhaps many network interface cards supporting 1000BaseT? I'm thinking, specifically of interrupt coalescing. No idea. All I know is that on my network before I put some 1000BT cards onto the network, the round trip time was very very stable at 130us. Now it flops around- sometimes 140 us, sometimes 280, sometimes 10ms. It (whatever it is) has destroyed a good timekeeping system. rick jones ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why is NTPD adjusting the system clock when in LOCAL(0) mode?
On 2011-06-15, Charles Elliott elliott...@verizon.net wrote: Hello: I wrote a clock simulator program that, among other things, outputs the current time adjustment every second. The only active lines in NTPD's conf file are: # your local system clock, could be used as a backup # (this is only useful if you need to distribute time no matter how good or bad it is) server 127.127.1.0 iburst minpoll 4 maxpoll 4 Really really really terrible idea. Get rid of it. And if you are going to use ntp, you really need some time source it can use to set your clock. It is pretty useless without that. # but it should operate at a high stratum level to let the clients know and force them to # use any other timesource they may have. fudge 127.127.1.0 stratum 12 Yet NTPD is constantly changing the curTimeAdjustment. Here is the evidence from my program: CTA: 156003 CTA: 156004 CTA: 156003 no idea what this means. .. I know that NTPD is doing this because when I stop it, my simulator outputs CTA: 156001 CTA: 156001 CTA: 156001 .. until I restart NTPD, at which time it goes back to speeding up the system time. On what basis could NTPD possibly adjust the system time when it is using the local clock as its only time source? What standard is NTPD comparing the time to? I am running Windows 7 64-bit and the version of NTPD I am using is ntpd 4.2.4p7@copenhagen-o May 22 11:25:36 (UTC+02:00) 2009 (3). Thanks in advance for your help. Charles Elliott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp server specs
unruh un...@wormhole.physics.ubc.ca wrote: On 2011-06-16, Rick Jones rick.jon...@hp.com wrote: unruh un...@wormhole.physics.ubc.ca wrote: But terrible on 1000BaseT. I know it is a convenient shorthand to use the link-technology name, but is it really that 1000BaseT as specified by the IEEE is terrible, or the *implementation* specifics of various, perhaps many network interface cards supporting 1000BaseT? I'm thinking, specifically of interrupt coalescing. No idea. All I know is that on my network before I put some 1000BT cards onto the network, the round trip time was very very stable at 130us. Now it flops around- sometimes 140 us, sometimes 280, sometimes 10ms. It (whatever it is) has destroyed a good timekeeping system. Then sift through the bathwater man and see what has fouled it before you toss-out the baby. :) And utter sweeping generalizations while it flies through the air... FWIW, here is some netperf output from my own little 1GbE network in my cubicle: raj@tardy:~/netperf2_trunk$ src/netperf -H 192.168.1.3 -t TCP_RR -l 10 -v 2 MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.3 (192.168.1.3) port 0 AF_INET : histogram : demo Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size SizeTime Rate bytes Bytes bytesbytes secs.per sec 16384 87380 11 10.0012108.71 16384 87380 Alignment Offset RoundTrip TransThroughput Local Remote Local Remote LatencyRate 10^6bits/s Send RecvSend Recvusec/Tran per sec Outbound Inbound 8 0 0 0 82.585 12108.712 0.097 0.097 Histogram of request/response times UNIT_USEC :0:0:0:0:0:0:0:0:0:0 TEN_USEC :0:0:0:0:0: 642: 523: 15767: 99307: 1053 HUNDRED_USEC :0: 3575: 180: 20:5:2:3:2:0:0 UNIT_MSEC :0:5:2:1:1:1:0:0:0:0 TEN_MSEC :0:0:0:0:0:0:0:0:0:0 HUNDRED_MSEC :0:0:0:0:0:0:0:0:0:0 UNIT_SEC :0:0:0:0:0:0:0:0:0:0 TEN_SEC :0:0:0:0:0:0:0:0:0:0 100_SECS: 0 HIST_TOTAL: 121089 one that I've not tried to tweak all that much, and where one of the nodes remains connected to a reasonably busy timeshare network. rick jones -- I don't interest myself in why. I think more often in terms of when, sometimes where; always how much. - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Why is NTPD adjusting the system clock when in LOCAL(0) mode?
On Wed, Jun 15, 2011 at 15:21 UTC, Charles Elliott elliott...@verizon.net wrote: server 127.127.1.0 iburst minpoll 4 maxpoll 4 fudge 127.127.1.0 stratum 12 Yet NTPD is constantly changing the curTimeAdjustment. Here is the evidence from my program: ntpd freewheels as orphan parent or using the LOCAL driver at the last-known frequency adjustment persisted in the driftfile, which given your configuration must have a default path even if one is not given. Assuming your system was synchronized to a NTP source at some time in the past, that frequency correction likely brings your PC's clock much closer to beating at 1 second per second. ntpd logs the initial drift value, if found, at startup. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
