subject:"\[ntp\:questions\] PSYCHO PC clock is advancing at 2 HR per second"

2012-03-19 Thread E-Mail Sent to this address will be added to the BlackLists

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

2012-03-19 Thread Dave Hart

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

Sincerely Frustrated,

Ron

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

2012-03-19 Thread Dave Hart

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

2012-03-19 Thread unruh

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,

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

Sincerely Frustrated,

Ron

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

2012-03-19 Thread unruh

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

2012-03-19 Thread unruh

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

2012-03-20 Thread Miroslav Lichvar

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

2012-03-20 Thread Dave Hart

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

2012-03-20 Thread Dave Hart

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

2012-03-20 Thread David Lord


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

2012-03-20 Thread Dave Hart

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

2012-03-20 Thread Chris Albertson

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

2012-03-20 Thread E-Mail Sent to this address will be added to the BlackLists

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

2012-03-20 Thread David Lord


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

2012-03-20 Thread E-Mail Sent to this address will be added to the BlackLists


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

2012-03-20 Thread Rick Jones

"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