[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Hi all, I just came home from supper to the most NOT charming experience. I had left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I came home, I found the clock said Aug 2014 and visually could see that the clock was advancing at a rate of about 2 HR per actual second. The Meinberg screen said it was locked into the local clock and the Meinberg screen appeared to be updating about twice per second rather than once ever 10 seconds. It said that the preferred clock was LOCL 127.127.1.1. I don't know what the heck happened, but these anomalies are getting really old. Hopefully the Sure board will do better. Oh, by the way, I shut down NTPD and the clock kept advancing the same way. 2 reboots appear to have fixed it. I've removed LOCL from the config file. Here are some links to some log and conf files if anyone is interested. Note the dates at the end. I've got 1200 log files in between these start and end dates. http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock note the date far into the future http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock note the date far into the future http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock Sincerely Frustrated, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Ron, I don't know what the heck happened either, but there are a few clues. You didn't tell us which version of ntpd you're using or which OS it's running on. Skimming the huge ntp.conf for non-comment lines I see it appears to be some version of Windows. Take note of the last line in the first loopstats file you sent: 56005 85287.065 -1.#IND0 -1.#IO 0.003538719 -1.#IND00 3 There is no activity in the corresponding peerstats file to give a hint what sent your offset and frequency off the deep end. You might check the eventlog around the end of the 19th UTC to see if there are any clues there. Although it's the first time I've seen such, it appears the offset and frequency calculations both ended up overflowing. I would have guessed bad input should have appeared in peerstats before loopstats but I didn't find anything unusual. It does appear the GPS was unplugged or stopped sending or sent sentences indicating no lock, based on the last peerstats entry for 127.127.20.5 occurring almost exactly 5 minutes before the overflow event. Probably we should just write it off as nominal since the PC is described as psycho. Take care, Dave Hart On Tue, Mar 20, 2012 at 01:59, Ron Frazier (NTP) wrote: > Hi all, > > I just came home from supper to the most NOT charming experience. I had > left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I > came home, I found the clock said Aug 2014 and visually could see that the > clock was advancing at a rate of about 2 HR per actual second. The Meinberg > screen said it was locked into the local clock and the Meinberg screen > appeared to be updating about twice per second rather than once ever 10 > seconds. It said that the preferred clock was LOCL 127.127.1.1. I don't > know what the heck happened, but these anomalies are getting really old. > Hopefully the Sure board will do better. Oh, by the way, I shut down NTPD > and the clock kept advancing the same way. 2 reboots appear to have fixed > it. I've removed LOCL from the config file. Here are some links to some > log and conf files if anyone is interested. Note the dates at the end. > I've got 1200 log files in between these start and end dates. > > http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock > > http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock note > the date far into the future > http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock > > http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock note > the date far into the future > http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock > > Sincerely Frustrated, > > Ron > > > -- > > (PS - If you email me and don't get a quick response, don't be concerned. > I get about 300 emails per day from alternate energy mailing lists and > such. I don't always see new messages very quickly. If you need a > reply and have not heard from me in 1 - 2 weeks, send your message again.) > > Ron Frazier > timekeepingdude AT c3energy.com > > ___ > 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] PSYCHO PC clock is advancing at 2 HR per second
Ron Frazier (NTP) wrote: > the clock said Aug 2014 > the clock was advancing at a rate of about 2 HR per actual second. > appeared to be updating about twice per second rather than once > ever 10 seconds. It said that the preferred clock was LOCL Remove LOCL. I thought others had mentioned it might be a bad idea. -- E-Mail Sent to this address will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Hi Dave H, Thanks for the info and for looking into the issue. I meant that the clock was psycho, not the PC. The PC is normally very tame and cooperative, as cooperative as Windows gets anyway. These GPS experiments have certainly brought several surprises though. I run both Windows and Ubuntu Linux, but in this case, the system is: Windows 7 Home Premium SP 1 NTPD 4.2.7p259 LOCL has been removed. However, that brings up a question. Since I'm doing tests with the internet clocks noselected (but still monitoring them), and the GPS is the only selectable clock, what happens if it becomes invalid? The whole reason I put LOCL in there was to allow the machine to "coast" if the GPS signal became invalid. How would I go about checking the event log? Sincerely, Ron On 3/19/2012 10:59 PM, Dave Hart wrote: Ron, I don't know what the heck happened either, but there are a few clues. You didn't tell us which version of ntpd you're using or which OS it's running on. Skimming the huge ntp.conf for non-comment lines I see it appears to be some version of Windows. Take note of the last line in the first loopstats file you sent: 56005 85287.065 -1.#IND0 -1.#IO 0.003538719 -1.#IND00 3 There is no activity in the corresponding peerstats file to give a hint what sent your offset and frequency off the deep end. You might check the eventlog around the end of the 19th UTC to see if there are any clues there. Although it's the first time I've seen such, it appears the offset and frequency calculations both ended up overflowing. I would have guessed bad input should have appeared in peerstats before loopstats but I didn't find anything unusual. It does appear the GPS was unplugged or stopped sending or sent sentences indicating no lock, based on the last peerstats entry for 127.127.20.5 occurring almost exactly 5 minutes before the overflow event. Probably we should just write it off as nominal since the PC is described as psycho. Take care, Dave Hart On Tue, Mar 20, 2012 at 01:59, Ron Frazier (NTP) wrote: Hi all, I just came home from supper to the most NOT charming experience. I had left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I came home, I found the clock said Aug 2014 and visually could see that the clock was advancing at a rate of about 2 HR per actual second. The Meinberg screen said it was locked into the local clock and the Meinberg screen appeared to be updating about twice per second rather than once ever 10 seconds. It said that the preferred clock was LOCL 127.127.1.1. I don't know what the heck happened, but these anomalies are getting really old. Hopefully the Sure board will do better. Oh, by the way, I shut down NTPD and the clock kept advancing the same way. 2 reboots appear to have fixed it. I've removed LOCL from the config file. Here are some links to some log and conf files if anyone is interested. Note the dates at the end. I've got 1200 log files in between these start and end dates. http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock note the date far into the future http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock note the date far into the future http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock Sincerely Frustrated, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Tue, Mar 20, 2012 at 03:56, Ron Frazier (NTP) wrote: > Hi Dave H, > > Thanks for the info and for looking into the issue. I meant that the clock > was psycho, not the PC. Right, I got that. You were ever so politely screaming for attention regarding software I volunteer to help maintain. How may I snap to your service? > The PC is normally very tame and cooperative, as cooperative as Windows > gets anyway. These GPS experiments have certainly brought several > surprises though. > > I run both Windows and Ubuntu Linux, but in this case, the system is: > > Windows 7 Home Premium SP 1 > NTPD 4.2.7p259 > > LOCL has been removed. However, that brings up a question. Since I'm doing > tests with the internet clocks noselected (but still monitoring them), and > the GPS is the only selectable clock, what happens if it becomes invalid? > The whole reason I put LOCL in there was to allow the machine to "coast" if > the GPS signal became invalid. The behavior of the local clock discipline is not any different with no selectable sources than with only the LOCAL driver selectable. Where it makes a difference is clients will not continue to follow a ntpd server which has no selectable sources, but will follow one using LOCAL as a fallback. Your machine will freewheel the same either way. Only clients will care about the difference, and if that's an issue, orphan mode may provide a more resilient solution. Still, as much as I doubt using the LOCAL clock driver is optimal for you, I know a lot of people are in the habit and want ntpd to behave well even when that driver is in use, regardless of my opinion of its utility in that case :) > How would I go about checking the event log? Using the Event Viewer, eventvwr from a command line or right-click on Computer and select Manage. Good luck, Dave Hart > On 3/19/2012 10:59 PM, Dave Hart wrote: >> >> Ron, >> >> I don't know what the heck happened either, but there are a few clues. >> You didn't tell us which version of ntpd you're using or which OS >> it's running on. Skimming the huge ntp.conf for non-comment lines I >> see it appears to be some version of Windows. >> >> Take note of the last line in the first loopstats file you sent: >> >> 56005 85287.065 -1.#IND0 -1.#IO 0.003538719 -1.#IND00 3 >> >> There is no activity in the corresponding peerstats file to give a >> hint what sent your offset and frequency off the deep end. You might >> check the eventlog around the end of the 19th UTC to see if there are >> any clues there. >> >> Although it's the first time I've seen such, it appears the offset and >> frequency calculations both ended up overflowing. I would have >> guessed bad input should have appeared in peerstats before loopstats >> but I didn't find anything unusual. It does appear the GPS was >> unplugged or stopped sending or sent sentences indicating no lock, >> based on the last peerstats entry for 127.127.20.5 occurring almost >> exactly 5 minutes before the overflow event. >> >> Probably we should just write it off as nominal since the PC is >> described as psycho. >> >> Take care, >> Dave Hart >> >> On Tue, Mar 20, 2012 at 01:59, Ron Frazier (NTP) >> wrote: >> >>> >>> Hi all, >>> >>> I just came home from supper to the most NOT charming experience. I had >>> left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I >>> came home, I found the clock said Aug 2014 and visually could see that >>> the >>> clock was advancing at a rate of about 2 HR per actual second. The >>> Meinberg >>> screen said it was locked into the local clock and the Meinberg screen >>> appeared to be updating about twice per second rather than once ever 10 >>> seconds. It said that the preferred clock was LOCL 127.127.1.1. I don't >>> know what the heck happened, but these anomalies are getting really old. >>> Hopefully the Sure board will do better. Oh, by the way, I shut down >>> NTPD >>> and the clock kept advancing the same way. 2 reboots appear to have >>> fixed >>> it. I've removed LOCL from the config file. Here are some links to some >>> log and conf files if anyone is interested. Note the dates at the end. >>> I've got 1200 log files in between these start and end dates. >>> >>> http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock >>> >>> >>> http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock >>> note >>> the date far into the future >>> http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock >>> >>> >>> http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clo
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, Ron Frazier (NTP) wrote: > Hi all, > > I just came home from supper to the most NOT charming experience. I had > left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I > came home, I found the clock said Aug 2014 and visually could see that > the clock was advancing at a rate of about 2 HR per actual second. The > Meinberg screen said it was locked into the local clock and the Meinberg And you have local clock anywhere in the configuration why? It is dumb as you have discovered. > screen appeared to be updating about twice per second rather than once > ever 10 seconds. It said that the preferred clock was LOCL > 127.127.1.1. I don't know what the heck happened, but these anomalies > are getting really old. Hopefully the Sure board will do better. Oh, > by the way, I shut down NTPD and the clock kept advancing the same way. It sounds like the system has reset the timer interrupt advance. > 2 reboots appear to have fixed it. I've removed LOCL from the config > file. Here are some links to some log and conf files if anyone is > interested. Note the dates at the end. I've got 1200 log files in > between these start and end dates. > > http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock > > http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock > http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock > note the date far into the future > http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock > > http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock > http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock > note the date far into the future > http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock > > Sincerely Frustrated, > > Ron > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 12:11 AM, Dave Hart wrote: On Tue, Mar 20, 2012 at 03:56, Ron Frazier (NTP) wrote: Hi Dave H, Thanks for the info and for looking into the issue. I meant that the clock was psycho, not the PC. Right, I got that. You were ever so politely screaming for attention regarding software I volunteer to help maintain. How may I snap to your service? I certainly didn't mean any offense by anything I said, and apologize if any was perceived. OK, this event freaked me out. I almost felt like screaming. Watching the hands on the windows graphical clock image spin rapidly around was making me wonder if the PC was haunted or something, or had a virus, or had bad RAM, or a bad HDD, none of which I wanted to think about. I have been very surprised with the apparent unreliability of GPS sometimes. This one in particular seems to wander off from UTC and have periodic heart attacks. It's been a big surprise to me. This is strange and weird stuff to a timekeeping newbie. I really DO appreciate your (and other people's) assistance. 8-) The only thing I could think of to do was post the experience on the list in case someone could shed some light on it. The PC is normally very tame and cooperative, as cooperative as Windows gets anyway. These GPS experiments have certainly brought several surprises though. I run both Windows and Ubuntu Linux, but in this case, the system is: Windows 7 Home Premium SP 1 NTPD 4.2.7p259 LOCL has been removed. However, that brings up a question. Since I'm doing tests with the internet clocks noselected (but still monitoring them), and the GPS is the only selectable clock, what happens if it becomes invalid? The whole reason I put LOCL in there was to allow the machine to "coast" if the GPS signal became invalid. The behavior of the local clock discipline is not any different with no selectable sources than with only the LOCAL driver selectable. Where it makes a difference is clients will not continue to follow a ntpd server which has no selectable sources, but will follow one using LOCAL as a fallback. Your machine will freewheel the same either way. Only clients will care about the difference, and if that's an issue, orphan mode may provide a more resilient solution. Still, as much as I doubt using the LOCAL clock driver is optimal for you, I know a lot of people are in the habit and want ntpd to behave well even when that driver is in use, regardless of my opinion of its utility in that case :) LOCL is gone. Since you say the system can freewheel either way, I'll probably leave it gone. I had specifically hoped it would prevent problems in case the GPS went crazy. I guess I was mistaken. Since I dual boot between Windows and Linux, eventually, I hope to have each PC capable of using a GPS, no matter which OS is running, and one PC designated as my master clock, no matter which OS is running. The master clock would prefer the GPS first, then internet servers. The other PC's would prefer the GPS first (if attached), then my master clock, then internet servers. Just for curiosity, is there any difference between 127.127.1.1 and 127.127.1.0? Sincerely, Ron How would I go about checking the event log? Using the Event Viewer, eventvwr from a command line or right-click on Computer and select Manage. Good luck, Dave Hart On 3/19/2012 10:59 PM, Dave Hart wrote: Ron, I don't know what the heck happened either, but there are a few clues. You didn't tell us which version of ntpd you're using or which OS it's running on. Skimming the huge ntp.conf for non-comment lines I see it appears to be some version of Windows. Take note of the last line in the first loopstats file you sent: 56005 85287.065 -1.#IND0 -1.#IO 0.003538719 -1.#IND00 3 There is no activity in the corresponding peerstats file to give a hint what sent your offset and frequency off the deep end. You might check the eventlog around the end of the 19th UTC to see if there are any clues there. Although it's the first time I've seen such, it appears the offset and frequency calculations both ended up overflowing. I would have guessed bad input should have appeared in peerstats before loopstats but I didn't find anything unusual. It does appear the GPS was unplugged or stopped sending or sent sentences indicating no lock, based on the last peerstats entry for 127.127.20.5 occurring almost exactly 5 minutes before the overflow event. Probably we should just write it off as nominal since the PC is described as psycho. Take care, Dave Hart On Tue, Mar 20, 2012 at 01:59, Ron Frazier (NTP) wrote: Hi all, I just came home from supper to the most NOT charming experience. I had left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I came home, I found the clock said Aug 2014 and visually could see that the clock was advancing at a rate of about 2 HR per actual second. The Mei
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 12:09 AM, unruh wrote: On 2012-03-20, Ron Frazier (NTP) wrote: Hi all, I just came home from supper to the most NOT charming experience. I had left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I came home, I found the clock said Aug 2014 and visually could see that the clock was advancing at a rate of about 2 HR per actual second. The Meinberg screen said it was locked into the local clock and the Meinberg And you have local clock anywhere in the configuration why? It is dumb as you have discovered. I've been testing with everything noselected but the GPS, but still monitoring the internet servers. I had hoped LOCL would allow the system to continue running gracefully, if not accurately, if the GPS went crazy. I guess it didn't do that. LOCL is now gone. screen appeared to be updating about twice per second rather than once ever 10 seconds. It said that the preferred clock was LOCL 127.127.1.1. I don't know what the heck happened, but these anomalies are getting really old. Hopefully the Sure board will do better. Oh, by the way, I shut down NTPD and the clock kept advancing the same way. It sounds like the system has reset the timer interrupt advance. 2 reboots appear to have fixed it. I've removed LOCL from the config file. Here are some links to some log and conf files if anyone is interested. Note the dates at the end. I've got 1200 log files in between these start and end dates. http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock note the date far into the future http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock note the date far into the future http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock Sincerely Frustrated, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, Ron Frazier (NTP) wrote: > On 3/20/2012 12:09 AM, unruh wrote: >> On 2012-03-20, Ron Frazier (NTP) wrote: >> >>> Hi all, >>> >>> I just came home from supper to the most NOT charming experience. I had >>> left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I >>> came home, I found the clock said Aug 2014 and visually could see that >>> the clock was advancing at a rate of about 2 HR per actual second. The >>> Meinberg screen said it was locked into the local clock and the Meinberg >>> >> And you have local clock anywhere in the configuration why? It is dumb >> as you have discovered. >> >> > > I've been testing with everything noselected but the GPS, but still > monitoring the internet servers. I had hoped LOCL would allow the > system to continue running gracefully, if not accurately, if the GPS > went crazy. I guess it didn't do that. LOCL is now gone. > Of course the question still is why in the world did the system go nuts when it was on Local. That itself should not have happened. >>> screen appeared to be updating about twice per second rather than once >>> ever 10 seconds. It said that the preferred clock was LOCL >>> 127.127.1.1. I don't know what the heck happened, but these anomalies >>> are getting really old. Hopefully the Sure board will do better. Oh, >>> by the way, I shut down NTPD and the clock kept advancing the same way. >>> >> It sounds like the system has reset the timer interrupt advance. >> >> >>> 2 reboots appear to have fixed it. I've removed LOCL from the config >>> file. Here are some links to some log and conf files if anyone is >>> interested. Note the dates at the end. I've got 1200 log files in >>> between these start and end dates. >>> >>> http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock >>> >>> http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock >>> note the date far into the future >>> http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock >>> >>> http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock >>> note the date far into the future >>> http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock >>> >>> Sincerely Frustrated, >>> >>> Ron >>> > > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, Ron Frazier (NTP) wrote: > Hi Dave H, > > Thanks for the info and for looking into the issue. I meant that the > clock was psycho, not the PC. The PC is normally very tame and > cooperative, as cooperative as Windows gets anyway. These GPS > experiments have certainly brought several surprises though. > > I run both Windows and Ubuntu Linux, but in this case, the system is: > > Windows 7 Home Premium SP 1 > NTPD 4.2.7p259 > > LOCL has been removed. However, that brings up a question. Since I'm > doing tests with the internet clocks noselected (but still monitoring > them), and the GPS is the only selectable clock, what happens if it > becomes invalid? The whole reason I put LOCL in there was to allow the > machine to "coast" if the GPS signal became invalid. It will coast on its own. There are millions of machines out there that do not run ntpd and keep time reasonably well. They "coast" fine. > > How would I go about checking the event log? > > Sincerely, > > Ron > > > On 3/19/2012 10:59 PM, Dave Hart wrote: >> Ron, >> >> I don't know what the heck happened either, but there are a few clues. >> You didn't tell us which version of ntpd you're using or which OS >> it's running on. Skimming the huge ntp.conf for non-comment lines I >> see it appears to be some version of Windows. >> >> Take note of the last line in the first loopstats file you sent: >> >> 56005 85287.065 -1.#IND0 -1.#IO 0.003538719 -1.#IND00 3 >> >> There is no activity in the corresponding peerstats file to give a >> hint what sent your offset and frequency off the deep end. You might >> check the eventlog around the end of the 19th UTC to see if there are >> any clues there. >> >> Although it's the first time I've seen such, it appears the offset and >> frequency calculations both ended up overflowing. I would have >> guessed bad input should have appeared in peerstats before loopstats >> but I didn't find anything unusual. It does appear the GPS was >> unplugged or stopped sending or sent sentences indicating no lock, >> based on the last peerstats entry for 127.127.20.5 occurring almost >> exactly 5 minutes before the overflow event. >> >> Probably we should just write it off as nominal since the PC is >> described as psycho. >> >> Take care, >> Dave Hart >> >> On Tue, Mar 20, 2012 at 01:59, Ron Frazier (NTP) >> wrote: >> >>> Hi all, >>> >>> I just came home from supper to the most NOT charming experience. I had >>> left with my PC clock syncing nicely to my Globalsat BU-353 GPS. When I >>> came home, I found the clock said Aug 2014 and visually could see that the >>> clock was advancing at a rate of about 2 HR per actual second. The Meinberg >>> screen said it was locked into the local clock and the Meinberg screen >>> appeared to be updating about twice per second rather than once ever 10 >>> seconds. It said that the preferred clock was LOCL 127.127.1.1. I don't >>> know what the heck happened, but these anomalies are getting really old. >>> Hopefully the Sure board will do better. Oh, by the way, I shut down NTPD >>> and the clock kept advancing the same way. 2 reboots appear to have fixed >>> it. I've removed LOCL from the config file. Here are some links to some >>> log and conf files if anyone is interested. Note the dates at the end. >>> I've got 1200 log files in between these start and end dates. >>> >>> http://dl.dropbox.com/u/9879631/ntp.conf%20psycho%20clock >>> >>> http://dl.dropbox.com/u/9879631/loopstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120320%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120321%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120322%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20120323%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/loopstats.20140112%20psycho%20clock note >>> the date far into the future >>> http://dl.dropbox.com/u/9879631/loopstats.20140113%20psycho%20clock >>> >>> http://dl.dropbox.com/u/9879631/peerstats.20120319-2-above-priority-gpgga96-poll-3-6%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120320%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120321%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120322%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20120323%20psycho%20clock >>> http://dl.dropbox.com/u/9879631/peerstats.20140824%20psycho%20clock note >>> the date far into the future >>> http://dl.dropbox.com/u/9879631/peerstats.20140825%20psycho%20clock >>> >>> Sincerely Frustrated, >>> >>> Ron >>> > > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"unruh" wrote in message news:JDU9r.22132$_c5.11...@newsfe09.iad... [] Of course the question still is why in the world did the system go nuts when it was on Local. That itself should not have happened. If some software had told the system clock to run fast, it simply stays running fast, even on Local. Ron is using a single GPS device, over USB, without the backup of a few Internet servers to stop such a thing happening, and the GPS has already shown itself to be problematical. NTP would normally have simply rejected the errant GPS data and not cause the PC clock to run wild, but without the Internet servers as backup, what is NTP to do? I don't think it has a choice other than to believe the GPS, even if it's incorrect or faulty. Ron, perhaps in the future you could adopt a similar configuration to one I've mentioned before - add some Internet servers with a long polling interval as a second opinion for NTP: _ server server 0.us.pool.ntp.org minpoll 10 iburst server 1.us.pool.ntp.org minpoll 10 iburst server 0.uk.pool.ntp.org minpoll 10 iburst server 1.uk.pool.ntp.org minpoll 10 iburst _ using servers [network] local to yourself, of course. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Tue, Mar 20, 2012 at 02:59:12AM +, Dave Hart wrote: > Although it's the first time I've seen such, it appears the offset and > frequency calculations both ended up overflowing. I would have > guessed bad input should have appeared in peerstats before loopstats > but I didn't find anything unusual. This sounds familiar. Perhaps the OP is hitting the bug 2156 fixed recently? If the emulated adjtime on Windows doesn't apply the 500 ppm limit, it could have explained the huge frequency error. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 2:25 AM, David J Taylor wrote: "unruh" wrote in message news:JDU9r.22132$_c5.11...@newsfe09.iad... [] Of course the question still is why in the world did the system go nuts when it was on Local. That itself should not have happened. If some software had told the system clock to run fast, it simply stays running fast, even on Local. Ron is using a single GPS device, over USB, without the backup of a few Internet servers to stop such a thing happening, and the GPS has already shown itself to be problematical. NTP would normally have simply rejected the errant GPS data and not cause the PC clock to run wild, but without the Internet servers as backup, what is NTP to do? I don't think it has a choice other than to believe the GPS, even if it's incorrect or faulty. Ron, perhaps in the future you could adopt a similar configuration to one I've mentioned before - add some Internet servers with a long polling interval as a second opinion for NTP: _ server server 0.us.pool.ntp.org minpoll 10 iburst server 1.us.pool.ntp.org minpoll 10 iburst server 0.uk.pool.ntp.org minpoll 10 iburst server 1.uk.pool.ntp.org minpoll 10 iburst _ using servers [network] local to yourself, of course. Cheers, David Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop to the internet. Normally, that would be OK. However, as discussed previously, even my errant GPS is more accurate over the short term than the internet for me. With the internet conection, I get + / - 50 ms variations in time over a span of an our. With the GPS, I get + / - 60 ms variations over several days, with a few wild corrections during its heart attacks. Those are two bad choices, but I think I'd still rather run on the GPS. The only way I can prevent clock hopping is by noselecting the internet servers. Even if I end up with internet servers turned on, which I expect to, I think it's much better to know about these GPS anomalies before putting it into long term service. Anybody considering using a SIRF III or maybe even any SIRF unit for timekeeping should be warned by my experience, test the unit, and make sure it's up to the task. These problems could even affect SIRF units with PPS outputs, although I don't know. I'll probably decommission this unit from timekeeping duty and relegate it to navigation duty, although I'm not sure how trustworthy it is for that when it's throwing a temper tantrum. I've already committed to getting better (hopefully) equipment. (Shipping from Hong Kong or where ever seems to take a LONG time when you're waiting on something.) Hopefully, the Sure board will be much more stable and reliable. I'm planning to do the same extensive testing on the Sure for a week or two. I'll start out just plugging the Sure into my serial - USB converter using the same com port as the Globalsat unit was running on. I want to see how it does with NMEA only data for a while. I'm hoping NOT to see substantial drifting from UTC and NOT to see any heart attacks every few days. I expect lots of jitter, since a number of variable length sentences are being output. Then, I plan to turn off all but GPGGA and test some more, and maybe tinker with the baud rate. Then, if I can solder the board without killing it, I'll engage PPS through the serial - USB port and test that for a while. Then, I'll try it with PPS and real serial on my other computer, the only one with a serial port. Hopefully, when I'm done, I'll have a qualified unit running stably and accurately for the whole network to use. I've acquired a case and some hardware to mount the device similar to yours. Once I learned that it was only 3" x 3", that made me nervous as far as soldering and all, but we'll see what happens. By the way, do you think I should update to Dave H's latest binaries? I'm at 4.2.7p259 on Windows. Almost all these discussions have been about Windows. Linux is a whole other ballgame
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Tue, Mar 20, 2012 at 12:28, Miroslav Lichvar wrote: > On Tue, Mar 20, 2012 at 02:59:12AM +, Dave Hart wrote: >> Although it's the first time I've seen such, it appears the offset and >> frequency calculations both ended up overflowing. I would have >> guessed bad input should have appeared in peerstats before loopstats >> but I didn't find anything unusual. > > This sounds familiar. Perhaps the OP is hitting the bug 2156 fixed > recently? Very good point. He's using p259 which has bug 2156 which could trigger a divide by zero if the LOCAL driver is selected. p263 and later fix that bug. > If the emulated adjtime on Windows doesn't apply the 500 ppm > limit, it could have explained the huge frequency error. adj_systime() in ports/winnt/ntpd/nt_clockstuff.c does enforce 500 PPM limit on what it asks of Windows. In order to emulate adjtime() called at the beginning of frequency calibration to eliminate the entire initial offset, any correction of greater magnitude than 500 us results in 500 us being applied and the remainder carried over to the next once-per-second adj_systime(). On balance, I don't think bug 2156 explains what Ron reported. The division by zero in question wouldn't have resulted in the loopstats offset and frequency being -1.#IND (which is, BTW, slightly odd -- there are more references to -1.#INF and 1.#IND) and -1.#IO. Also, even with a wildly unpredictable or large argument passed to adj_systime(), no more than 500 PPM should make it through to Windows. David Taylor is right that it is normal for Windows to keep running the clock at whatever rate was last set after the program setting the rate goes away. It's also true that Windows does not have any rate limits itself -- you can easily tell Windows to advance the clock 1 usec per tick (nominally 15.625 msec), one hour per tick. Unless I misread the nt_clockstuff.c code, it shouldn't be possible to get ntpd to set the Windows clock rate more than 500 PPM from nominal. Thanks, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"Ron Frazier (NTP)" wrote in message [] Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Run a Perl script one a minute, looking for the GPS line in ntpq -p output, and if the tally code isn't "*" (or whatever, get it to run: "net stop ntp" Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. It's not a time GPS, so one could argue that it's not to be trusted. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. Unlikely, as there are several GPS receivers with PPS outputs listed using that chipset. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop to the internet. Normally, that would be OK. However, as discussed previously, even my errant GPS is more accurate over the short term than the internet for me. With the internet conection, I get + / - 50 ms variations in time over a span of an our. With the GPS, I get + / - 60 ms variations over several days, with a few wild corrections during its heart attacks. Those are two bad choices, but I think I'd still rather run on the GPS. Your choice, of course. The only way I can prevent clock hopping is by noselecting the internet servers. What's the problem with the clock changing to Internet servers? It will change back again when the GPS returns to an acceptable state. Even if I end up with internet servers turned on, which I expect to, I think it's much better to know about these GPS anomalies before putting it into long term service. Anybody considering using a SIRF III or maybe even any SIRF unit for timekeeping should be warned by my experience, test the unit, and make sure it's up to the task. These problems could even affect SIRF units with PPS outputs, although I don't know. I'll probably decommission this unit from timekeeping duty and relegate it to navigation duty, although I'm not sure how trustworthy it is for that when it's throwing a temper tantrum. You want to say all SiRF chipsets are bad on the basis of testing one manufacturer's implementation, and in a way which the software supplier doesn't recommend? I've already committed to getting better (hopefully) equipment. (Shipping from Hong Kong or where ever seems to take a LONG time when you're waiting on something.) 2-3 weeks, and I'm an impatient sort as well! Hopefully, the Sure board will be much more stable and reliable. I'm planning to do the same extensive testing on the Sure for a week or two. I'll start out just plugging the Sure into my serial - USB converter using the same com port as the Globalsat unit was running on. I want to see how it does with NMEA only data for a while. I'm hoping NOT to see substantial drifting from UTC and NOT to see any heart attacks every few days. I expect lots of jitter, since a number of variable length sentences are being output. Then, I plan to turn off all but GPGGA and test some more, and maybe tinker with the baud rate. Then, if I can solder the board without killing it, I'll engage PPS through the serial - USB port and test that for a while. Then, I'll try it with PPS and real serial on my other computer, the only one with a serial port. You /will/ see variation in the serial output from the Sure device, as you will in many NMEA devices. For the Sure device, one measurement is here: http://www.leapsecond.com/pages/MG1613S/ under the heading "NMEA Latency". The graph here is 100 milliseconds full scale. http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif Hopefully, when I'm done, I'll have a qualified unit running stably and accurately for the whole network to use. I've acquired a case and some hardware to mount the device similar to yours. Once I learned that it was only 3" x 3", that made me nervous as far as soldering and all, but we'll see what happens. If in doubt, find someone who is used to working on such units. You could try Bill Unruh's suggestion to start with. By the way, do you think I should update to Dave H's latest binaries? I'm at 4.2.7p259 on Windows. Almost all these discussions have been about Windows. Linux is a whole other ballgame. The NTPD there from the repositories is about 2 years old, and I'm reluctant to go outside the repositories because of the numerous problems it creates. One very serious Linux user on a local message board said even he doesn't compile his own programs because
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
[] David Taylor is right that it is normal for Windows to keep running the clock at whatever rate was last set after the program setting the rate goes away. It's also true that Windows does not have any rate limits itself -- you can easily tell Windows to advance the clock 1 usec per tick (nominally 15.625 msec), one hour per tick. Unless I misread the nt_clockstuff.c code, it shouldn't be possible to get ntpd to set the Windows clock rate more than 500 PPM from nominal. Thanks, Dave Hart Dave, How does NTPD_TICKADJ_PPM affect this? If that was set to -800, for example, wouldn't the adjustment range be -300/-1300 rather than +/-500? Or are you including NTPD_TICKADJ_PPM in "nominal". Thanks, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Tue, Mar 20, 2012 at 15:55, David J Taylor wrote: > How does NTPD_TICKADJ_PPM affect this? If that was set to -800, for > example, wouldn't the adjustment range be -300/-1300 rather than +/-500? Yes, it would. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Ron Frazier (NTP) wrote: On 3/20/2012 2:25 AM, David J Taylor wrote: "unruh" wrote in message news:JDU9r.22132$_c5.11...@newsfe09.iad... [] Of course the question still is why in the world did the system go nuts when it was on Local. That itself should not have happened. If some software had told the system clock to run fast, it simply stays running fast, even on Local. Ron is using a single GPS device, over USB, without the backup of a few Internet servers to stop such a thing happening, and the GPS has already shown itself to be problematical. NTP would normally have simply rejected the errant GPS data and not cause the PC clock to run wild, but without the Internet servers as backup, what is NTP to do? I don't think it has a choice other than to believe the GPS, even if it's incorrect or faulty. Ron, perhaps in the future you could adopt a similar configuration to one I've mentioned before - add some Internet servers with a long polling interval as a second opinion for NTP: _ server server 0.us.pool.ntp.org minpoll 10 iburst server 1.us.pool.ntp.org minpoll 10 iburst server 0.uk.pool.ntp.org minpoll 10 iburst server 1.uk.pool.ntp.org minpoll 10 iburst _ using servers [network] local to yourself, of course. Cheers, David Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Easy, configure it that way. Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop NMEA gives me around +/- 10ms mean, 20-30ms rms and 40-80ms maximum PPS gives me around 0.000ms mean, 0.004ms rms and 0.015-0.035ms maximum Attempting to compare time vs NMEA offset doesn't get you anywhere. There are more productive ways of spending your time such as sorting out your wireless network or having a wired link to one pc to confirm if the delays you're seeing are due to the wireless network or your provider. David to the internet. Normally, that would be OK. However, as discussed previously, even my errant GPS is more accurate over the short term than the internet for me. With the internet conection, I get + / - 50 ms variations in time over a span of an our. With the GPS, I get + / - 60 ms variations over several days, with a few wild corrections during its heart attacks. Those are two bad choices, but I think I'd still rather run on the GPS. The only way I can prevent clock hopping is by noselecting the internet servers. Even if I end up with internet servers turned on, which I expect to, I think it's much better to know about these GPS anomalies before putting it into long term service. Anybody considering using a SIRF III or maybe even any SIRF unit for timekeeping should be warned by my experience, test the unit, and make sure it's up to the task. These problems could even affect SIRF units with PPS outputs, although I don't know. I'll probably decommission this unit from timekeeping duty and relegate it to navigation duty, although I'm not sure how trustworthy it is for that when it's throwing a temper tantrum. I've already committed to getting better (hopefully) equipment. (Shipping from Hong Kong or where ever seems to take a LONG time when you're waiting on something.) Hopefully, the Sure board will be much more stable and reliable. I'm planning to do the same extensive testing on the Sure for a week or two. I'll start out just plugging the Sure into my serial - USB converter using the same com port as the Globalsat unit was running on. I want to see how it does with NMEA only data for a while. I'm hoping NOT to see substantial drifting from UTC and NOT to see any heart attacks every few days. I expect lots of jitter, since a number of variable length sentences are being output. Then, I plan to turn off all but GPGGA and test some more, and maybe tinker with the baud rate. Then, if I can solder the board without killing it, I'll engage PPS through the serial - USB port and test that for a while. Then, I'll try it with PPS and real serial on my other computer, the only one with a serial port. Hope
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, David J Taylor wrote: > "unruh" wrote in message > news:JDU9r.22132$_c5.11...@newsfe09.iad... > [] >> Of course the question still is why in the world did the system go nuts >> when it was on Local. That itself should not have happened. > > If some software had told the system clock to run fast, it simply stays > running fast, even on Local. I have never had any machine whether running ntp, chrony or nothing, result in a machine running a factor of thousands too fast. There is nothing that I know of that would do that. Yes, if something told it to advance the clock one hour per clock tick, it would do it. But you beg the question, what would do that. > > Ron is using a single GPS device, over USB, without the backup of a few > Internet servers to stop such a thing happening, and the GPS has already > shown itself to be problematical. NTP would normally have simply rejected > the errant GPS data and not cause the PC clock to run wild, but without > the Internet servers as backup, what is NTP to do? I don't think it has a > choice other than to believe the GPS, even if it's incorrect or faulty. It is really really hard to imagine any gps device doing that. > > Ron, perhaps in the future you could adopt a similar configuration to one > I've mentioned before - add some Internet servers with a long polling > interval as a second opinion for NTP: > > _ > server > > server 0.us.pool.ntp.org minpoll 10 iburst > server 1.us.pool.ntp.org minpoll 10 iburst > server 0.uk.pool.ntp.org minpoll 10 iburst > server 1.uk.pool.ntp.org minpoll 10 iburst > _ > > > using servers [network] local to yourself, of course. > > Cheers, > David > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, Dave Hart wrote: > On Tue, Mar 20, 2012 at 12:28, Miroslav Lichvar wrote: >> On Tue, Mar 20, 2012 at 02:59:12AM +, Dave Hart wrote: >>> Although it's the first time I've seen such, it appears the offset and >>> frequency calculations both ended up overflowing. ?I would have >>> guessed bad input should have appeared in peerstats before loopstats >>> but I didn't find anything unusual. >> >> This sounds familiar. Perhaps the OP is hitting the bug 2156 fixed >> recently? > > Very good point. He's using p259 which has bug 2156 which could > trigger a divide by zero if the LOCAL driver is selected. p263 and > later fix that bug. > >> If the emulated adjtime on Windows doesn't apply the 500 ppm >> limit, it could have explained the huge frequency error. > > adj_systime() in ports/winnt/ntpd/nt_clockstuff.c does enforce 500 PPM > limit on what it asks of Windows. In order to emulate adjtime() > called at the beginning of frequency calibration to eliminate the > entire initial offset, any correction of greater magnitude than 500 us > results in 500 us being applied and the remainder carried over to the > next once-per-second adj_systime(). > > On balance, I don't think bug 2156 explains what Ron reported. The > division by zero in question wouldn't have resulted in the loopstats > offset and frequency being -1.#IND (which is, BTW, slightly odd -- > there are more references to -1.#INF and 1.#IND) and -1.#IO. Also, > even with a wildly unpredictable or large argument passed to > adj_systime(), no more than 500 PPM should make it through to Windows. > > David Taylor is right that it is normal for Windows to keep running > the clock at whatever rate was last set after the program setting the > rate goes away. It's also true that Windows does not have any rate > limits itself -- you can easily tell Windows to advance the clock 1 > usec per tick (nominally 15.625 msec), one hour per tick. Unless I > misread the nt_clockstuff.c code, it shouldn't be possible to get ntpd > to set the Windows clock rate more than 500 PPM from nominal. Presumably it could run away. It sets it at 500PPM on this cycle. The next reading then comes early and it again applies a 500PPM extra, etc. That would lead to an exponential runaway, and the hour per tick that he was seeing wouldn't it? > > Thanks, > Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, Ron Frazier (NTP) wrote: > On 3/20/2012 2:25 AM, David J Taylor wrote: >> "unruh" wrote in message >> news:JDU9r.22132$_c5.11...@newsfe09.iad... >> [] >>> Of course the question still is why in the world did the system go nuts >>> when it was on Local. That itself should not have happened. >> >> If some software had told the system clock to run fast, it simply >> stays running fast, even on Local. >> >> Ron is using a single GPS device, over USB, without the backup of a >> few Internet servers to stop such a thing happening, and the GPS has >> already shown itself to be problematical. NTP would normally have >> simply rejected the errant GPS data and not cause the PC clock to run >> wild, but without the Internet servers as backup, what is NTP to do? >> I don't think it has a choice other than to believe the GPS, even if >> it's incorrect or faulty. >> >> Ron, perhaps in the future you could adopt a similar configuration to >> one I've mentioned before - add some Internet servers with a long >> polling interval as a second opinion for NTP: >> >> _ >> server >> >> server 0.us.pool.ntp.org minpoll 10 iburst >> server 1.us.pool.ntp.org minpoll 10 iburst >> server 0.uk.pool.ntp.org minpoll 10 iburst >> server 1.uk.pool.ntp.org minpoll 10 iburst >> _ >> >> >> using servers [network] local to yourself, of course. >> >> Cheers, >> David >> > > Hi David T, > > Eventually, I do plan to have the server preferences as follows: > > Time server machine: > > GPS > Internet as backup > > Hypothetically speaking, what if I don't want it to distribute time if > it's working in internet mode? > > Non time server machines > > GPS (if attached) > Local time server (if available) Sorry to shout but NONONONONONONONONONO. Do not use Local time server ever, if by local time server you mean LOCL. If you mean a time server on your LAN, that is of course fine. > Internet as backup > > However, I only plan to do that after thoroughly testing the GPS by > itself for a week or two to see if it's stable. I originally had the > internet servers on with this unit. It completely surprised me by > having this tendency to drift apparently and have periodic heart > attacks. Unfortunately, this odd behavior may exist in all SIRF III and > possibly other SIRF units. It was only by turning off the internet > servers that I was able to get some clean graphs of exactly what the GPS > was doing. When I had the internet servers enabled, once the GPS > starting acting odd, which it shouldn't do at all, NTPD would clock hop > to the internet. Normally, that would be OK. However, as discussed > previously, even my errant GPS is more accurate over the short term than > the internet for me. With the internet conection, I get + / - 50 ms > variations in time over a span of an our. With the GPS, I get + / - 60 > ms variations over several days, with a few wild corrections during its > heart attacks. Those are two bad choices, but I think I'd still rather > run on the GPS. The only way I can prevent clock hopping is by > noselecting the internet servers. Even if I end up with internet > servers turned on, which I expect to, I think it's much better to know > about these GPS anomalies before putting it into long term service. > Anybody considering using a SIRF III or maybe even any SIRF unit for > timekeeping should be warned by my experience, test the unit, and make > sure it's up to the task. These problems could even affect SIRF units > with PPS outputs, although I don't know. I'll probably decommission > this unit from timekeeping duty and relegate it to navigation duty, > although I'm not sure how trustworthy it is for that when it's throwing > a temper tantrum. > > I've already committed to getting better (hopefully) equipment. > (Shipping from Hong Kong or where ever seems to take a LONG time when > you're waiting on something.) Hopefully, the Sure board will be much > more stable and reliable. I'm planning to do the same extensive testing Some apparently ship with bad antennas. Mine craps out often (delivering nothing to the unit) maybe some internal loose connection? (th blue light stops blinking). > on the Sure for a week or two. I'll start out just plugging the Sure > into my serial - USB converter using the same com port as the Globalsat > unit was running on. I want to see how it does with NMEA only data for > a while. I'm hoping NOT to see substantial drifting from UTC and NOT to > see any heart attacks every few days. I expect lots of jitter, since a > number of variable length sentences are being output. Then, I plan to > turn off all but GPGGA and test some more, and maybe tinker with the > baud rate. Then, if I can solder the board without killing it, I'll > engage PPS through the serial - USB port and test that for a while. > Then, I
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"unruh" wrote in message news:d13ar.7952$gv1.7...@newsfe12.iad... [] It is really really hard to imagine any gps device doing that. Yes, I agree, and yet what just popped up in my mail box but a reference to: "an inexplicable 1 second slip of 3 GPS based NTP time sources". I have, of course, asked for more details! Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 1:25 PM, unruh wrote: On 2012-03-20, Ron Frazier (NTP) wrote: On 3/20/2012 2:25 AM, David J Taylor wrote: "unruh" wrote in message news:JDU9r.22132$_c5.11...@newsfe09.iad... [] Of course the question still is why in the world did the system go nuts when it was on Local. That itself should not have happened. If some software had told the system clock to run fast, it simply stays running fast, even on Local. Ron is using a single GPS device, over USB, without the backup of a few Internet servers to stop such a thing happening, and the GPS has already shown itself to be problematical. NTP would normally have simply rejected the errant GPS data and not cause the PC clock to run wild, but without the Internet servers as backup, what is NTP to do? I don't think it has a choice other than to believe the GPS, even if it's incorrect or faulty. Ron, perhaps in the future you could adopt a similar configuration to one I've mentioned before - add some Internet servers with a long polling interval as a second opinion for NTP: _ server server 0.us.pool.ntp.org minpoll 10 iburst server 1.us.pool.ntp.org minpoll 10 iburst server 0.uk.pool.ntp.org minpoll 10 iburst server 1.uk.pool.ntp.org minpoll 10 iburst _ using servers [network] local to yourself, of course. Cheers, David Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Non time server machines GPS (if attached) Local time server (if available) Sorry to shout but NONONONONONONONONONO. Do not use Local time server ever, if by local time server you mean LOCL. If you mean a time server on your LAN, that is of course fine. Poor choice of words. I meant LAN in that case. Ron Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop to the internet. Normally, that would be OK. However, as discussed previously, even my errant GPS is more accurate over the short term than the internet for me. With the internet conection, I get + / - 50 ms variations in time over a span of an our. With the GPS, I get + / - 60 ms variations over several days, with a few wild corrections during its heart attacks. Those are two bad choices, but I think I'd still rather run on the GPS. The only way I can prevent clock hopping is by noselecting the internet servers. Even if I end up with internet servers turned on, which I expect to, I think it's much better to know about these GPS anomalies before putting it into long term service. Anybody considering using a SIRF III or maybe even any SIRF unit for timekeeping should be warned by my experience, test the unit, and make sure it's up to the task. These problems could even affect SIRF units with PPS outputs, although I don't know. I'll probably decommission this unit from timekeeping duty and relegate it to navigation duty, although I'm not sure how trustworthy it is for that when it's throwing a temper tantrum. I've already committed to getting better (hopefully) equipment. (Shipping from Hong Kong or where ever seems to take a LONG time when you're waiting on something.) Hopefully, the Sure board will be much more stable and reliable. I'm planning to do the same extensive testing Some apparently ship with bad antennas. Mine craps out often (delivering nothing to the unit) maybe some internal loose connection? (th blue light stops blinking). on the Sure for a week or two. I'll start out just plugging the Sure into my serial - USB converter using the same com port as the Globalsat unit was running on. I want to see how it does with NMEA only data for a while. I'm hoping NOT to see substantial drifting from UTC and NOT to see any heart attacks every few days. I expect lots of jitter, since a number of variable length sentences are being output. Then, I plan to turn off all but GPGGA and test some more, and maybe tinker with the baud rate. Then, if I can solder the board without killing it, I'll engage PPS through the serial - USB port and test that for a while. Then, I'll try it with PPS and real serial on my other computer, the only one with a serial port. Hopefully, when I
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Tue, Mar 20, 2012 at 17:28, unruh wrote: > On 2012-03-20, Dave Hart wrote: >> David Taylor is right that it is normal for Windows to keep running >> the clock at whatever rate was last set after the program setting the >> rate goes away. It's also true that Windows does not have any rate >> limits itself -- you can easily tell Windows to advance the clock 1 >> usec per tick (nominally 15.625 msec), one hour per tick. Unless I >> misread the nt_clockstuff.c code, it shouldn't be possible to get ntpd >> to set the Windows clock rate more than 500 PPM from nominal. > > Presumably it could run away. It sets it at 500PPM on this cycle. The > next reading then comes early and it again applies a 500PPM extra, etc. > That would lead to an exponential runaway, and the hour per tick that he > was seeing wouldn't it? No, frequency adjustments aren't compounded like that. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Hi David L, See below. On 3/20/2012 1:00 PM, David Lord wrote: Ron Frazier (NTP) wrote: On 3/20/2012 2:25 AM, David J Taylor wrote: "unruh" wrote in message news:JDU9r.22132$_c5.11...@newsfe09.iad... [] Of course the question still is why in the world did the system go nuts when it was on Local. That itself should not have happened. If some software had told the system clock to run fast, it simply stays running fast, even on Local. Ron is using a single GPS device, over USB, without the backup of a few Internet servers to stop such a thing happening, and the GPS has already shown itself to be problematical. NTP would normally have simply rejected the errant GPS data and not cause the PC clock to run wild, but without the Internet servers as backup, what is NTP to do? I don't think it has a choice other than to believe the GPS, even if it's incorrect or faulty. Ron, perhaps in the future you could adopt a similar configuration to one I've mentioned before - add some Internet servers with a long polling interval as a second opinion for NTP: _ server server 0.us.pool.ntp.org minpoll 10 iburst server 1.us.pool.ntp.org minpoll 10 iburst server 0.uk.pool.ntp.org minpoll 10 iburst server 1.uk.pool.ntp.org minpoll 10 iburst _ using servers [network] local to yourself, of course. Cheers, David Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Easy, configure it that way. I'm not sure how to do that within the confines of ntp.conf. David T. suggested I could run a Perl script every minute to shut down NTP if the GPS fails. But, I'd rather keep NTP running and just not distribute time on the LAN when my time server is polling the internet. Which brings up a question. If my time server on my LAN is attached to the GPS, that GPS is considered stratum zero and my time server on the LAN appears to be a stratum 1 device to other computers, right? Then, what if the time server stops using the GPS and begins using internet stratum 2 servers as it's time source? Does my LAN time server now present itself as a stratum 3 device to the other PC's on the LAN? If so, they might automatically stop using it and poll the internet stratum 2 servers themselves. That would be fine. Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop NMEA gives me around +/- 10ms mean, 20-30ms rms and 40-80ms maximum PPS gives me around 0.000ms mean, 0.004ms rms and 0.015-0.035ms maximum Attempting to compare time vs NMEA offset doesn't get you anywhere. There are more productive ways of spending your time such as sorting out your wireless network or having a wired link to one pc to confirm if the delays you're seeing are due to the wireless network or your provider. David The first thing a timekeeping newbie like me hears when asking about accurate PC timekeeping is "go hang a GPS on it". So, back when I started experimenting in January, and without the benefit of 2 months of banging my head on this wall and all these discussions, I go to Amazon, find a cheap GPS with good reviews, and buy it. I hook it up, configure NTP, and start getting + / - 10 ms of offsets of the PC versus GPS time. Since I think GPS time = UTC time, for most practical purposes, I'm happy. For my particular purposes, + / - 10 ms is fine. I plan to pursue PPS mostly for learning reasons, but I don't have to have microsecond level accuracy. I just want my PC's clocks to be right to less than 500 ms but would really prefer less than 10 ms. I also want to be doing better than the + / - 50 ms I'm getting from the internet at the moment. Another goal of having the GPS was possibly to poll the internet less often. Now, only after 2 months of head banging and discussions, do I find that the NMEA data is wandering. So, since I could live with NMEA only if it didn't wander, even though it only give + / - 10 ms accuracy, the question on my mind is: Does only this GPS wander? Evidence is no. Others wander. David T mentioned a wandering Garmin
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, David J Taylor wrote: > "unruh" wrote in message > news:d13ar.7952$gv1.7...@newsfe12.iad... > [] >> It is really really hard to imagine any gps device doing that. > > Yes, I agree, and yet what just popped up in my mail box but a reference > to: > > "an inexplicable 1 second slip of 3 GPS based NTP time sources". > > I have, of course, asked for more details! A one second slip I could understand-- eg Gamin 18x reporting over 1 second after the associated second would lead to that. But a computer advancing at an hour per tick is way beyond that. Perhaps the 1 second slip tickled a bug in ntp with the LOCL clock-- where the system then saw the GPS as a false ticker, went to LOCAL with a bad rate, and compounded the rate error by some sort of runaway process. > > Cheers, > David > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"unruh" wrote in message news:Ur4ar.15722$iq1.15...@newsfe18.iad... On 2012-03-20, David J Taylor wrote: "unruh" wrote in message news:d13ar.7952$gv1.7...@newsfe12.iad... [] It is really really hard to imagine any gps device doing that. Yes, I agree, and yet what just popped up in my mail box but a reference to: "an inexplicable 1 second slip of 3 GPS based NTP time sources". I have, of course, asked for more details! A one second slip I could understand-- eg Gamin 18x reporting over 1 second after the associated second would lead to that. But a computer advancing at an hour per tick is way beyond that. Perhaps the 1 second slip tickled a bug in ntp with the LOCL clock-- where the system then saw the GPS as a false ticker, went to LOCAL with a bad rate, and compounded the rate error by some sort of runaway process. You are confusing two events here. Ron had a problem with the PC running fast. This was a separate incident where there was a 1 second slippage. When and if I get more details I will post them here. There is no suggestion that the two are related. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Ron, I think the below is "correct enough" but accuracy is only one dimension of NTP server performance.As you have found one other dimension is "reliability". It does little good to have a system that is running at pico-second level But jumps ahead two years at rare unpredictable times. (It is kind of like the race car that goes 200MPH but the engine blows every third race.) It would be interesting to make a table like yours but to list varying degrees of reliability. On Tue, Mar 20, 2012 at 12:09 PM, Ron Frazier (NTP) > > Speaking only regarding Windows systems for a moment: > > So, let's say a person needs + / - 100 ms performance from UTC. He can > use the internet, even with wireless, and multiple routers, like I have. > Or he could use even a USB only GPS if there is a reason. > > Say he needs + / - 20 ms performance. Internet may be an option depending > on the circumstances. GPS might be a better option depending on the GPS. > > Say he needs + / - 1 ms performance. Internet is probably not an option, > at least in my experience and my location. USB only GPS with PPS through > the serial - USB converter might work. Serial GPS with PPS would work. > > Say he needs + / - 20 us performance. Excluding the realm of rubidium > standards and such, serial GPS with PPS is probably the only option. > > Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, David J Taylor wrote: > "unruh" wrote in message > news:Ur4ar.15722$iq1.15...@newsfe18.iad... >> On 2012-03-20, David J Taylor >> wrote: >>> "unruh" wrote in message >>> news:d13ar.7952$gv1.7...@newsfe12.iad... >>> [] It is really really hard to imagine any gps device doing that. >>> >>> Yes, I agree, and yet what just popped up in my mail box but a >>> reference >>> to: >>> >>> "an inexplicable 1 second slip of 3 GPS based NTP time sources". >>> >>> I have, of course, asked for more details! >> >> A one second slip I could understand-- eg Gamin 18x reporting over 1 >> second after the associated second would lead to that. But a computer >> advancing at an hour per tick is way beyond that. >> Perhaps the 1 second slip tickled a bug in ntp with the LOCL clock-- >> where the system then saw the GPS as a false ticker, went to LOCAL with >> a bad rate, and compounded the rate error by some sort of runaway >> process. > > You are confusing two events here. Ron had a problem with the PC running > fast. This was a separate incident where there was a 1 second slippage. > When and if I get more details I will post them here. There is no > suggestion that the two are related. No confusion. I understood completely. Ron had a machine on GPS which ran away. You got a report of a 1 sec slippage. The question is whether or not a 1 sec slippage in the GPS could trigger a runaway on a machine which also had LOCL as a server. I simply do not believe that the GPS sudenly went wild and delivered time at a rate 1000 times the UTC rate. Something on his system triggered and instability, and all he had running was a GPS and the LOCL server. Now, usually the machine would take the GPS signal and it certainly could not engage in that kind of runaway behaviour. It could however engage in something like a 1 sec slippage. How could that trigger an instability? > > Cheers, > David > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, Dave Hart wrote: > On Tue, Mar 20, 2012 at 17:28, unruh wrote: >> On 2012-03-20, Dave Hart wrote: >>> David Taylor is right that it is normal for Windows to keep running >>> the clock at whatever rate was last set after the program setting the >>> rate goes away. ?It's also true that Windows does not have any rate >>> limits itself -- you can easily tell Windows to advance the clock 1 >>> usec per tick (nominally 15.625 msec), one hour per tick. ?Unless I >>> misread the nt_clockstuff.c code, it shouldn't be possible to get ntpd >>> to set the Windows clock rate more than 500 PPM from nominal. >> >> Presumably it could run away. It sets it at 500PPM on this cycle. The >> next reading then comes early and it again applies a 500PPM extra, etc. >> That would lead to an exponential runaway, and the hour per tick that he >> was seeing wouldn't it? > > No, frequency adjustments aren't compounded like that. Lets hope not, but on his system, something DID trigger a runaway. So while frequency adjustments shouldn't be compounded like that, perhaps they were due to a bug in the ntpd software. > > Cheers, > Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Ron Frazier (NTP) wrote: Hi David L, See below. On 3/20/2012 1:00 PM, David Lord wrote: Ron Frazier (NTP) wrote: Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Easy, configure it that way. I'm not sure how to do that within the confines of ntp.conf. David T. suggested I could run a Perl script every minute to shut down NTP if the GPS fails. But, I'd rather keep NTP running and just not distribute time on the LAN when my time server is polling the internet. Which brings up a question. If my time server on my LAN is attached to the GPS, that GPS is considered stratum zero and my time server on the LAN appears to be a stratum 1 device to other computers, right? Then, what if the time server stops using the GPS and begins using internet stratum 2 servers as it's time source? Does my LAN time server now present itself as a stratum 3 device to the other PC's on the LAN? If so, they might automatically stop using it and poll the internet stratum 2 servers themselves. That would be fine. "ntpd" is not designed to be restarted often, either by scripts or by reboot to another operating system. If that is your requirement use ntpdate to get you perhaps within a second. Ntp.conf provides options to limit responses from ntpd. That begs the question, was your ntpd answering requests when your server was 50 seconds out? Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop NMEA gives me around +/- 10ms mean, 20-30ms rms and 40-80ms maximum PPS gives me around 0.000ms mean, 0.004ms rms and 0.015-0.035ms maximum Attempting to compare time vs NMEA offset doesn't get you anywhere. There are more productive ways of spending your time such as sorting out your wireless network or having a wired link to one pc to confirm if the delays you're seeing are due to the wireless network or your provider. David The first thing a timekeeping newbie like me hears when asking about accurate PC timekeeping is "go hang a GPS on it". So, back when I started experimenting in January, and without the benefit of 2 months of banging my head on this wall and all these discussions, I go to Amazon, find a cheap GPS with good reviews, and buy it. I hook it up, configure NTP, and start getting + / - 10 ms of offsets of the PC versus GPS time. Since I think GPS time = UTC time, for most practical purposes, I'm happy. For my particular purposes, + / - 10 ms is fine. I plan to Your perception of GPS time was understandably wrong. pursue PPS mostly for learning reasons, but I don't have to have microsecond level accuracy. I just want my PC's clocks to be right to less than 500 ms but would really prefer less than 10 ms. I also want to be doing better than the + / - 50 ms I'm getting from the internet at the moment. Another goal of having the GPS was possibly to poll the internet less often. Now, only after 2 months of head banging and discussions, do I find that the NMEA data is wandering. My NMEA time data wanders. It is not broken, the NMEA spec is for the time data to be accurate to within one second. If you require millisecond offset from GPS you need to use PPS which will give timing within a few microseconds. Otherwise if you still want to use NMEA rather than internet servers you need to configure ntpd to accept the larger variations in offset without dumping the source as false-ticker. David So, since I could live with NMEA only if it didn't wander, even though it only give + / - 10 ms accuracy, the question on my mind is: Does only this GPS wander? Evidence is no. Others wander. David T mentioned a wandering Garmin and someone on another list mentioned another SIRF unit that does it? Do all SIRF GPS's wander? Very possible, but evidence that I have is inconclusive. Do all NMEA outputs on all GPS's everywhere wander? I don't know about that. I think it's important to have this discussion, and I think it's important that it goes on these public lists. If it turns out to be true that almost no GPS with NMEA only output, or with PPS but that's not used, will ever provide more tha
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
unruh wrote: > Dave Hart wrote: >> frequency adjustments aren't compounded like that. > > Lets hope not, but on his system, something DID trigger a runaway. What about power saving frequency management of the core NTP is using? -- E-Mail Sent to this address will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-20, David Lord wrote: > Ron Frazier (NTP) wrote: >> Hi David L, >> >> See below. >> >> On 3/20/2012 1:00 PM, David Lord wrote: >>> Ron Frazier (NTP) wrote: > > > Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? >>> >>> >>> Easy, configure it that way. >>> >> >> I'm not sure how to do that within the confines of ntp.conf. David T. >> suggested I could run a Perl script every minute to shut down NTP if the >> GPS fails. But, I'd rather keep NTP running and just not distribute >> time on the LAN when my time server is polling the internet. Which >> brings up a question. If my time server on my LAN is attached to the >> GPS, that GPS is considered stratum zero and my time server on the LAN >> appears to be a stratum 1 device to other computers, right? Then, what >> if the time server stops using the GPS and begins using internet stratum >> 2 servers as it's time source? Does my LAN time server now present >> itself as a stratum 3 device to the other PC's on the LAN? If so, they >> might automatically stop using it and poll the internet stratum 2 >> servers themselves. That would be fine. > > "ntpd" is not designed to be restarted often, either by > scripts or by reboot to another operating system. If that > is your requirement use ntpdate to get you perhaps within > a second. > > Ntp.conf provides options to limit responses from ntpd. > > That begs the question, was your ntpd answering requests > when your server was 50 seconds out? Since all it has was LOCL as a time source, there is no reason why it shouldn't answer requests. For all it knew it was exactly on time. Every time it measured the offset, the offset was 0. That is pretty good timekeeping! :-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 5:19 PM, David Lord wrote: Ron Frazier (NTP) wrote: Hi David L, See below. On 3/20/2012 1:00 PM, David Lord wrote: Ron Frazier (NTP) wrote: Hi David T, Eventually, I do plan to have the server preferences as follows: Time server machine: GPS Internet as backup Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Easy, configure it that way. I'm not sure how to do that within the confines of ntp.conf. David T. suggested I could run a Perl script every minute to shut down NTP if the GPS fails. But, I'd rather keep NTP running and just not distribute time on the LAN when my time server is polling the internet. Which brings up a question. If my time server on my LAN is attached to the GPS, that GPS is considered stratum zero and my time server on the LAN appears to be a stratum 1 device to other computers, right? Then, what if the time server stops using the GPS and begins using internet stratum 2 servers as it's time source? Does my LAN time server now present itself as a stratum 3 device to the other PC's on the LAN? If so, they might automatically stop using it and poll the internet stratum 2 servers themselves. That would be fine. "ntpd" is not designed to be restarted often, either by scripts or by reboot to another operating system. If that is your requirement use ntpdate to get you perhaps within a second. Ntp.conf provides options to limit responses from ntpd. That begs the question, was your ntpd answering requests when your server was 50 seconds out? I don't currently have a server set up. I'm only testing on the one computer at the moment. Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop NMEA gives me around +/- 10ms mean, 20-30ms rms and 40-80ms maximum PPS gives me around 0.000ms mean, 0.004ms rms and 0.015-0.035ms maximum Attempting to compare time vs NMEA offset doesn't get you anywhere. There are more productive ways of spending your time such as sorting out your wireless network or having a wired link to one pc to confirm if the delays you're seeing are due to the wireless network or your provider. David The first thing a timekeeping newbie like me hears when asking about accurate PC timekeeping is "go hang a GPS on it". So, back when I started experimenting in January, and without the benefit of 2 months of banging my head on this wall and all these discussions, I go to Amazon, find a cheap GPS with good reviews, and buy it. I hook it up, configure NTP, and start getting + / - 10 ms of offsets of the PC versus GPS time. Since I think GPS time = UTC time, for most practical purposes, I'm happy. For my particular purposes, + / - 10 ms is fine. I plan to Your perception of GPS time was understandably wrong. pursue PPS mostly for learning reasons, but I don't have to have microsecond level accuracy. I just want my PC's clocks to be right to less than 500 ms but would really prefer less than 10 ms. I also want to be doing better than the + / - 50 ms I'm getting from the internet at the moment. Another goal of having the GPS was possibly to poll the internet less often. Now, only after 2 months of head banging and discussions, do I find that the NMEA data is wandering. My NMEA time data wanders. It is not broken, the NMEA spec is for the time data to be accurate to within one second. If you require millisecond offset from GPS you need to use PPS which will give timing within a few microseconds. Otherwise if you still want to use NMEA rather than internet servers you need to configure ntpd to accept the larger variations in offset without dumping the source as false-ticker. David So, since I could live with NMEA only if it didn't wander, even though it only give + / - 10 ms accuracy, the question on my mind is: Does only this GPS wander? Evidence is no. Others wander. David T mentioned a wandering Garmin and someone on another list mentioned another SIRF unit that does it? Do all SIRF GPS's wander? Very possible, but evidence that I have is inconclusive. Do all NMEA outputs on all GPS's everywhere wander? I don't know about that. I think it's important to have this discussion, and I think it's important that it goes on these publ
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 5:48 PM, E-Mail Sent to this address will be added to the BlackLists wrote: unruh wrote: Dave Hart wrote: frequency adjustments aren't compounded like that. Lets hope not, but on his system, something DID trigger a runaway. What about power saving frequency management of the core NTP is using? I doubt that's relevant. I currently have both min and max CPU speed set to 100% as someone mentioned it before. Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 11:21 AM, David J Taylor wrote: "Ron Frazier (NTP)" wrote in message [] Hypothetically speaking, what if I don't want it to distribute time if it's working in internet mode? Run a Perl script one a minute, looking for the GPS line in ntpq -p output, and if the tally code isn't "*" (or whatever, get it to run: "net stop ntp" Non time server machines GPS (if attached) Local time server (if available) Internet as backup However, I only plan to do that after thoroughly testing the GPS by itself for a week or two to see if it's stable. I originally had the internet servers on with this unit. It completely surprised me by having this tendency to drift apparently and have periodic heart attacks. It's not a time GPS, so one could argue that it's not to be trusted. Unfortunately, this odd behavior may exist in all SIRF III and possibly other SIRF units. Unlikely, as there are several GPS receivers with PPS outputs listed using that chipset. It was only by turning off the internet servers that I was able to get some clean graphs of exactly what the GPS was doing. When I had the internet servers enabled, once the GPS starting acting odd, which it shouldn't do at all, NTPD would clock hop to the internet. Normally, that would be OK. However, as discussed previously, even my errant GPS is more accurate over the short term than the internet for me. With the internet conection, I get + / - 50 ms variations in time over a span of an our. With the GPS, I get + / - 60 ms variations over several days, with a few wild corrections during its heart attacks. Those are two bad choices, but I think I'd still rather run on the GPS. Your choice, of course. The only way I can prevent clock hopping is by noselecting the internet servers. What's the problem with the clock changing to Internet servers? It will change back again when the GPS returns to an acceptable state. While I'm testing to determine the GPS's stability and reliability, I don't want it clock hopping. It screws up my graphs. Once I'm satisfied with the system and revert to normal operating mode, I don't have a problem with it. Even if I end up with internet servers turned on, which I expect to, I think it's much better to know about these GPS anomalies before putting it into long term service. Anybody considering using a SIRF III or maybe even any SIRF unit for timekeeping should be warned by my experience, test the unit, and make sure it's up to the task. These problems could even affect SIRF units with PPS outputs, although I don't know. I'll probably decommission this unit from timekeeping duty and relegate it to navigation duty, although I'm not sure how trustworthy it is for that when it's throwing a temper tantrum. You want to say all SiRF chipsets are bad on the basis of testing one manufacturer's implementation, and in a way which the software supplier doesn't recommend? There are two issues, the NMEA drift, and the periodic heart attacks. I know from Charles Elliott's (I think) comments that his BU-353 exhibits both curses. So, I'd say it's intrinsic to that product, at least. I don't know if other Globalsat products do these things. I've got reports of other SIRF based devices showing the substantial NMEA drift. I don't know if they are subject to the heart attacks or offset storms that this unit exhibits. You can bet I'd want to test ANY other SIRF designs before deploying it. I've already committed to getting better (hopefully) equipment. (Shipping from Hong Kong or where ever seems to take a LONG time when you're waiting on something.) 2-3 weeks, and I'm an impatient sort as well! Hopefully, the Sure board will be much more stable and reliable. I'm planning to do the same extensive testing on the Sure for a week or two. I'll start out just plugging the Sure into my serial - USB converter using the same com port as the Globalsat unit was running on. I want to see how it does with NMEA only data for a while. I'm hoping NOT to see substantial drifting from UTC and NOT to see any heart attacks every few days. I expect lots of jitter, since a number of variable length sentences are being output. Then, I plan to turn off all but GPGGA and test some more, and maybe tinker with the baud rate. Then, if I can solder the board without killing it, I'll engage PPS through the serial - USB port and test that for a while. Then, I'll try it with PPS and real serial on my other computer, the only one with a serial port. You /will/ see variation in the serial output from the Sure device, as you will in many NMEA devices. For the Sure device, one measurement is here: http://www.leapsecond.com/pages/MG1613S/ under the heading "NMEA Latency". The graph here is 100 milliseconds full scale. http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif That's funny, there's this line in the text. "In a 15 minute run (900 s
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"Ron Frazier (NTP)" wrote: > On 3/20/2012 5:48 PM, E-Mail Sent to this address will be added to the > BlackLists wrote: > > unruh wrote: > > > >> Dave Hart wrote: > >> > >>> frequency adjustments aren't compounded like that. > >>> > >> Lets hope not, but on his system, something DID trigger a runaway. > >> > > What about power saving frequency management of the core > > NTP is using? > > > > > I doubt that's relevant. I currently have both min and max CPU speed > set to 100% as someone mentioned it before. I forget - was that at the BIOS level or up in the OS? If the latter, best check the BIOS too - for example, HP ProLiant systems (not sure about PCs but perhaps there too) have an automagically done by firmware power management mode... rick jones -- portable adj, code that compiles under more than one compiler 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] PSYCHO PC clock is advancing at 2 HR per second
Rick Jones wrote: > Ron Frazier wrote: >> BlackList wrote: >>> unruh wrote: Dave Hart wrote: > frequency adjustments aren't compounded like that. Lets hope not, but on his system, something DID trigger a runaway. >>> What about power saving frequency management of the core NTP is using? >>> >> I doubt that's relevant. I currently have both min and max CPU speed >> set to 100% as someone mentioned it before. > > I forget - was that at the BIOS level or up in the OS? > If the latter, best check the BIOS too - for example, > HP ProLiant systems (not sure about PCs but perhaps > there too) have an automagically done by firmware power > management mode... ... and some modern CPUs will vary core frequency and power independent of the BIOS and OS settings to keep the temperature of the CPU below thresholds. -- E-Mail Sent to this address will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"unruh" wrote in message news:dG5ar.18461$pc1.11...@newsfe11.iad... [] No confusion. I understood completely. Ron had a machine on GPS which ran away. You got a report of a 1 sec slippage. The question is whether or not a 1 sec slippage in the GPS could trigger a runaway on a machine which also had LOCL as a server. OK. I simply do not believe that the GPS sudenly went wild and delivered time at a rate 1000 times the UTC rate. It seems unlikely. Something on his system triggered and instability, and all he had running was a GPS and the LOCL server. Now, usually the machine would take the GPS signal and it certainly could not engage in that kind of runaway behaviour. It could however engage in something like a 1 sec slippage. How could that trigger an instability? I would regard a system which was not at least somewhat protected against failure of a GPS device as not being correctly configured. Perhaps the NTP simulator could be used to predict behaviour in the case you suggest, but I have no experience with that tool. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"Ron Frazier (NTP)" wrote in message news:4f692255.2020...@c3energy.com... On 3/20/2012 11:21 AM, David J Taylor wrote: [] You /will/ see variation in the serial output from the Sure device, as you will in many NMEA devices. For the Sure device, one measurement is here: http://www.leapsecond.com/pages/MG1613S/ under the heading "NMEA Latency". The graph here is 100 milliseconds full scale. http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif That's funny, there's this line in the text. "In a 15 minute run (900 seconds) the mean latency was 350.2 ms with a standard deviation (jitter) of 10.7 ms. " Then there's the graph, which seems to show a variance in NMEA start time of 75 ms or so. The two seem to contradict each other. How so? Are you taking the peak-to-peak figures from the graph and comparing it to the standard deviation? SD isn't a peak-to-peak value. You already mentioned the Garmin previously, and the Sure now, and I have reports of similar NMEA drifting behavior from other SIRF units. So, it appears that most, if not all GPS's exhibit a variance in the timing of NMEA data of 50 to 120 ms or so. That would definitely put a limit on what you could do with NMEA only data. Yes, in typical GPS receivers the NMEA data is only accurate to a second - it says where the unit was at the UTC second preceding the data. I don't believe that jitter in NMEA output time is limited to one particular chipset. (Is jitter RMS, SD, peak-to-peak?). Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Wed, Mar 21, 2012 at 06:49, David J Taylor wrote: > (Is jitter RMS, SD, peak-to-peak?). NTP's jitter is root mean squares of offsets from the clock filter register (last 8 responses, more or less). Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On Wed, Mar 21, 2012 at 06:49, David J Taylor wrote: (Is jitter RMS, SD, peak-to-peak?). NTP's jitter is root mean squares of offsets from the clock filter register (last 8 responses, more or less). Dave Hart Thanks, Dave. Makes good sense. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/21/2012 2:49 AM, David J Taylor wrote: "Ron Frazier (NTP)" wrote in message news:4f692255.2020...@c3energy.com... On 3/20/2012 11:21 AM, David J Taylor wrote: [] You /will/ see variation in the serial output from the Sure device, as you will in many NMEA devices. For the Sure device, one measurement is here: http://www.leapsecond.com/pages/MG1613S/ under the heading "NMEA Latency". The graph here is 100 milliseconds full scale. http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif That's funny, there's this line in the text. "In a 15 minute run (900 seconds) the mean latency was 350.2 ms with a standard deviation (jitter) of 10.7 ms. " Then there's the graph, which seems to show a variance in NMEA start time of 75 ms or so. The two seem to contradict each other. How so? Are you taking the peak-to-peak figures from the graph and comparing it to the standard deviation? SD isn't a peak-to-peak value. You already mentioned the Garmin previously, and the Sure now, and I have reports of similar NMEA drifting behavior from other SIRF units. So, it appears that most, if not all GPS's exhibit a variance in the timing of NMEA data of 50 to 120 ms or so. That would definitely put a limit on what you could do with NMEA only data. Yes, in typical GPS receivers the NMEA data is only accurate to a second - it says where the unit was at the UTC second preceding the data. I don't believe that jitter in NMEA output time is limited to one particular chipset. (Is jitter RMS, SD, peak-to-peak?). I noticed that Dave Hart later posted this reply to your question. I'll reference that below. NTP's jitter is root mean squares of offsets from the clock filter register (last 8 responses, more or less). Cheers, David Perhaps I've been misusing some of the terms. There appear to be 5 items we could discuss / graph. A) The moment to moment offset of my PC's clock from the GPS clock when I sample it. In my case, this is NMEA data. This is where I've been reporting + / - 10 ms accuracy. I, perhaps wrongly, thought this peak to peak range, or maybe half of it, was the jitter. B) The longer term (a few days) variance of the NMEA data from UTC. You could call it variance, wobble, drift, I don't know if there is an official name for it. C) What your ntp plotter plots as the red line on the jitter tab with a loopstats file. Not sure how that's derived. D) What your ntp plotter plots as the black line on the jitter tab with a loopstats file, a weighted moving average, presumably of the red line. E) What the Meinburg Time Server reports for each peer as jitter. This is probably the same data as NTPQ - p. Probably, C and E are the only ones that match Dave Hart's definition quoted above. For my personal purposes, an RMS value doesn't do me as much good. I am mainly concerned with A and B. My main concerns are, how far my PCs' clocks are off from each other, and how far they're off from UTC. So, I could say the following to characterize my GPS system. 1) My PC clock is almost always within + / - 10 ms of GPS time due to short term offsets from the GPS NMEA data. 2) My GPS time is almost always within + / - 70 ms of UTC time due to longer term variance in the timing of the NMEA data. and consequently 3) My PC clock is almost always within + / - 80 ms (adding the two) of UTC time due to short term and longer term changes in the NMEA data. I have no idea what the proper names are to apply to these parameters. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 8:27 PM, Rick Jones wrote: "Ron Frazier (NTP)" wrote: On 3/20/2012 5:48 PM, E-Mail Sent to this address will be added to the BlackLists wrote: unruh wrote: Dave Hart wrote: frequency adjustments aren't compounded like that. Lets hope not, but on his system, something DID trigger a runaway. What about power saving frequency management of the core NTP is using? I doubt that's relevant. I currently have both min and max CPU speed set to 100% as someone mentioned it before. I forget - was that at the BIOS level or up in the OS? If the latter, best check the BIOS too - for example, HP ProLiant systems (not sure about PCs but perhaps there too) have an automagically done by firmware power management mode... rick jones My settings are at the Windows OS level. There's the one where you can set the maximum and minimum CPU speed as a percentage. Both mine, on ac power, are at 100%, which may increase power consumption, but which may also make for more reliable timing. I haven't proven that either way yet. There's also a system cooling policy, which I have set to active. That means, increase the fan speed before slowing the processor. I monitor the system temperature, and I don't think it's been overheating. Sincerely, Ron -- (PS - If you email me and don't get a quick response, don't be concerned. I get about 300 emails per day from alternate energy mailing lists and such. I don't always see new messages very quickly. If you need a reply and have not heard from me in 1 - 2 weeks, send your message again.) Ron Frazier timekeepingdude AT c3energy.com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-21, Ron Frazier (NTP) wrote: > On 3/21/2012 2:49 AM, David J Taylor wrote: >> >> "Ron Frazier (NTP)" wrote in message >> news:4f692255.2020...@c3energy.com... >>> On 3/20/2012 11:21 AM, David J Taylor wrote: >> [] You /will/ see variation in the serial output from the Sure device, as you will in many NMEA devices. For the Sure device, one measurement is here: http://www.leapsecond.com/pages/MG1613S/ under the heading "NMEA Latency". The graph here is 100 milliseconds full scale. http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif >>> >>> That's funny, there's this line in the text. >>> >>> "In a 15 minute run (900 seconds) the mean latency was 350.2 ms with >>> a standard deviation (jitter) of 10.7 ms. " >>> >>> Then there's the graph, which seems to show a variance in NMEA start >>> time of 75 ms or so. The two seem to contradict each other. >> >> How so? Are you taking the peak-to-peak figures from the graph and >> comparing it to the standard deviation? SD isn't a peak-to-peak value. >> >>> You already mentioned the Garmin previously, and the Sure now, and I >>> have reports of similar NMEA drifting behavior from other SIRF units. >>> So, it appears that most, if not all GPS's exhibit a variance in the >>> timing of NMEA data of 50 to 120 ms or so. That would definitely put >>> a limit on what you could do with NMEA only data. >> >> Yes, in typical GPS receivers the NMEA data is only accurate to a >> second - it says where the unit was at the UTC second preceding the >> data. I don't believe that jitter in NMEA output time is limited to >> one particular chipset. >> >> (Is jitter RMS, SD, peak-to-peak?). >> > > I noticed that Dave Hart later posted this reply to your question. I'll > reference that below. > > NTP's jitter is root mean squares of offsets from the clock filter > register (last 8 responses, more or less). Strange, because ntp then takes that entry of those 8 with the shortest roundtrip time and uses only it to drive the ntp algorithm. Thus on the one hand it is using it as a measure of jitter and on the other hand saying it does not trust most of those values, with a distrust so deep it throws them away. Why would you be reporting anything for a set of data you distrust so deeply. > > > >> Cheers, >> David > > Perhaps I've been misusing some of the terms. There appear to be 5 > items we could discuss / graph. > > A) The moment to moment offset of my PC's clock from the GPS clock when > I sample it. In my case, this is NMEA data. This is where I've been > reporting + / - 10 ms accuracy. I, perhaps wrongly, thought this peak > to peak range, or maybe half of it, was the jitter. > > B) The longer term (a few days) variance of the NMEA data from UTC. You > could call it variance, wobble, drift, I don't know if there is an > official name for it. > > C) What your ntp plotter plots as the red line on the jitter tab with a > loopstats file. Not sure how that's derived. > > D) What your ntp plotter plots as the black line on the jitter tab with > a loopstats file, a weighted moving average, presumably of the red line. > > E) What the Meinburg Time Server reports for each peer as jitter. This > is probably the same data as NTPQ - p. > > Probably, C and E are the only ones that match Dave Hart's definition > quoted above. > > For my personal purposes, an RMS value doesn't do me as much good. I am > mainly concerned with A and B. My main concerns are, how far my PCs' > clocks are off from each other, and how far they're off from UTC. So, I > could say the following to characterize my GPS system. > > 1) My PC clock is almost always within + / - 10 ms of GPS time due to > short term offsets from the GPS NMEA data. > > 2) My GPS time is almost always within + / - 70 ms of UTC time due to > longer term variance in the timing of the NMEA data. > > and consequently > > 3) My PC clock is almost always within + / - 80 ms (adding the two) of > UTC time due to short term and longer term changes in the NMEA data. > > I have no idea what the proper names are to apply to these parameters. > > Sincerely, > > Ron > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
>> NTP's jitter is root mean squares of offsets from the clock filter >> register (last 8 responses, more or less). unruh wrote: > Strange, because ntp then takes that entry of those 8 > with the shortest roundtrip time and uses only it to > drive the ntp algorithm. Thus on the one hand it is using > it as a measure of jitter and on the other hand saying > it does not trust most of those values, with a distrust > so deep it throws them away. Why would you be reporting > anything for a set of data you distrust so deeply. Truth, lies, and statistics? {or is that Lies, damned lies, and statistics?} -- E-Mail Sent to this address will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
"Ron Frazier (NTP)" wrote in message news:4f69e531.7070...@c3energy.com... [] C) What your ntp plotter plots as the red line on the jitter tab with a loopstats file. Not sure how that's derived. Red-line: jitter straight out of the loopstats data. Scale on the left. Green line: same, but averaged over the time you select. Note that the scale is on the right-hand side, and is ten times that on the left. This so that peaks show more clearly on the raw graph. D) What your ntp plotter plots as the black line on the jitter tab with a loopstats file, a weighted moving average, presumably of the red line. The RMS variation of the offset in a one-hour period. Not sure this is particularly useful, quite honestly. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 3/20/2012 2:59 PM, unruh wrote: On 2012-03-20, David J Taylor wrote: "unruh" wrote in message news:d13ar.7952$gv1.7...@newsfe12.iad... [] It is really really hard to imagine any gps device doing that. Yes, I agree, and yet what just popped up in my mail box but a reference to: "an inexplicable 1 second slip of 3 GPS based NTP time sources". I have, of course, asked for more details! A one second slip I could understand-- eg Gamin 18x reporting over 1 Gamin??? Perhaps you meant to write "Garmin"! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 21 Mar, 2012, at 11:36 , unruh wrote: > On 2012-03-21, Ron Frazier (NTP) wrote: >> >> I noticed that Dave Hart later posted this reply to your question. I'll >> reference that below. >> >> NTP's jitter is root mean squares of offsets from the clock filter >> register (last 8 responses, more or less). > > Strange, because ntp then takes that entry of those 8 with the shortest > roundtrip time and uses only it to drive the ntp algorithm. Thus on the > one hand it is using it as a measure of jitter and on the other hand > saying it does not trust most of those values, with a distrust so deep > it throws them away. Why would you be reporting anything for a set of > data you distrust so deeply. I see you keep pointing this out in various ways, but I really don't understand the point. If you are measuring data with non-guassian, non-zero-mean noise superimposed you need to find a statistic which is appropriate for the noise to produce the best noise-free estimate of the quantity you are interested in measuring. If someone takes `n' samples with a (slightly different) non-gaussian noise distribution and finds the median of the `n' (which is an individual sample) to use for further processing would you really call that "throwing away 'n-1' of the samples" rather than just computing the measure of central tendency which is most appropriate for the noise distribution? And if he went back over the data to compute a measure of variability (perhaps computing the median square deviation would be more appropriate) would that really be reporting something "for a set of data you distrust so deeply"? Unless I'm missing something this seems like a rather bizarre point of view. If you are looking for something to complain about in this particular bit of machinery in ntpd I think there are much more interesting aspects you might consider. The best might be that this code causes ntpd to sometimes process offsets which are quite old, in that they were measured at a time well into the past. In theory PLLs and other feedback control mechanisms are unconditionally destabilized if there is any delay in the feedback path. This is why ntpd makes no use of knowledge of when an offset was measured; it is feeding those offsets to a PLL and a PLL has no way to deal with data measured at any time other than "right now". In practice (as opposed to theory) approximating stability while using data which is significantly delayed requires making the time constant of the PLL large enough that the delay in the feedback path can be assumed to be approximately zero in comparison. The time constant of ntpd's PLL, and hence the stately pace at which it responds to errors, is hence directly related to the worst case delays between the measurement and the processing offset data which is caused by this filter. There are so many things to complain about that actually make sense (in reality everything can be justified in terms of tradeoffs, but people can differ about which tradeoffs produce the most attractive result) that I don't see why you keep harping on something which seems more like nonsense. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-22, Dennis Ferguson wrote: > > On 21 Mar, 2012, at 11:36 , unruh wrote: >> On 2012-03-21, Ron Frazier (NTP) wrote: >>> >>> I noticed that Dave Hart later posted this reply to your question. I'll >>> reference that below. >>> >>> NTP's jitter is root mean squares of offsets from the clock filter >>> register (last 8 responses, more or less). >> >> Strange, because ntp then takes that entry of those 8 with the shortest >> roundtrip time and uses only it to drive the ntp algorithm. Thus on the >> one hand it is using it as a measure of jitter and on the other hand >> saying it does not trust most of those values, with a distrust so deep >> it throws them away. Why would you be reporting anything for a set of >> data you distrust so deeply. > > I see you keep pointing this out in various ways, but I really don't > understand the point. If you are measuring data with non-guassian, > non-zero-mean noise superimposed you need to find a statistic which is > appropriate for the noise to produce the best noise-free estimate of the > quantity you are interested in measuring. If someone takes `n' samples > with a (slightly different) non-gaussian noise distribution and finds the > median of the `n' (which is an individual sample) to use for further > processing would you really call that "throwing away 'n-1' of the samples" > rather than just computing the measure of central tendency which is most No I would not. That is not what ntpd does. It really does throw away 7 of the samples and never uses them. The whole question is what is the best statistic to use. I do not believe that the "shortest roundtrip time" is that best statistic. If you could convince me it is, I would be more than happy to have ntp use it. IF the roundtrip times were to vary by factors of 2 from one instance to the next, I might be persuaded that it was the best statistic. But it does not in almost all cases where ntpd is used. It varies by a few percent ( with maybe an occasional blip with larger delays.) I have huge reams of data to support my statement. Note that in the refclock drivers, some fraction of the events are thrown away to make up for "popcorn" events ( events believed to be taken from a distribution with a far wider distribution than normal-Ie, the model is that the distribution is of the form P1 rho1(x)+P2 rho2(x) where P1>>P2 and rho2 is a dsitribution with a much larger deviation than rho1) and the "throwing away" is an attempt to get rid of those events from the second. But ntpd's handling of the round trip statistic strikes me as an extremely ad hoc, unthought-through attempt to answer the valic question of how to handle "popcorn" events in the one way trip time of the data. There are instances where it might even be the right thing to do, but those are, I believe, rare, not the run of the mill. The current handling throws away valuable data-- data which could instead be used to increase the sensitivity of ntpd to changes in the clock rate, eg due to temperature changes, a sensitivity which is currently poor in ntpd. It could be used to decrease the errors in ntpd's clock handling. Instead it is thrown away in an attempt to solve a problem that is in many cases non-existant. > appropriate for the noise distribution? And if he went back over the data > to compute a measure of variability (perhaps computing the median square > deviation would be more appropriate) would that really be reporting something > "for a set of data you distrust so deeply"? Unless I'm missing something > this seems like a rather bizarre point of view. > > If you are looking for something to complain about in this particular bit > of machinery in ntpd I think there are much more interesting aspects you > might consider. The best might be that this code causes ntpd to sometimes > process offsets which are quite old, in that they were measured at a time > well into the past. In theory PLLs and other feedback control mechanisms > are unconditionally destabilized if there is any delay in the feedback path. > This is why ntpd makes no use of knowledge of when an offset was measured; > it is feeding those offsets to a PLL and a PLL has no way to deal with data > measured at any time other than "right now". In practice (as opposed to > theory) approximating stability while using data which is significantly > delayed requires making the time constant of the PLL large enough that > the delay in the feedback path can be assumed to be approximately zero > in comparison. The time constant of ntpd's PLL, and hence the stately > pace at which it responds to errors, is hence directly related to the > worst case delays between the measurement and the processing offset data > which is caused by this filter. Yes, that is another problem. It directly leads to ntpd's glacial response to true changes-- like changes in the rate due to temperature changes. Like changes in the rate due to startup, etc. Are those costs worth the benefits? Somet
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
unruh wrote: No I would not. That is not what ntpd does. It really does throw away 7 of the samples and never uses them. The whole question is what is the best statistic to use. I do not believe that the "shortest roundtrip time" is that best statistic. If you could convince me it is, I would be more than happy to have ntp use it. In _some_ scenarios, keeping only the minimum rttsample is indeed the best approach: I have been working for a couple of years on the new cell phone network in Norway (we've replaced everything, including every single base station!). Even if GSM and related cell phone standards does not require the same absolute timing precision as some of those used in the US, there is still a requirement for a _very_ stable frequency base in order to do transparent handover from one base station to the next, and the relative offset determines the maximum doppler that can be handled. In order to be considered OK, we can't accept more than 50 ppb frequency offset. Handling this with up to 50 ms sawtooth variation (with periods up to several hours) in the one-way latency means that the vendor require sampling periods of up to 10+ hours, with multiple packets/second and then keeping a single packet at the end. Of course, the main requirement is to start with a _very_ stable time base, in this case double-oven OCXOs with daily drift rates in the fractional ppb range! IF the roundtrip times were to vary by factors of 2 from one instance to the next, I might be persuaded that it was the best statistic. But it does not in almost all cases where ntpd is used. It varies by a few percent ( with maybe an occasional blip with larger delays.) I have huge reams of data to support my statement. So do I, and I would have agreed with you a month ago, but I have gotten actual measurement data from the base station vendor showing really _huge_ packet-to-packet jitter values. Terje - "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] PSYCHO PC clock is advancing at 2 HR per second
On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote: > unruh wrote: > >No I would not. That is not what ntpd does. It really does throw away 7 > >of the samples and never uses them. The whole question is what is the > >best statistic to use. I do not believe that the "shortest roundtrip > >time" is that best statistic. If you could convince me it is, I would be > >more than happy to have ntp use it. > > In _some_ scenarios, keeping only the minimum rttsample is indeed > the best approach: Yes, it depends on the network jitter and clock stability. But ntpd doesn't try to estimate the stability and uses a fixed dispersion rate and Allan intercept in the filter algorithm (15 ppm and 1024 sec by default). By tweaking the constants you can change the ratio of dropped samples. But I think a much bigger problem with the clock filter and PLL combination is that it can't drop more than 7 samples. When the network is saturated, it's usually better to drop much more than. If the increase in delay is 1 second and the clock is good to 10 ppm, it could wait for days before accepting another sample. > In order to be considered OK, we can't accept more than 50 ppb > frequency offset. > > Handling this with up to 50 ms sawtooth variation (with periods up > to several hours) in the one-way latency means that the vendor > require sampling periods of up to 10+ hours, with multiple > packets/second and then keeping a single packet at the end. That seems excessive. Do they set the frequency directly just from the last two samples? With PLL or similar, increasing the time constant accordingly might be a better approach. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Miroslav Lichvar wrote: On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote: But I think a much bigger problem with the clock filter and PLL combination is that it can't drop more than 7 samples. When the network is saturated, it's usually better to drop much more than. If the increase in delay is 1 second and the clock is good to 10 ppm, it could wait for days before accepting another sample. Oh but it can! Check out "huff-puff"! You can easily tell ntpd to coast past multi-hour periods of excessive delays/traffic. In order to be considered OK, we can't accept more than 50 ppb frequency offset. Handling this with up to 50 ms sawtooth variation (with periods up to several hours) in the one-way latency means that the vendor require sampling periods of up to 10+ hours, with multiple packets/second and then keeping a single packet at the end. That seems excessive. Do they set the frequency directly just from the last two samples? With PLL or similar, increasing the time constant accordingly might be a better approach. They keep the best sample from each of four periods, each period can be up to 10+ hours, then they do a second set of validity checks on the four surviving samples, before the final curve fitting to determine the actual drift rate. Terje -- - "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] PSYCHO PC clock is advancing at 2 HR per second
On 2012-03-23, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote: > unruh wrote: >> No I would not. That is not what ntpd does. It really does throw away 7 >> of the samples and never uses them. The whole question is what is the >> best statistic to use. I do not believe that the "shortest roundtrip >> time" is that best statistic. If you could convince me it is, I would be >> more than happy to have ntp use it. > > In _some_ scenarios, keeping only the minimum rttsample is indeed the > best approach: > > I have been working for a couple of years on the new cell phone network > in Norway (we've replaced everything, including every single base station!). > > Even if GSM and related cell phone standards does not require the same > absolute timing precision as some of those used in the US, there is > still a requirement for a _very_ stable frequency base in order to do > transparent handover from one base station to the next, and the relative > offset determines the maximum doppler that can be handled. > > In order to be considered OK, we can't accept more than 50 ppb frequency > offset. > > Handling this with up to 50 ms sawtooth variation (with periods up to > several hours) in the one-way latency means that the vendor require > sampling periods of up to 10+ hours, with multiple packets/second and > then keeping a single packet at the end. > > Of course, the main requirement is to start with a _very_ stable time > base, in this case double-oven OCXOs with daily drift rates in the > fractional ppb range! >> >> IF the roundtrip times were to vary by factors of 2 from one instance to >> the next, I might be persuaded that it was the best statistic. But it >> does not in almost all cases where ntpd is used. It varies by a few >> percent ( with maybe an occasional blip with larger delays.) I have huge >> reams of data to support my statement. > > So do I, and I would have agreed with you a month ago, but I have gotten > actual measurement data from the base station vendor showing really > _huge_ packet-to-packet jitter values. In your case, I might well be persuaded that throwing away data is the best way of handling the errors. But it would still leave me uncomfortable. Data is precious. It is unrepeatable (in the case of timing). My prejudice would be that surely there is some way of extracting more from the data than simply that one least delay packet. For example, for ntpd if the delay is in either one path or the other, then instead of using the mean as the best estimate of the remote clock time, one could assume that the increase in travel time is in only one path, and by looking at the offset get a pretty good idea of which one it is in (see the offset vs travel plots in Mill's book, where you can get these wings in which the change in travel time is due to only one of the paths.) That is infomation you could use to better the time estimates. It of course makes for a much more complex clock filter than the simple "throw away everything but the shortest roundtrip". Recall that with 8 data points, you reduce the statistical error by about a factor of 3 over 1. If the variation in roundtrip is less than about 3, then the advantage of the greater number of points can outweigh the increased noise due to round trip variation. > > Terje > - > "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] PSYCHO PC clock is advancing at 2 HR per second
On Fri, Mar 23, 2012 at 06:12:11PM +0100, Terje Mathisen wrote: > Miroslav Lichvar wrote: > >On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote: > >But I think a much bigger problem with the clock filter and PLL > >combination is that it can't drop more than 7 samples. When the > >network is saturated, it's usually better to drop much more than. If > >the increase in delay is 1 second and the clock is good to 10 ppm, it > >could wait for days before accepting another sample. > > Oh but it can! > > Check out "huff-puff"! > > You can easily tell ntpd to coast past multi-hour periods of > excessive delays/traffic. With huff-puff it doesn't really coast, it just shifts the offset in one direction by increase in the delay. This works well when the link is saturated in one direction, but under normal conditions it makes the timekeeping worse, so you need to consider if it's worth enabling. If you want to see why ntpd can't drop more samples you can block the NTP packets in firewall, e.g. in a cycle which allows 4 packets and drops 60. The PLL will be unstable, frequency will be jumping up and down, offset orders of magnitude higher. This is the reason why some other NTP implementations were created. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions