subject:"Re\: \[ntp\:questions\] ARRGH\!\!\! I woke up to a 50 SECOND clock error."

Terje Mathisen terje.mathisen at tmsw.no wrote in message 
news:is9e39-6ve2@ntp6.tmsw.no...

[]
You should never accept much more than 10:1 speed difference between 
down and up.


Terje


Should - I agree.  But in the UK from Virgin Media I have 30 Mb/s down, 
1 Mb/s up.  I have been promised an upload speed increase about 18 months 
ago to 2 Mb/s up, which is more sensible, but that increase hasn't yet 
been delivered.  I am also promised an increase within the next year which 
doubles my existing speeds, giving 60 Mb/s down and 4 Mb/s up.  Not ideal, 
but I prefer cable to ADSL.


No wonder I have four GPS devices connected to 5 PCs!  G

Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-17 Thread John Hasler

David J Taylor writes:
 But in the UK from Virgin Media I have 30 Mb/s down, 1 Mb/s up.  I
 have been promised an upload speed increase about 18 months ago to 2
 Mb/s up, which is more sensible...

Such a very high cable download speed is a peak burst speeds on a shared
medium.  Your sustained performance is not likely to be more than a
fraction of it.

 Not ideal, but I prefer cable to ADSL.

You'd get less jitter with DSL.
-- 
John Hasler 
jhas...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

John Hasler jhas...@newsguy.com wrote in message 
news:87sjh7mlqs@thumper.dhh.gt.org...

David J Taylor writes:

But in the UK from Virgin Media I have 30 Mb/s down, 1 Mb/s up.  I
have been promised an upload speed increase about 18 months ago to 2
Mb/s up, which is more sensible...


Such a very high cable download speed is a peak burst speeds on a shared
medium.  Your sustained performance is not likely to be more than a
fraction of it.


Speed tests from a number of sites show 30 Mb/s, and that's over several 
seconds.  I downloaded the Windows-8 64-bit ISO recently, and the 
3,583,707,136 bytes took 48 minutes, 24 seconds, which I make about 7.4 
Mb/s, and the 32-bit ISO was 2,711,396,352 bytes in 27 minutes, so about 
13.4 Mb/s.  That was without any download accelerator (no multiple 
connections).



Not ideal, but I prefer cable to ADSL.


You'd get less jitter with DSL.
--
John Hasler


DSL or ADSL?  But I haven't checked the jitter on the cable modem link for 
a long time, since I installed the GPS receivers.


Thanks, John.

Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


You'd get less jitter with DSL.
--
John Hasler


John,

You have piqued my interest.  I have just set up a Windows-8 PC with an 
ntp configuration not dissimilar to Ron's, in that it's using purely 
Internet servers but trying to monitor a local stratum-1 server as well. 
In essence:


__
# Local stratum-1 Free BSD server
server 192.168.0.3  iburst  minpoll 5 maxpoll 5  prefer  noselect

# Seven external servers:
server  x.x.x.uk  iburst
server  y.y.y.uk  iburst
server  0.uk.pool.ntp.org  iburst
server  1.uk.pool.ntp.org  iburst
server  2.uk.pool.ntp.org  iburst
server  0.nl.pool.ntp.org  iburst
server  1.nl.pool.ntp.org  iburst
__


The performance will appear here:

 http://www.satsignal.eu/mrtg/performance_torvik.php

It will be interesting to see whether the Internet servers poll period 
increased from 64s (I'm hoping that the 32s poll on the local server won't 
affect the Internet ones), and what level of jitter is achieved.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-17 Thread Charles Elliott

I did not express myself well.  Permit me to explain.  

1. The variable delays are caused by buffering at the Internet routers.  See
CACM Staff. (2012). BufferBloat: what's wrong with the internet? Commun.
ACM, 55(2), 40-47. doi: 10.1145/2076450.2076464.  A discussion with Vint
Cerf, Van Jacobson, Nick Weaver, and Jim Gettys.  Instead of rejecting
packets that a router has no bandwidth to transmit, routers now buffer them.
As memory has become cheaper, the buffers have in many cases become large.
This results in packet delays that are highly variable and can exceed
several seconds.

The delays are asymmetric; that is, they are always positive.
NTPD's filtering algorithm always rejects outliers.  So when a packet is
received that has been buffered for 500 to 1000 ms, NTPD may associate it
with an offset this is much closer to the mean.  If this is true, then NTPD
has to be biased in its estimation of round-trip delay.  If a series of
packets are received that have been buffered, then eventually the mean will
increase until the offset is no longer an outlier.  But if the delay caused
by buffering is sporadic, as Unruh suggests, then NTPD will never compute
the offset correctly as all the outliers will have been rejected.

Furthermore, there are two bits of information associated with the
computation of offset: The offset = ((t1-t0) + (t3 - t2))/2 itself and the
time it is computed, which must be separated by some power of 2 seconds.  As
far as I can tell NTPD just throws away the fact that the interval between
offset computations must be near some power of 2.  Let the offset be y and
the computation of it be x.  Then is not y = f(x)?  That is, is not the
offset at least partially a function of the time it was computed?  Would
regression analysis be a more appropriate filtering algorithm?

Moreover, in industry feedback control is often the mechanism used
to correct for random noise, which buffering delay may be.

2. It is true that ADSL is asymmetric.  For example several tests show that
I see [2.57, 2.88] mbps down and [0.560, 0.720] mbps up.  But consider that
I have to be within a few thousand feet of the telco central office, which
is in Center City Philadelphia, and all the NTP servers are in State
College, PA (152 mi), Northern (Ramsey) New Jersey (95 mi), or New York City
(86 mi).  Thus the distance that the packet travels at 0.7 mbps is
relatively tiny compared to its total distance.  I question whether the ADSL
asymmetry accounts for the large negative correlation between delay and
offset that NTPD produces.

3. Ron is correct about the BU-353 GPS device: After a cold restart, the
BU-353 is right in synch with the average of 8 stratum 2 servers, and then
the offset steadily increases until the BU-353 looses synch with the
satellites after about a day.  Another cold restart starts the cycle again.
This may make comparisons between the BU-353 and Internet time invalid.  The
question is, what would happen if one did a warm restart instead of a cold
one?


Charles Elliott

 -Original Message-
 From: questions-bounces+elliott.ch=verizon@lists.ntp.org
 [mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
 Behalf Of unruh
 Sent: Friday, March 16, 2012 7:56 PM
 To: questions@lists.ntp.org
 Subject: Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock
 error.
 
 On 2012-03-16, Charles Elliott elliott...@verizon.net wrote:
  On the subject of accuracy, has anyone ever really looked at NTPD's
  offset filtering mechanism?  What it does now is sort the last (about
  50) offsets from smallest to largest and then prunes the smallest or
  largest, depending on which is further away from the average, until
  there are only N (I forget what N is) offset observations left.
 
 That is for refclocks, And it is usually about 16 (poll 4, and once per
 second). N is about 60% of the total.
 
 
  There may be at least two problems with this filtering mechanism.
  First, there is no apparent theory behind it; I have never seen such
 a
  crude filter
 
 The theory is that there are two noise mechanisms, one approximately
 gaussian with small standard deviation and one much broader but rarer.
 Ie, occasionally you will get popconr spikes. The median is the
 optimal estimator if you want to minimize |y-ybar|, just as the mean is
 the optimal estimator for (y-ybar)^2. |y-ybar| is less sensitive to
 large deviations.
 
  that does not take into account any information inherent in the data.
  On the other hand, what I don't know about filters would fill all 24
  volumes of an encyclopedia.
 
 Sure it does. See above.
 
 
  Second, we know that each offset observation should have arrived
 about
  one second after the previous one, yet NTPD does not take advantage
 of
  that knowledge.  There are filters, such as the Kalman filter that
  uses a Bayesian estimation approach to predict the next observation
  and adjusts it according to the prediction when it arrives, that do

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-17 Thread Ron Frazier (NTP)


On 3/17/2012 11:48 AM, David J Taylor wrote:

You'd get less jitter with DSL.
--
John Hasler


John,

You have piqued my interest.  I have just set up a Windows-8 PC with 
an ntp configuration not dissimilar to Ron's, in that it's using 
purely Internet servers but trying to monitor a local stratum-1 server 
as well. In essence:


__
# Local stratum-1 Free BSD server
server 192.168.0.3  iburst  minpoll 5 maxpoll 5  prefer  noselect

# Seven external servers:
server  x.x.x.uk  iburst
server  y.y.y.uk  iburst
server  0.uk.pool.ntp.org  iburst
server  1.uk.pool.ntp.org  iburst
server  2.uk.pool.ntp.org  iburst
server  0.nl.pool.ntp.org  iburst
server  1.nl.pool.ntp.org  iburst
__


The performance will appear here:

 http://www.satsignal.eu/mrtg/performance_torvik.php

It will be interesting to see whether the Internet servers poll period 
increased from 64s (I'm hoping that the 32s poll on the local server 
won't affect the Internet ones), and what level of jitter is achieved.


Cheers,
David



Hi David,

I'm not sure what will happen if you simultaneously prefer and noselect 
the local server.  Assuming the local stratum 1 server is the most 
stable time source, you'll get a much better picture of what the 
internet servers are doing relative to it if you allow it to be 
selectable as well as being preferred.  When you graph it, if the local 
server is the active clock, all the lines for the internet servers will 
be gathered around and relative to the local server.  When I tried to do 
things the other way around, with an internet server preferred, the 
graph looked awful because there was so much variation.  Also, if your 
local server starts reporting time that looks too far from the internet 
servers, regardless of who's fault it is, ntp will clock hop over to the 
internet servers.


I don't THINK your internet servers will ever poll above their default 
minpoll value of 6, or 64 seconds.


I realize you don't have a gps attached to this pc, but the iburst lines 
reminded me of something.  I read somewhere that having iburst on 
internet server lines, if a local gps is attached, could prevent the PC 
from synchronizing to the gps before it synchronizes to the internet.  
On my pc with the gps attached, I don't use the iburst command.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f64d793.9010...@c3energy.com...

[]

Hi David,

I'm not sure what will happen if you simultaneously prefer and noselect 
the local server.  Assuming the local stratum 1 server is the most 
stable time source, you'll get a much better picture of what the 
internet servers are doing relative to it if you allow it to be 
selectable as well as being preferred.  When you graph it, if the local 
server is the active clock, all the lines for the internet servers will 
be gathered around and relative to the local server.  When I tried to do 
things the other way around, with an internet server preferred, the 
graph looked awful because there was so much variation.  Also, if your 
local server starts reporting time that looks too far from the internet 
servers, regardless of who's fault it is, ntp will clock hop over to the 
internet servers.


I don't THINK your internet servers will ever poll above their default 
minpoll value of 6, or 64 seconds.


I realize you don't have a gps attached to this pc, but the iburst lines 
reminded me of something.  I read somewhere that having iburst on 
internet server lines, if a local gps is attached, could prevent the PC 
from synchronizing to the gps before it synchronizes to the internet. 
On my pc with the gps attached, I don't use the iburst command.


Sincerely,

Ron


Ron,

The local stratum-1 server shows without a tally code against it in the 
ntpq -p output, so it's being recorded in the peerstats, but not used for 
syncing.  The noselect msut override the prefer.


After about three hours running, the Internet servers are all at 512 
seconds poll interval.  The averaged jitter has been below 1 millisecond 
for the last couple of hours.  The offset is reporting between -0.7 
and -1.8 milliseconds, and the frequency is stabilising very nicely 
(because of the long poll interval).  I'll leave this running overnight 
and tomorrow to see how it handles temperature changes and any Internet 
access changes, and to get a few more points on the graph.


One caveat is that I am using the most recent NTP (ntpd 4.2.7p263 from 
Dave Hart's download page), and that with Windows-8, it may be using the 
new precision time system call.  From my own tests, this is similar, on 
earlier versions of NTP, to setting the environment variable 
NTPD_USE_INTERP_DANGEROUS, thus forcing the NTP time interpolation to be 
used.


The configuration I have is:

- cable modem (with built-in router, but working as a bridge by putting my 
own router in a device in the DMZ).


- Samknows network monitor (modified WRT54GL router)

- WRT54GL router running DD-WRT firmware

- Netgear 8-port consumer 1 Gb/s switch (G5108)

- wired connection to ~2 year old laptop PC

I only mention this to show that (a) it's not a direct connection and (b) 
there's no wireless involved.  My aim here is simply to see what 
performance may be had with just Internet servers.  The PC is only running 
NTP and monitoring software - no user programs and no interactive work, so 
it is a best-case scenario.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-17 Thread Ron Frazier (NTP)


On 3/17/2012 3:20 PM, David J Taylor wrote:
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f64d793.9010...@c3energy.com...

[]

Hi David,

I'm not sure what will happen if you simultaneously prefer and 
noselect the local server.  Assuming the local stratum 1 server is 
the most stable time source, you'll get a much better picture of what 
the internet servers are doing relative to it if you allow it to be 
selectable as well as being preferred.  When you graph it, if the 
local server is the active clock, all the lines for the internet 
servers will be gathered around and relative to the local server.  
When I tried to do things the other way around, with an internet 
server preferred, the graph looked awful because there was so much 
variation.  Also, if your local server starts reporting time that 
looks too far from the internet servers, regardless of who's fault it 
is, ntp will clock hop over to the internet servers.


I don't THINK your internet servers will ever poll above their 
default minpoll value of 6, or 64 seconds.


I realize you don't have a gps attached to this pc, but the iburst 
lines reminded me of something.  I read somewhere that having iburst 
on internet server lines, if a local gps is attached, could prevent 
the PC from synchronizing to the gps before it synchronizes to the 
internet. On my pc with the gps attached, I don't use the iburst 
command.


Sincerely,

Ron


Ron,

The local stratum-1 server shows without a tally code against it in 
the ntpq -p output, so it's being recorded in the peerstats, but not 
used for syncing.  The noselect msut override the prefer.


After about three hours running, the Internet servers are all at 512 
seconds poll interval.  The averaged jitter has been below 1 
millisecond for the last couple of hours.  The offset is reporting 
between -0.7 and -1.8 milliseconds, and the frequency is stabilising 
very nicely (because of the long poll interval).  I'll leave this 
running overnight and tomorrow to see how it handles temperature 
changes and any Internet access changes, and to get a few more points 
on the graph.




Come to think of it, my comment about the polling interval not 
increasing may only apply to a local refclock, not a local server.


One caveat is that I am using the most recent NTP (ntpd 4.2.7p263 from 
Dave Hart's download page), and that with Windows-8, it may be using 
the new precision time system call.  From my own tests, this is 
similar, on earlier versions of NTP, to setting the environment 
variable NTPD_USE_INTERP_DANGEROUS, thus forcing the NTP time 
interpolation to be used.




Can you elaborate more about what NTPD_USE_INTERP_DANGEROUS does?

Sincerely,

Ron



The configuration I have is:

- cable modem (with built-in router, but working as a bridge by 
putting my own router in a device in the DMZ).


- Samknows network monitor (modified WRT54GL router)

- WRT54GL router running DD-WRT firmware

- Netgear 8-port consumer 1 Gb/s switch (G5108)

- wired connection to ~2 year old laptop PC

I only mention this to show that (a) it's not a direct connection and 
(b) there's no wireless involved.  My aim here is simply to see what 
performance may be had with just Internet servers.  The PC is only 
running NTP and monitoring software - no user programs and no 
interactive work, so it is a best-case scenario.


Cheers,
David




--

(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] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-17 Thread Terje Mathisen


David J Taylor wrote:

Terje Mathisen terje.mathisen at tmsw.no wrote in message
news:is9e39-6ve2@ntp6.tmsw.no...
[]

You should never accept much more than 10:1 speed difference between
down and up.

Terje


Should - I agree. But in the UK from Virgin Media I have 30 Mb/s down,
1 Mb/s up. I have been promised an upload speed increase about 18 months
ago to 2 Mb/s up, which is more sensible, but that increase hasn't yet
been delivered. I am also promised an increase within the next year
which doubles my existing speeds, giving 60 Mb/s down and 4 Mb/s up. Not
ideal, but I prefer cable to ADSL.


I prefer fiber: 50/50 Mbit, very consistent ping times of a couple of ms 
to most no.pool.ntp.org servers. :-)


Cost is about $75/month.

Terje

--
- Terje.Mathisen at tmsw.no
almost all programming can be viewed as an exercise in caching

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-17 Thread Ron Frazier (NTP)


On 3/17/2012 6:00 PM, Terje Mathisen wrote:

David J Taylor wrote:

Terje Mathisen terje.mathisen at tmsw.no wrote in message
news:is9e39-6ve2@ntp6.tmsw.no...
[]

You should never accept much more than 10:1 speed difference between
down and up.

Terje


Should - I agree. But in the UK from Virgin Media I have 30 Mb/s down,
1 Mb/s up. I have been promised an upload speed increase about 18 months
ago to 2 Mb/s up, which is more sensible, but that increase hasn't yet
been delivered. I am also promised an increase within the next year
which doubles my existing speeds, giving 60 Mb/s down and 4 Mb/s up. Not
ideal, but I prefer cable to ADSL.


I prefer fiber: 50/50 Mbit, very consistent ping times of a couple of 
ms to most no.pool.ntp.org servers. :-)


Cost is about $75/month.

Terje



You're a lucky dude if that's even an option.  For most purposes other 
than timing, Comcast cable does pretty good for me.


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] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-16 Thread Ron Frazier (NTP)


Charles,

This is a PS to my preceding reply to this.  If this makes no sense, 
read my other reply first.


Once you get your graphs working, you can select different IP's on the 
peerstats screen as follows.  This may change in future updates to the 
program.


Right click on the graph.

An IP selection screen pops up.

To select a few IP's to show:

 a) click the check boxes for just the IP's you want
 b) click OK

To select all but a few IP's to show:

 a) click the all button
 b) click the check boxes to unselect the IP's you don't want
 c) click OK

To get back to the full list of IP's

 a) right click to bring up the IP selection screen
 b) click none   (Think of it as filtering none of them.)
 c) click OK

There was something else I wanted to mention, and I'm sure I'll remember 
it shortly after sending this.  Anyway, good luck.


Sincerely,

Ron



On 3/16/2012 7:07 PM, Charles Elliott wrote:

On the subject of accuracy, has anyone ever really looked at NTPD's offset
filtering mechanism?  What it does now is sort the last (about 50) offsets
from smallest to largest and then prunes the smallest or largest, depending
on which is further away from the average, until there are only N (I forget
what N is) offset observations left.

There may be at least two problems with this filtering mechanism.  First,
there is no apparent theory behind it; I have never seen such a crude filter
that does not take into account any information inherent in the data.  On
the other hand, what I don't know about filters would fill all 24 volumes of
an encyclopedia.

Second, we know that each offset observation should have arrived about one
second after the previous one, yet NTPD does not take advantage of that
knowledge.  There are filters, such as the Kalman filter that uses a
Bayesian estimation approach to predict the next observation and adjusts it
according to the prediction when it arrives, that do take advantage of
previous observations.  Demonstrations of the Kalman filter on the Internet
show almost spectacular results.  I used a Kalman filter in my clock
simulation program and the results seemed pretty good.  However, there are
numerical analysis considerations to programming a Kalman filter as the sums
and products of observations can become large in a program that runs
infinitely long.  Also, choosing the parameters of a Kalman filter is
apparently a black art.

Would it be worth it to recruit an electrical or systems engineer who
claimed to know something about filtering data to take a serious look at
NTPD's data filtering approach?  There has to be some reason that there is a
significant negative correlation between delay and offset in NTPD.  There
also has to be a reason that my GPS clock (BU-353, which, when it is working
well, only has offset ±6 ms from zero) has a difference between about 0 and
47 ms from an NTP server on another computer that gets its time from 8 NTP
stratum 2 servers over the Internet and has remarkably consistent offsets
±3.5 ms from zero.  The difference between the GPS clock and the average of
the stratum 2 servers appears to be a function of the time of day; it is
large during the mid-part of the day, when the Internet is busy and the
delay is large and quite variable between servers, and small late in the day
(right now it is -0.626; 6:55 PM EST), when the delay is smaller and pretty
uniform for all stratum 2 servers.

Charles Elliott

   

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
Behalf Of Chris Albertson
Sent: Thursday, March 15, 2012 5:22 PM
To: unruh
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock
error.

On Thu, Mar 15, 2012 at 2:09 PM, unruhun...@invalid.ca  wrote:

 

Unfortunately it is not that simple. That rate changes by significan
amounts. Thus the rate you get after a week may be very different
   

than
 

the rate you get after an hour. That, I submit, is the chief obstacle
to having an accurate clock. And that change in rate does not fit
   

with
 

the Allan variance assumptions (the noise source is not of the type
assumed)
   

You are right about that.  I was going to add in a bit about how to
pick the best time to look at the clock tower.  But left it out because
the point I was making was only that these things are not NTP
specific.   Details after that did not contribute the the main point.


Chris Albertson
Redondo Beach, California




--

(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

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-16 Thread Ron Frazier (NTP)

PPS to prior messages.  I knew I'd remember this after I hit send the 
last time.


You probably want to do any long term graphs starting right after 
powering off the GPS and back on.  If your GPS NMEA start time is 
wandering, that will give you a baseline for comparison which is 
consistent.  Also, once you've accumulated enough graph to see where the 
internet servers are relateive to the GPS, you can set the fudge time2 
parameter to align the GPS time offsets with the average server time 
offsets.  If you do that and restart and wait a while, the server graph 
lines should be almost right on top of the gps time graph.  If the GPS 
is wandering, these server lines will appear to move away from the GPS 
line over time.


http://dl.dropbox.com/u/9879631/peerstats%20after%20GSP%20power%20cycle%20with%20fudge%20factor%2020120316%202100.jpg

Here are the server lines in my ntp.conf for the GPS.

# windows lines for testing gps selected as main source - gpgga 9600 baud
server 127.127.20.5 prefer minpoll 3 maxpoll 3 mode 18
fudge  127.127.20.5 time2 0.4260 refid GPS1

Note that the fudge time2 parameter required to get your GPS time 
comparable to internet server time will change if you change the baud 
rate of the GPS.


Sincerely,

Ron


On the subject of accuracy, has anyone ever really looked at NTPD's offset
filtering mechanism?  What it does now is sort the last (about 50) offsets
from smallest to largest and then prunes the smallest or largest, depending
on which is further away from the average, until there are only N (I forget
what N is) offset observations left.

There may be at least two problems with this filtering mechanism.  First,
there is no apparent theory behind it; I have never seen such a crude filter
that does not take into account any information inherent in the data.  On
the other hand, what I don't know about filters would fill all 24 volumes of
an encyclopedia.

Second, we know that each offset observation should have arrived about one
second after the previous one, yet NTPD does not take advantage of that
knowledge.  There are filters, such as the Kalman filter that uses a
Bayesian estimation approach to predict the next observation and adjusts it
according to the prediction when it arrives, that do take advantage of
previous observations.  Demonstrations of the Kalman filter on the Internet
show almost spectacular results.  I used a Kalman filter in my clock
simulation program and the results seemed pretty good.  However, there are
numerical analysis considerations to programming a Kalman filter as the sums
and products of observations can become large in a program that runs
infinitely long.  Also, choosing the parameters of a Kalman filter is
apparently a black art.

Would it be worth it to recruit an electrical or systems engineer who
claimed to know something about filtering data to take a serious look at
NTPD's data filtering approach?  There has to be some reason that there is a
significant negative correlation between delay and offset in NTPD.  There
also has to be a reason that my GPS clock (BU-353, which, when it is working
well, only has offset ±6 ms from zero) has a difference between about 0 and
47 ms from an NTP server on another computer that gets its time from 8 NTP
stratum 2 servers over the Internet and has remarkably consistent offsets
±3.5 ms from zero.  The difference between the GPS clock and the average of
the stratum 2 servers appears to be a function of the time of day; it is
large during the mid-part of the day, when the Internet is busy and the
delay is large and quite variable between servers, and small late in the day
(right now it is -0.626; 6:55 PM EST), when the delay is smaller and pretty
uniform for all stratum 2 servers.

Charles Elliott

   

-Original Message-
From: questions-bounces+elliott.ch=verizon@lists.ntp.org
[mailto:questions-bounces+elliott.ch=verizon@lists.ntp.org] On
Behalf Of Chris Albertson
Sent: Thursday, March 15, 2012 5:22 PM
To: unruh
Cc: questions@lists.ntp.org
Subject: Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock
error.

On Thu, Mar 15, 2012 at 2:09 PM, unruhun...@invalid.ca  wrote:

 

Unfortunately it is not that simple. That rate changes by significan
amounts. Thus the rate you get after a week may be very different
   

than
 

the rate you get after an hour. That, I submit, is the chief obstacle
to having an accurate clock. And that change in rate does not fit
   

with
 

the Allan variance assumptions (the noise source is not of the type
assumed)
   

You are right about that.  I was going to add in a bit about how to
pick the best time to look at the clock tower.  But left it out because
the point I was making was only that these things are not NTP
specific.   Details after that did not contribute the the main point.


Chris Albertson
Redondo Beach, California
 




--

(PS - If you email me and don't get a quick response, don't be concerned.
I

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread Terje Mathisen


unruh wrote:

On 2012-03-14, David J Taylordavid-tay...@blueyonder.co.uk.invalid  wrote:

unruhun...@invalid.ca  wrote in message
news:I1T7r.36416$l12.35...@newsfe23.iad...
[]

Did you shut down and restart your computer? Did you perchance do this
during the daylight savings time transition on a Windows system? Could
the error be related to the fact that Windows like time on localtime not
UTC?


Windows uses UTC internally, not local time.  Local time is simply a
presentation layer issue.  Windows is unaffected by a DST transition.


That must be new, since windows certainly used to maintain system time
as local time. Caused numberous headaches for people using both Windows
and Linux.


Windows expects the CMOS BIOS clock to be in local time (which is the 
opposite from Linux), but then converts this twice: First to UTC in 
order to be able to use the NTP protocol, and to timestamp file updates 
with UTC, but then it converts back to local time for almost all 
timekeeping functions.


There is a Registry key which is supposed to allow Windows to use UTC in 
CMOS, but the only time I tried this (many years ago) it was somewhat 
broken.


Terje
--
- Terje.Mathisen at tmsw.no
almost all programming can be viewed as an exercise in caching

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread David J Taylor


Hi David,

I really appreciate all these suggestions you shared, as well as past 
ones.


Based somewhat on been there, done that!

If I decide to revamp my network, I'll probably put some of them into 
use.  However, that's not really practical right now.  All the 
networking gear is in the basement and all the PC's are upstairs.  I've 
already spent 2 months working on this GPS stuff and ignoring some other 
things I need to be doing.  I think I'm just going to focus on getting 
the Sure board up and running on a time server when it comes and, 
perhaps, use my BU-353 as a backup time source, and use the internet 
servers as a third level backup source.  Most of the time, I won't care 
what they're doing  Hopefully, I can spend less time thinking about time 
and just know that my PC's clocks are right.  Regardless, I'm going to 
continue to have an interest in the topic and have enjoyed all the 
discussions and learning that have occurred.  It's just that I have to 
do at least a few other things besides this.


Sincerely,

Ron


Yes, sensitive those these new GPS receivers are, the basement may not be 
the best location!  G  Be certain to get the Sure antenna in a good 
location - it's likely sealed for outdoor use such as stuck to a car roof.


I do see quite a wide variation in performance over Wi-Fi - I have two 
permanent PCs (Molde and Puffin) and two temporary PCs (Bergen and 
Mercury) connected at the moment, and averaged jitter varies a lot:


1.0 - 4.3 ms - Molde
1.1 - 2.1 ms - Puffin
1.3 - 3 ms - Bergen
4 - 12 ms - Mercury

 http://www.satsignal.eu/mrtg/performance_ntp.php

They are all synced to a Stratum-1 FreeBSD server showing microsecond 
jitter, running the same NTP, with the same configuration.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread David J Taylor



Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f61168b.8030...@c3energy.com...

[]

PS to my prior message.

I don't think the problem so much is the delay to the internet servers, 
or even to get out of my house.  NTPD is supposed to take care of that 
as long as it's pretty much symmetrical.  I think the problem is that 
the Windows clock is like a wild tiger that doesn't want to be tamed and 
which is running every which way.


Windows is not designed as a real-time OS, and its timekeeping is not as 
good as other systems, but with one good local server you can sync Windows 
PCs to that server with something like: minpoll 5 maxpoll 5.  Obviously, 
you would not do that over the Internet without permission.


For whatever reason, cpu load, heat, cosmic vibrations, whatever, the 
intrinsic frequency of the windows clock is always changing.  In order 
to avoid beating up on the internet servers too much, I have to poll 
them at least every 4 minutes apart.  If you let it, NTPD will extend 
that out to 16 minutes or more.  So, when the clock source is polled, 
say the PC clock is too fast, so NTPD slows it down.  Then, when you 
poll the clock source again, say the PC clock is too slow, so NTPD 
speeds it up.  Because of the varying intrinsic frequency of the clock, 
you can never find a clock speed that just works, because then the 
system goes and changes, by changes in the oscillator, how much time 
passes at those particular settings.  It's a battle you cannot win.  By 
polling my GPS every 8 seconds, I can keep the clock under control based 
on it's current needs which are varying second by second.  Of course, 
when discussing internet servers, 30 ms of jitter doesn't help any.


Windows itself doesn't vary the clock frequency unless you enable the 
power-saving frequency of the chipset.  What I /have/ seen on Windows is 
poorly written third-party drivers which hold off interrupts for too long 
or are otherwise badly behaved, and chipsets or motherboards which are 
equally unfriendly.  I have one application which can ruin timekeeping, 
given half a chance!  Note the scale on PC Gemini which has an AMD 
processor on an ASUS A8N SLI motherboard.  +/- 100 ms, not +/- 3 ms.  I 
see large offset steps, which NTP tries its best to keep up with.


[]
The point is, that it's a continually moving target.  The windows clock 
is the same way.  It never runs at the same frequency from minute to 
minute.  Even if you get it running right one minute, it's wrong the 
next.


All PCs are a continually moving target!  Some move more than others, but 
give a good PPS source, the major variation on even Windows PCs is due to 
temperature fluctuations.


Let's take, for example, the TAZ computer I mentioned earlier.  Forget 
GPS for the moment.  With the default settings, NTPD will eventually be 
polling the internet server every 16 minutes.  The problem is not 
exclusively that there is jitter in the time retrieved from the time 
server.  Let's also forget that for the moment.  Say we poll the 
internet server and it says the time is exactly 12:00:00.  Rounding to 
the seconds level just for simplicity, say my clock says 12:00:02, so 
I'm 2 seconds fast.  So, we slow down the clock by tweaking its 
parameters.  Then, we wait 16 more minutes.  Now the time server says 
12:16:00.  Say my clock says 12:15:57.  Now, I'm 3 seconds slow, so we 
speed the clock back up.  Now, theoretically, just like my pendulum 
clock, I should be able to get the parameters dialed in so the clock 
keeps time.  However, behind the scenes, the intrinsic operational speed 
changed.  While I'm sure I'm butchering the internal technicalities, 
let's say the clock has a speed knob, and if we set the speed knob to a 
value of 100, the the clock will count exactly 1 second while exactly 1 
second passes.  If this stayed true, NTPD would eventually set the speed 
knob at 100 and everybody would be happy.  But the intrinsic speed of 
the oscillator changed, so that now setting that knob at 100 now makes 
the clock think 1.03 seconds has passed when, in actuality, 1 second has 
passed.  So the clock is running fast.  So, NTPD dials the speed knob 
back to 97.  But now, the oscillator has changed again so that a setting 
of 97 now makes the clock think that .95 seconds have passed, when, in 
actuality, 1 second has passed.  This is why I'm getting such wild 
oscillation in the graph.  No matter what NTPD does to tweak the clock 
speed, and no matter how accurate that is at the time, that adjustment 
never has the same effect the next time the time server is polled.  Just 
as setting the screw on the pendulum of my mechanical clock doesn't have 
the same effect tomorrow as it does today.  There will never be a 
setting that just works.
 I don't think it's a game you can win on a standard windows computer. 
So, I'm not even inclined to play the internet NTP server game.  So, by 
polling my GPS every 8 seconds, the computer

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/15/2012 4:34 AM, David J Taylor wrote:


Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f61168b.8030...@c3energy.com...

[]

PS to my prior message.

I don't think the problem so much is the delay to the internet 
servers, or even to get out of my house.  NTPD is supposed to take 
care of that as long as it's pretty much symmetrical.  I think the 
problem is that the Windows clock is like a wild tiger that doesn't 
want to be tamed and which is running every which way.


Windows is not designed as a real-time OS, and its timekeeping is not 
as good as other systems, but with one good local server you can sync 
Windows PCs to that server with something like: minpoll 5 maxpoll 5.  
Obviously, you would not do that over the Internet without permission.


For whatever reason, cpu load, heat, cosmic vibrations, whatever, the 
intrinsic frequency of the windows clock is always changing.  In 
order to avoid beating up on the internet servers too much, I have to 
poll them at least every 4 minutes apart.  If you let it, NTPD will 
extend that out to 16 minutes or more.  So, when the clock source is 
polled, say the PC clock is too fast, so NTPD slows it down.  Then, 
when you poll the clock source again, say the PC clock is too slow, 
so NTPD speeds it up.  Because of the varying intrinsic frequency of 
the clock, you can never find a clock speed that just works, because 
then the system goes and changes, by changes in the oscillator, how 
much time passes at those particular settings.  It's a battle you 
cannot win.  By polling my GPS every 8 seconds, I can keep the clock 
under control based on it's current needs which are varying second by 
second.  Of course, when discussing internet servers, 30 ms of jitter 
doesn't help any.


Windows itself doesn't vary the clock frequency unless you enable the 
power-saving frequency of the chipset.  What I /have/ seen on Windows 
is poorly written third-party drivers which hold off interrupts for 
too long or are otherwise badly behaved, and chipsets or motherboards 
which are equally unfriendly.  I have one application which can ruin 
timekeeping, given half a chance!  Note the scale on PC Gemini which 
has an AMD processor on an ASUS A8N SLI motherboard.  +/- 100 ms, not 
+/- 3 ms.  I see large offset steps, which NTP tries its best to keep 
up with.




I mainly meant that operating conditions will vary the frequency of the 
oscillator.  Speaking of which, is there a way to run ntpd and have it 
NOT adjust the clock at all, but still generate stats files, so I can 
monitor the clock frequency just based on the computer usage and nothing 
else?


Can you elaborate on that power saving frequency thing?  Is that the 
thing in the control panel where you set the minimum and maximum cpu 
frequency?



[]
The point is, that it's a continually moving target.  The windows 
clock is the same way.  It never runs at the same frequency from 
minute to minute.  Even if you get it running right one minute, it's 
wrong the next.


All PCs are a continually moving target!  Some move more than others, 
but give a good PPS source, the major variation on even Windows PCs is 
due to temperature fluctuations.


Let's take, for example, the TAZ computer I mentioned earlier.  
Forget GPS for the moment.  With the default settings, NTPD will 
eventually be polling the internet server every 16 minutes.  The 
problem is not exclusively that there is jitter in the time retrieved 
from the time server.  Let's also forget that for the moment.  Say we 
poll the internet server and it says the time is exactly 12:00:00.  
Rounding to the seconds level just for simplicity, say my clock says 
12:00:02, so I'm 2 seconds fast.  So, we slow down the clock by 
tweaking its parameters.  Then, we wait 16 more minutes.  Now the 
time server says 12:16:00.  Say my clock says 12:15:57.  Now, I'm 3 
seconds slow, so we speed the clock back up.  Now, theoretically, 
just like my pendulum clock, I should be able to get the parameters 
dialed in so the clock keeps time.  However, behind the scenes, the 
intrinsic operational speed changed.  While I'm sure I'm butchering 
the internal technicalities, let's say the clock has a speed knob, 
and if we set the speed knob to a value of 100, the the clock will 
count exactly 1 second while exactly 1 second passes.  If this stayed 
true, NTPD would eventually set the speed knob at 100 and everybody 
would be happy.  But the intrinsic speed of the oscillator changed, 
so that now setting that knob at 100 now makes the clock think 1.03 
seconds has passed when, in actuality, 1 second has passed.  So the 
clock is running fast.  So, NTPD dials the speed knob back to 97.  
But now, the oscillator has changed again so that a setting of 97 now 
makes the clock think that .95 seconds have passed, when, in 
actuality, 1 second has passed.  This is why I'm getting such wild 
oscillation in the graph.  No matter what NTPD does to tweak the 
clock

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

On 3/14/2012 6:42 PM, E-Mail Sent to this address will be added to the 
BlackLists wrote:

Ron Frazier (NTP) wrote:
   

My typical performance from internet servers is offsets of + / - 60 ms.
 

# Why not try some that have a closer network distance, or are at least 
geographically closer?
# Georgia / Comcast Hints:

tos cohort 1
restrict source nomodify
pool us.pool.ntp.org iburst # supposed to give you 
geographically close servers

# server rolex.usg.edu iburst
# server timex.usg.edu iburst
# server ntp2.stsn.net iburst
# server tick.gatech.edu iburst
# server time.intersecur.net iburst
# server nist1-atl.ustiming.org iburst
# server nist1.columbiacountyga.gov iburst

# _Your_ ISP router is likely already picking up the closest couple of these 
all by itself already
# server ntp01.comcastbusiness.net iburst
# server ntp02.comcastbusiness.net iburst
# server ntp.whm.comcastcommercial.net iburst
# server ntp01.inflow.pa.bo.comcast.net iburst
# server ntp02.inflow.pa.bo.comcast.net iburst
# server ntp01.cmc.co.denver.comcast.net iburst
# server ntp02.cmc.co.denver.comcast.net iburst
# server cr01.atlanta.ga.ibone.comcast.net iburst
# server pr01.atlanta.ga.ibone.comcast.net iburst
# server pe02.56marietta.ga.ibone.comcast.net iburst
# server te-0-1-0-4-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-1-4-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-2-2-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-1-5-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-4-3-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-0-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-0-10-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-3-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-4-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-4-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-0-0-0-0-pe01.56marietta.ga.ibone.comcast.net iburst
# ...

   


Thanks for this info.  This is a very cool server list.  It's obviously 
relevant to my location.  I'm not sure just how you did that.  I'm going 
to keep this for reference.  For the moment, I have to spend my time on 
getting my GPS(s) working and setting up my own time server.  However, 
later, I might try some tinkering to improve the internet server 
performance.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread David J Taylor

Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f61e4df.4080...@c3energy.com...

[]
I mainly meant that operating conditions will vary the frequency of the 
oscillator.  Speaking of which, is there a way to run ntpd and have it 
NOT adjust the clock at all, but still generate stats files, so I can 
monitor the clock frequency just based on the computer usage and nothing 
else?


Pass.  What happens if everything is noselect?

Can you elaborate on that power saving frequency thing?  Is that the 
thing in the control panel where you set the minimum and maximum cpu 
frequency?


Likely, yes, but it varies between computers, chip makers (under different 
trade names), and BIOS makers.  For best timekeeping, you want no clock 
speed variation.


[]

 http://www.satsignal.eu/mrtg/performance_bacchus.php


Wow, if I'm reading that graph right in the last link, that cpu usage 
spike sent your clock variation from about 100 us to 4000 us.  That's 
amazing, and frustrating.


The offset went from zero, to approximately +1.2 milliseconds.  As MRTG 
can't plot negative numbers (it was designed for network throughput), I 
add 3.0 milliseconds to the reported offsets before plotting, as the left 
axis label says.  So the range of the graph is +/- 3.0 milliseconds, 
plotted as 0 to 6ms.


I thought all 32 bit Windows had the same kernel.  You could try this 
defragger.  I've had good luck with it, but I'm not sure which older 
systems it works on.


http://www.auslogics.com/en/software/disk-defrag/

[]

Sincerely,

Ron


Thanks for the suggestion, Ron, but that software, like most others, needs 
XP or higher.  I actually use that program on one of my PCs, as it can 
also be called from the command-line to defragment files or directories.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

On 2012-03-14, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote:
 On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:
 On 3/14/2012 4:00 PM, David J Taylor wrote:
 Hi David T,

 NOW  you understand.

 I have 4 PC's connected to the LAN, plus my wife's work computer 3 
 days / week, and on rare occasions my son's computer.  All are 
 connected by wifi.  All do pretty mundane things: web browser, 
 email, sometimes downloading patches, sometimes doing online 
 backup.  My 4 are running NTPD.  3 run windows most of the time and 
 dual boot into linux.  My 4th machine runs linux all the time.  When 
 my wife is here, she does a remote desktop type of thing into her 
 work system.  Two of my PC's are running Vista, one is running 
 Windows 7.  Those three dual boot into Ubuntu 11.04 and the always 
 linux machine runs Ubuntu 11.04.  Almost all the discussions I've 
 had on this mailing list are for my Windows 7 machine.

 The path out of my house is:

 PC Wifi -- Wifi router -- wired router -- cable modem -- ISP --  
 internet

 - is this PC connected over wireless or wired?


 Wifi G

 - what else is going through the router?  Someone else downloading 
 large files or using streaming audio or video?


 See above.  Normally, no huge data hogs.

 - who else might be sharing your connection?


 It's cable.  Who knows?  I also get cable TV and telephone through 
 the same wire.

 - what type of service do you have?  Presumably not dial-up!  But 
 what speed?


 Comcast Cable

 Just tested it with speedtest.net
  Ping to near city: 91 ms, Download: 29.63 Mbps, Upload: 5.3 Mbps

 - having checked you speed, would you describe your connection as 
 stable?


 See above for speed.  Generally, it's very stable.  However, for the 
 purposes we're discussing, I think it's latencies and delays that 
 are the problem.

 As I mentioned in my reply to David L, I'm not concerned over trying 
 to get stellar performance from internet servers.  I just want to 
 get a good GPS server system running and use the internet servers as 
 a backup.

 Sincerely,

 Ron

 Ron,

 Thanks for that clarification.  I think you should be getting /very 
 much/ better performance from your Internet servers.  That ping is 
 poor as well. Here I have 30 Mb/s down, just 1 Mb/s up, and NTP 
 delays show as 18-34 ms (most in 22-30 ms).

 To that end, if your cable modem has multiple ports, connect one of 
 the PCs direct to the CM and run it as your local NTP server.  Wi-Fi 
 doesn't help NTP.  Later, you can add GPS/PPS to that PC as well.  At 
 the very least, connect your timekeeping PC direct to the wired 
 router.  No Wi-Fi! For my main NTP server, I got a low-powered and 
 fan-less Intel Atom system, and it runs FreeBSD.  It /only/ runs NTP, 
 no interactive stuff at all.

 You might also consider getting rid of the two routers and just using 
 the wireless one.  You might also see whether you can run NTP on your 
 router - perhaps it's a model which can run the DD-WRT firmware.  I 
 think some variants of DD-WRT can run NTP, but please check.  I have 
 a WRT 54GL in my system where I run the DD-WRT firmware.

  http://www.dd-wrt.com/site/index

 Online backup could well affect the performance of the connection for 
 timekeeping, and your imminent Sure GPS/PPS will help enormously.

 Just some thoughts which may help you along the way.

 Cheers,
 David


 Hi David,

 I really appreciate all these suggestions you shared, as well as past 
 ones.  If I decide to revamp my network, I'll probably put some of 
 them into use.  However, that's not really practical right now.  All 
 the networking gear is in the basement and all the PC's are upstairs.  
 I've already spent 2 months working on this GPS stuff and ignoring 
 some other things I need to be doing.  I think I'm just going to focus 
 on getting the Sure board up and running on a time server when it 
 comes and, perhaps, use my BU-353 as a backup time source, and use the 
 internet servers as a third level backup source.  Most of the time, I 
 won't care what they're doing  Hopefully, I can spend less time 
 thinking about time and just know that my PC's clocks are right.  
 Regardless, I'm going to continue to have an interest in the topic and 
 have enjoyed all the discussions and learning that have occurred.  
 It's just that I have to do at least a few other things besides this.

 Sincerely,

 Ron



 PS to my prior message.

 I don't think the problem so much is the delay to the internet servers, 
 or even to get out of my house.  NTPD is supposed to take care of that 
 as long as it's pretty much symmetrical.  I think the problem is that 
 the Windows clock is like a wild tiger that doesn't want to be tamed and 
 which is running every which way.  For whatever reason, cpu load, heat, 
 cosmic vibrations, whatever, the intrinsic frequency of the windows 
 clock is always changing.  In order to avoid beating up on the internet 
 servers too much, I have to poll them at least every

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/15/2012 11:42 AM, unruh wrote:

On 2012-03-14, Ron Frazier (NTP)timekeepingntpl...@c3energy.com  wrote:
   

On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:
 

On 3/14/2012 4:00 PM, David J Taylor wrote:
   

Hi David T,

NOW  you understand.

   


snip


PS to my prior message.

I don't think the problem so much is the delay to the internet servers,
or even to get out of my house.  NTPD is supposed to take care of that
as long as it's pretty much symmetrical.  I think the problem is that
the Windows clock is like a wild tiger that doesn't want to be tamed and
which is running every which way.  For whatever reason, cpu load, heat,
cosmic vibrations, whatever, the intrinsic frequency of the windows
clock is always changing.  In order to avoid beating up on the internet
servers too much, I have to poll them at least every 4 minutes apart.
If you let it, NTPD will extend that out to 16 minutes or more.  So,
 

Actually, the effective NTPD poll interval is abotu 8 times the stated
interval. The clock filter throws away about 7 out of 8 poll results in
an attempt to get rid of assmetric polls. Ie, it assumes that the
shortest round trip interval out of the past 8 is the best estimate of
the symmetric roundtrip and throws away the rest. Thus if you have
polling every 4 min  (poll interval 8) the effective interval is about
every half hour.

That is fine if the clock is an even half way reasonable clock (Ie rate does
not change by more than say 2PPM over that time)


   


You're saying the effective polling interval is 8x what minpoll is. 
 However, if the access policy for a NIST server is no more than 20 
times per hour or every 3 minutes, and I set minpoll to 6 or 
approximately every minute, even if the clock algorithm throws away 7 of 
8 samples; am I not still sampling?  Am I not still hitting the NIST 
server every minute and are they not going to ban me from accessing it 
if that continues?



when the clock source is polled, say the PC clock is too fast, so NTPD
slows it down.  Then, when you poll the clock source again, say the PC
clock is too slow, so NTPD speeds it up.  Because of the varying
intrinsic frequency of the clock, you can never find a clock speed that
just works, because then the system goes and changes, by changes in the
oscillator, how much time passes at those particular settings.  It's a
battle you cannot win.  By polling my GPS every 8 seconds, I can keep
the clock under control based on it's current needs which are varying
second by second.  Of course, when discussing internet servers, 30 ms of
 

What are you talking about. There is no evicence either in your data or
in any reports by anyone of 30ms variation is network offsets.
Even on ADSL, it is in the microsecond range, not millisecond.


   


I'm not sure exactly what you're asking.  If you're referring to my 
comment about internet peer jitter, I occasionally see jitter numbers 
for internet peers on the Meinberg Time server monitor screen in the 20 
- 30 ms range and more frequently see numbers in the 10 - 20 ms range 
for jitter.  Here is a recent screen shot:


http://dl.dropbox.com/u/9879631/internet%20jitter%20example.jpg

Note that there are three peers with jitter in the 10 - 20 ms range.

If you were asking about the offsets my computers experience using the 
internet as a time source, my TAZ computer polls the internet 
exclusively and it's offsets routinely fluctuate + / - 50 ms.


http://dl.dropbox.com/u/9879631/TAZ%20loopstats%202012-03-07%20to%202012-03-14.jpg
http://dl.dropbox.com/u/9879631/ntp.conf-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120313-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120314-TAZ

Sincerely,

Ron


jitter doesn't help any.


snip


--

(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] ARRGH!!! I woke up to a 50 SECOND clock error.

On 2012-03-15, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote:
 On 3/15/2012 11:42 AM, unruh wrote:
 On 2012-03-14, Ron Frazier (NTP)timekeepingntpl...@c3energy.com  wrote:

 On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:
  
 On 3/14/2012 4:00 PM, David J Taylor wrote:

 Hi David T,

 NOW  you understand.



snip

 PS to my prior message.

 I don't think the problem so much is the delay to the internet servers,
 or even to get out of my house.  NTPD is supposed to take care of that
 as long as it's pretty much symmetrical.  I think the problem is that
 the Windows clock is like a wild tiger that doesn't want to be tamed and
 which is running every which way.  For whatever reason, cpu load, heat,
 cosmic vibrations, whatever, the intrinsic frequency of the windows
 clock is always changing.  In order to avoid beating up on the internet
 servers too much, I have to poll them at least every 4 minutes apart.
 If you let it, NTPD will extend that out to 16 minutes or more.  So,
  
 Actually, the effective NTPD poll interval is abotu 8 times the stated
 interval. The clock filter throws away about 7 out of 8 poll results in
 an attempt to get rid of assmetric polls. Ie, it assumes that the
 shortest round trip interval out of the past 8 is the best estimate of
 the symmetric roundtrip and throws away the rest. Thus if you have
 polling every 4 min  (poll interval 8) the effective interval is about
 every half hour.

 That is fine if the clock is an even half way reasonable clock (Ie rate does
 not change by more than say 2PPM over that time)




 You're saying the effective polling interval is 8x what minpoll is. 
   However, if the access policy for a NIST server is no more than 20 
 times per hour or every 3 minutes, and I set minpoll to 6 or 
 approximately every minute, even if the clock algorithm throws away 7 of 
 8 samples; am I not still sampling?  Am I not still hitting the NIST 
 server every minute and are they not going to ban me from accessing it 
 if that continues?

Yes. The poll interval is whatever you ( or ntp sets it to). Ie, it goes
to the externam machine to get data that often. However, ntpd only uses
approximately 20% of the values it gets from that remote machine. Thus
as far as the ntp algorithm on your machine is concerned its effective
poll interval is much longer. 

But why in the world are you going to the NIST servers for your time?
Use the pool. A stratum 2 or 3 server can certainly give you the ms
accuracy you apparently want. And if you are using gps, the only purpose
of the remote servers is a) fallback, and b) getting the second right.
None of those require NIST. 
You can cut your polling of NIST to infinity without affecting your
time.





 when the clock source is polled, say the PC clock is too fast, so NTPD
 slows it down.  Then, when you poll the clock source again, say the PC
 clock is too slow, so NTPD speeds it up.  Because of the varying
 intrinsic frequency of the clock, you can never find a clock speed that
 just works, because then the system goes and changes, by changes in the
 oscillator, how much time passes at those particular settings.  It's a
 battle you cannot win.  By polling my GPS every 8 seconds, I can keep
 the clock under control based on it's current needs which are varying
 second by second.  Of course, when discussing internet servers, 30 ms of
  
 What are you talking about. There is no evicence either in your data or
 in any reports by anyone of 30ms variation is network offsets.
 Even on ADSL, it is in the microsecond range, not millisecond.




 I'm not sure exactly what you're asking.  If you're referring to my 
 comment about internet peer jitter, I occasionally see jitter numbers 
 for internet peers on the Meinberg Time server monitor screen in the 20 
 - 30 ms range and more frequently see numbers in the 10 - 20 ms range 
 for jitter.  Here is a recent screen shot:

 http://dl.dropbox.com/u/9879631/internet%20jitter%20example.jpg

 Note that there are three peers with jitter in the 10 - 20 ms range.

Then there is something extremely wrong with those peers. Stop using
them. 



 If you were asking about the offsets my computers experience using the 
 internet as a time source, my TAZ computer polls the internet 
 exclusively and it's offsets routinely fluctuate + / - 50 ms.

 http://dl.dropbox.com/u/9879631/TAZ%20loopstats%202012-03-07%20to%202012-03-14.jpg
 http://dl.dropbox.com/u/9879631/ntp.conf-TAZ
 http://dl.dropbox.com/u/9879631/loopstats.20120313-TAZ
 http://dl.dropbox.com/u/9879631/loopstats.20120314-TAZ

AGain, that is not usual and indicates something is wrong. It is not use
use of the internet. Something else is very wrong. Using an internet
peer 50ms away I get jitter of less than 100us. (not ms), and I think
that experience is far more typical. If it is your network that is the
problem then it is especially silly to use a source like NIST, since its
is being totally

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.



On 2012-03-15, Ron Frazier (NTP)timekeepingntpl...@c3energy.com  wrote:
   

On 3/15/2012 11:42 AM, unruh wrote:
 

On 2012-03-14, Ron Frazier (NTP)timekeepingntpl...@c3energy.com   wrote:

   

On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:

 

On 3/14/2012 4:00 PM, David J Taylor wrote:

   

Hi David T,

NOW  you understand.


   

snip

 

PS to my prior message.

I don't think the problem so much is the delay to the internet servers,
or even to get out of my house.  NTPD is supposed to take care of that
as long as it's pretty much symmetrical.  I think the problem is that
the Windows clock is like a wild tiger that doesn't want to be tamed and
which is running every which way.  For whatever reason, cpu load, heat,
cosmic vibrations, whatever, the intrinsic frequency of the windows
clock is always changing.  In order to avoid beating up on the internet
servers too much, I have to poll them at least every 4 minutes apart.
If you let it, NTPD will extend that out to 16 minutes or more.  So,

 

Actually, the effective NTPD poll interval is abotu 8 times the stated
interval. The clock filter throws away about 7 out of 8 poll results in
an attempt to get rid of assmetric polls. Ie, it assumes that the
shortest round trip interval out of the past 8 is the best estimate of
the symmetric roundtrip and throws away the rest. Thus if you have
polling every 4 min  (poll interval 8) the effective interval is about
every half hour.

That is fine if the clock is an even half way reasonable clock (Ie rate does
not change by more than say 2PPM over that time)



   

You're saying the effective polling interval is 8x what minpoll is.
   However, if the access policy for a NIST server is no more than 20
times per hour or every 3 minutes, and I set minpoll to 6 or
approximately every minute, even if the clock algorithm throws away 7 of
8 samples; am I not still sampling?  Am I not still hitting the NIST
server every minute and are they not going to ban me from accessing it
if that continues?
 

Yes. The poll interval is whatever you ( or ntp sets it to). Ie, it goes
to the externam machine to get data that often. However, ntpd only uses
approximately 20% of the values it gets from that remote machine. Thus
as far as the ntp algorithm on your machine is concerned its effective
poll interval is much longer.

But why in the world are you going to the NIST servers for your time?
Use the pool. A stratum 2 or 3 server can certainly give you the ms
accuracy you apparently want. And if you are using gps, the only purpose
of the remote servers is a) fallback, and b) getting the second right.
None of those require NIST.
You can cut your polling of NIST to infinity without affecting your
time.


   


Allow me to explain.  A long time ago in a galaxy far far away, I wanted 
to synchronize the clocks of my Windows machines.  This was before I 
knew anything about Linux or NTP.  However, being a US citizen, I knew 
our government provided the National Institute of Standards and 
Technology (NIST) agency, and that they had a Time and Frequency 
division, just to help handle such things for US citizens and the world. 
 So, I went here to the Time and Frequency division (the link address 
may have changed over time):


http://www.nist.gov/pml/div688/

And then here to the Internet Time Service:

http://www.nist.gov/pml/div688/grp40/its.cfm

And I downloaed their little Windows time program here:

http://www.nist.gov/pml/div688/grp40/upload/nistime-32bit.exe

This thing is designed to poll the NIST servers (and only the NIST 
servers) up to every 4 hours and set your clock.  That's all it does, 
and I don't think it tries to tinker with the clock frequency.  I ran 
that for many years, and still, sometimes, would get a couple of seconds 
drift between polling intervals.  There is nothing on the website to 
discourage average Joe users from using the system.


A couple of years ago, I learned about and started using Ubuntu.  For 
timekeeping there, I used NTP.  At the time, there was a graphical 
interface to it and I picked about 8 random servers by ticking the check 
boxes and let it run.


Back around Christmas 2011, I got some atomic wall clocks and an atomic 
watch and got fascinated with the idea of getting more accuracy for the 
PC's.  That led me to doing reserach and that led me to install the 
Meinberg port of NTP.  Of course, then, I had to figure out how to add 
servers and set up ntp.conf.


In answer to your question, I'm using NIST because:

 a) My government provides it and, through their website, 
encourages the public to use it.

 b) I was familiar with it.
 c) I thought it would be more accurate.

Having said that, I could discontinue using it if the need arises.

So, I put 4 NIST servers, 4 stratum 2 servers, 4 US pool servers, and 
just for good measure, the Ubuntu time server in my ntp.conf.  Since all 
queries exiting my house show the same

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread Chris Albertson

 Basically you have a trade-off between frequency error and time offset.
 IIRC, polling quickly will reduce the offset, but you get greater frequency
 variations.


There is nothing magic about NTP.   You have the exact same trade off
if you try and sync your wrist watch to the big town clock on the
tower.

If you look at the tower every hour and set the wrist watch to match
you will have very small offset between the watch and the big clock.
But if you do this the _rate_ of your wrist watch will never be
spot-on except by luck.

On the other hand if you sync your watch once then wait a week or a
month to see how much it has gained or lost you may see quite a bit of
offset but now you have good data on the relative rates of the two
clocks

NTP did not invent this trade off, it existed 200 years ago.




Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

On 2012-03-15, Chris Albertson albertson.ch...@gmail.com wrote:
 Basically you have a trade-off between frequency error and time offset.
 IIRC, polling quickly will reduce the offset, but you get greater frequency
 variations.


 There is nothing magic about NTP.   You have the exact same trade off
 if you try and sync your wrist watch to the big town clock on the
 tower.

 If you look at the tower every hour and set the wrist watch to match
 you will have very small offset between the watch and the big clock.
 But if you do this the _rate_ of your wrist watch will never be
 spot-on except by luck.

 On the other hand if you sync your watch once then wait a week or a
 month to see how much it has gained or lost you may see quite a bit of
 offset but now you have good data on the relative rates of the two
 clocks

 NTP did not invent this trade off, it existed 200 years ago.

Unfortunately it is not that simple. That rate changes by significan
amounts. Thus the rate you get after a week may be very different than
the rate you get after an hour. That, I submit, is the chief obstacle to
having an accurate clock. And that change in rate does not fit with the
Allan variance assumptions (the noise source is not of the type
assumed)






 Chris Albertson
 Redondo Beach, California

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

On 2012-03-15, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote:

 On 2012-03-15, Ron Frazier (NTP)timekeepingntpl...@c3energy.com  wrote:

 On 3/15/2012 11:42 AM, unruh wrote:
  
 On 2012-03-14, Ron Frazier (NTP)timekeepingntpl...@c3energy.com   wrote:


 On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:

  
 On 3/14/2012 4:00 PM, David J Taylor wrote:


 Hi David T,

 NOW  you understand.



 snip

  
 PS to my prior message.

 I don't think the problem so much is the delay to the internet servers,
 or even to get out of my house.  NTPD is supposed to take care of that
 as long as it's pretty much symmetrical.  I think the problem is that
 the Windows clock is like a wild tiger that doesn't want to be tamed and
 which is running every which way.  For whatever reason, cpu load, heat,
 cosmic vibrations, whatever, the intrinsic frequency of the windows
 clock is always changing.  In order to avoid beating up on the internet
 servers too much, I have to poll them at least every 4 minutes apart.
 If you let it, NTPD will extend that out to 16 minutes or more.  So,

  
 Actually, the effective NTPD poll interval is abotu 8 times the stated
 interval. The clock filter throws away about 7 out of 8 poll results in
 an attempt to get rid of assmetric polls. Ie, it assumes that the
 shortest round trip interval out of the past 8 is the best estimate of
 the symmetric roundtrip and throws away the rest. Thus if you have
 polling every 4 min  (poll interval 8) the effective interval is about
 every half hour.

 That is fine if the clock is an even half way reasonable clock (Ie rate 
 does
 not change by more than say 2PPM over that time)




 You're saying the effective polling interval is 8x what minpoll is.
However, if the access policy for a NIST server is no more than 20
 times per hour or every 3 minutes, and I set minpoll to 6 or
 approximately every minute, even if the clock algorithm throws away 7 of
 8 samples; am I not still sampling?  Am I not still hitting the NIST
 server every minute and are they not going to ban me from accessing it
 if that continues?
  
 Yes. The poll interval is whatever you ( or ntp sets it to). Ie, it goes
 to the externam machine to get data that often. However, ntpd only uses
 approximately 20% of the values it gets from that remote machine. Thus
 as far as the ntp algorithm on your machine is concerned its effective
 poll interval is much longer.

 But why in the world are you going to the NIST servers for your time?
 Use the pool. A stratum 2 or 3 server can certainly give you the ms
 accuracy you apparently want. And if you are using gps, the only purpose
 of the remote servers is a) fallback, and b) getting the second right.
 None of those require NIST.
 You can cut your polling of NIST to infinity without affecting your
 time.




 Allow me to explain.  A long time ago in a galaxy far far away, I wanted 
 to synchronize the clocks of my Windows machines.  This was before I 
 knew anything about Linux or NTP.  However, being a US citizen, I knew 
 our government provided the National Institute of Standards and 
 Technology (NIST) agency, and that they had a Time and Frequency 
 division, just to help handle such things for US citizens and the world. 
   So, I went here to the Time and Frequency division (the link address 
 may have changed over time):

 http://www.nist.gov/pml/div688/

 And then here to the Internet Time Service:

 http://www.nist.gov/pml/div688/grp40/its.cfm

 And I downloaed their little Windows time program here:

 http://www.nist.gov/pml/div688/grp40/upload/nistime-32bit.exe

 This thing is designed to poll the NIST servers (and only the NIST 
 servers) up to every 4 hours and set your clock.  That's all it does, 
 and I don't think it tries to tinker with the clock frequency.  I ran 
 that for many years, and still, sometimes, would get a couple of seconds 
 drift between polling intervals.  There is nothing on the website to 
 discourage average Joe users from using the system.

 A couple of years ago, I learned about and started using Ubuntu.  For 
 timekeeping there, I used NTP.  At the time, there was a graphical 
 interface to it and I picked about 8 random servers by ticking the check 
 boxes and let it run.

 Back around Christmas 2011, I got some atomic wall clocks and an atomic 
 watch and got fascinated with the idea of getting more accuracy for the 
 PC's.  That led me to doing reserach and that led me to install the 
 Meinberg port of NTP.  Of course, then, I had to figure out how to add 
 servers and set up ntp.conf.

 In answer to your question, I'm using NIST because:

   a) My government provides it and, through their website, 
 encourages the public to use it.
   b) I was familiar with it.
   c) I thought it would be more accurate.

 Having said that, I could discontinue using it if the need arises.

And since your early forays into

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread Chris Albertson

On Thu, Mar 15, 2012 at 2:09 PM, unruh un...@invalid.ca wrote:

 Unfortunately it is not that simple. That rate changes by significan
 amounts. Thus the rate you get after a week may be very different than
 the rate you get after an hour. That, I submit, is the chief obstacle to
 having an accurate clock. And that change in rate does not fit with the
 Allan variance assumptions (the noise source is not of the type
 assumed)

You are right about that.  I was going to add in a bit about how to
pick the best time to look at the clock tower.  But left it out
because the point I was making was only that these things are not NTP
specific.   Details after that did not contribute the the main point.


Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-15 Thread Chuck Swiger

On Mar 15, 2012, at 2:06 PM, unruh wrote:
 Before hitting on 13 different servers, it would be better tofigure out
 what the problem is that is giving you such lousy results.

It's not hard to make an educated guess as to the cause; since the topology is:

PC Wifi -- Wifi router -- wired router -- cable modem -- ISP -- internet

WiFi radios are half-duplex since only one radio can be sending at a time, else 
you get a backoff similar to ethernet collisions on a hub.  If the WiFi link is 
idle (and nobody else is using 2.4 GHz bands nearby!), one ought to be able to 
get reasonably good timing, but as soon as there is any significant congestion 
from other machines (or phones, tablets, etc), a wireless NTP client will 
experience heavy jitter on the level of tens of milliseconds.

[ That doesn't get Ron up to 120ms, but if double-NAT is going on, or the 
routers aren't playing nice with each other for some other reason, it wouldn't 
be surprising to end up with marginal timekeeping results.  Plug something 
directly into ethernet jack on the wired router and retry ]

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


Hi David,

OK, you've convinced me.  I've put noselect on the GPS and taken it away 
on the New York NIST server.  The NY NIST server is now preferred and 
polling from 1 - 4 minutes.  Hopefully they won't ban me for hitting it 
too often.  I think the NIST server will have more jitter, particularly 
as the polling interval increases, but we'll see what happens.


Sincerely,

Ron


It will be interesting to see what difference that makes, Ron, and I look 
forward to seeing the graphs.


Personally, I saw little to choose between the various Internet servers 
you had, and I would have allowed four or five to be selected rather than 
just one, as that would not then leave NTP open to failure of the one 
server, and it would allow NTP to select what It believes to be the best.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

unruh un...@invalid.ca wrote in message 
news:I1T7r.36416$l12.35...@newsfe23.iad...

[]

Did you shut down and restart your computer? Did you perchance do this
during the daylight savings time transition on a Windows system? Could
the error be related to the fact that Windows like time on localtime not
UTC?


Windows uses UTC internally, not local time.  Local time is simply a 
presentation layer issue.  Windows is unaffected by a DST transition.


David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-14 Thread unruh

On 2012-03-13, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote:
Hi all,

I just woke up to a 50 SECOND clock error. Prior to the error, with my
PC locked into the GPS and the internet servers noselected, here's what
my peerstats looked like. Baseline is the GPS. Colored lines are
internet servers.

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Looking at this graph, I see that the nmea source was already difting
before the sudden jump. It lost 30ms wrt the other servers in the 20
hours beforehand. Then it went crazy for a while and jumped to 80 ms
ahead. I agree that this does seem to be that gps device. Which one is
it?

But that jump is 120ms not 50 sec.

I recently had a Garmin 18 go nuts-- giving massive amounts of noise.

Here is what was showing on the Meinberg Time Server Monitor when I woke up:

http://dl.dropbox.com/u/9879631/drifting02a%20-%20insane.jpg

And the graph of the peerstats for that time:

http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg

The clock error was REAL, as confirmed by my atomic wrist watch.

However, the loopstats graph for the same time period shows no problem
with the GPS:

http://dl.dropbox.com/u/9879631/drifting02c%20-%20gps%20NOT%20insane.jpg

So, I shut down NTPD and reset the time with a batch file that calls
ntpdate and querys the New York NIST server:

http://dl.dropbox.com/u/9879631/drifting02d%20-%20set%20with%20ntpdate.jpg

Here is the time server monitor shortly after NTPD restart:

http://dl.dropbox.com/u/9879631/drifting02e%20-%20shortly%20after%20ntpd%20restart.jpg

And after a 2nd restart:

http://dl.dropbox.com/u/9879631/drifting02f%20-%202nd%20ntpd%20restart%20after%20insane.jpg

And here are the current peerstats, which look normal. The offset to
the internet servers tends to drift and will eventually cross the zero
line and get positive.

http://dl.dropbox.com/u/9879631/drifting02g%20-%20peerstats%20after%20insane%20and%202nd%20reset.jpg

The GPS appears to have been stable all through this, and was never
powered off or unplugged. It looks like NTPD went crazy and reset my
clock for some reason.

It also reset all of the remote servers at the same time? Since it was
an offset of your system with respect to the remote systems.

Here are the peerstats and loopstats during the insane period.

http://dl.dropbox.com/u/9879631/loopstats.20120313-1-restart%20around%201350%20utc
http://dl.dropbox.com/u/9879631/peerstats.20120313-1-insane

Here is my current ntp.conf:

http://dl.dropbox.com/u/9879631/ntp.conf

My system is Windows 7, NTP 4.2.7p259, GPS GlobalSat BU-353 USB NMEA
only with GPGGA sentence at 57,600 baud.

If anyone can shed some light on what happened, please do. It's driving
me bonkers. I don't believe the GPS is at fault, and I suspect NTPD.

Again, the remote servers all agree. The GPS time does not (driving your
system time) .

Thanks in advance.

Sincerely,

Ron

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-14 Thread David Lord


Ron Frazier (NTP) wrote:

On 3/13/2012 5:39 PM, David Lord wrote:

Ron Frazier (NTP) wrote:

On 3/13/2012 2:40 PM, Chris Albertson wrote:

On Tue, Mar 13, 2012 at 9:52 AM, Ron Frazier (NTP)
timekeepingntpl...@c3energy.com  wrote:

Hi all,

I just woke up to a 50 SECOND clock error.  Prior to the error, 
with my PC
locked into the GPS and the internet servers noselected, here's 
what my
peerstats looked like.  Baseline is the GPS.  Colored lines are 
internet

servers.

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Looks to me like that GPS, maybe lock lock and was able to coast on
hold over for a while then fell off a cliff. If you have a log of
satellite  signal to noise ratios you might be able to figure out why.

The internet servers appear to be 100% reliable seeing as they all 
agree.


These kinds of things are why some hobbysts end up buying multiple GPS
(different brands)  Otherwise it is hard to sort out a GPS firmware
bug from a solar storm or just that there were not sats visable to
your indoor antenna for a few minutes

I think your goal is to learn about all of this so these problems are
a good thing.  No one learns much from working systems.   But if the
goal is a reliable NTP server, the pool NTP servers can't be beat
except by a good timing mode GPS, that has good self diagnostics and
PPS.  The self diagnostics part is important


The link you quoted just now is not the one that bugs me so much 
today.  This one is the one that bugs me today, where my clock was 
stepped by 50 seconds for some reason.


http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg


I'm on a text mostly system so why do you require me to use
a web browser to help you?

What is your current ntp.conf, ntpd version, operating system
and response of ntpq -crv -p after ntpd has had at least
a day to stabilise?

Not so long ago you posted that you had an offset within
+/- 6 ms but didn't give any evidence. Response from
ntpq -crv -p or better a day from peer_summary or couple
of days from loop_summary would be enough.


David


When I get the Sure board, I plan to hang it on the pc in tandem with 
this GPS and compare.


Sincerely,

Ron




Hi David L.,

I just figured the images and dropbox would be the fastest way to 
distribute the information.  I didn't think I could attach files to 
messages going to the NTP questions mailing list.


I'll be glad to provide stats files if anyone is interested.  Just tell 
me how to distribute them.


Based on advice from David Taylor, I just changed my configuration.  
Previously, I had only the GPS selectable and the internet servers 
noselected for testing purposes to try to determine where a slow 
drifting behavior is coming from.  Now, I have changed that so the GPS 
is noselected and the New York NIST server is the preferred and only 
selectable peer.  I am monitoring the GPS and other internet servers for 
comparison.  So, it will be a couple of days before this configuration 
accumulates some stats files.


Even though I have been tinkering with this GPS for a couple of months, 
I have never seen anything like the 50 second jump I started this thread 
about.  That problem may not be reproducible for some time, if at all.


Faulty GPS, incorrect configuration, anybodies guess?

Internet servers give me an rms offset about 610us, whilst GPS
with PPS gives about 4us. There are day to day variations and
some rare 'events' when GPS or an internet server goes bad.

GPS without PPS, Globalsat BR304, wasn't worth using as ntp
source due to large variations in offset from the NMEA sentences
that were tried with RMC being best giving 50% of offsets under
10ms but maximum offsets being near 100ms.

MSF radioclock mostly has offset below 1500us.

DCF radioclock can have offset below 100us but reception is too
variable being non existant for some periods each day.

I use mrtg to monitor my servers because it's easy to see when
a fault occurs but the graphs don't help to locate the cause.


(1) Internet servers only, rms offset 609us:

loopstats.20120313
loop 71, 368+/-1360.5, rms 608.7, freq 1.24+/-0.173, var 0.112

peerstats.20120313
   ident cnt mean rms  max delay dist disp
==
81.187.61.74  70   -0.1230.5061.2550.416   21.959   10.600
158.152.1.76  690.1180.9272.025   17.864   28.174   10.205
130.88.200.4  706.0991.6863.553   23.694   33.833   10.345
90.155.53.94  68   -0.0341.1272.952   17.376   29.720   10.938
79.135.97.79  710.5730.7221.388   31.522   38.183   10.618
130.159.196.117   750.3130.9671.830   27.958   35.9169.516


(2) GPS with PPS, local and internet servers, rms offset 3.4us:

loopstats.20120313
loop 1350, 4+/-25.6, rms 3.4, freq -35.28+/-0.222, var 0.067

peerstats.20120313
   ident cnt mean rms  max delay

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/14/2012 2:46 AM, David J Taylor wrote:

Hi David,

OK, you've convinced me.  I've put noselect on the GPS and taken it 
away on the New York NIST server.  The NY NIST server is now 
preferred and polling from 1 - 4 minutes.  Hopefully they won't ban 
me for hitting it too often.  I think the NIST server will have more 
jitter, particularly as the polling interval increases, but we'll see 
what happens.


Sincerely,

Ron


It will be interesting to see what difference that makes, Ron, and I 
look forward to seeing the graphs.


Personally, I saw little to choose between the various Internet 
servers you had, and I would have allowed four or five to be selected 
rather than just one, as that would not then leave NTP open to failure 
of the one server, and it would allow NTP to select what It believes 
to be the best.


Cheers,
David



Hi David,

OK.  You asked for it.  8-)

When I'm through testing, I'll open up the other internet servers as a 
backup in case the GPS fails.  For now, I'm just running with one clock 
source at a time.  Still trying to document and chase down this 
wandering effect.


I ran with NY NIST as the only selectable clock source and monitoring 
the GPS for comparison all night.  The results were horrible.  My 
offsets from NIST time were in the + 65 ms / - 75 ms range.  I had the 
polling interval set to start at 1 minute and go up to 4 minutes.  There 
is way too much clock wander to even think about testing the accuracy of 
the GPS.  I've gone back to polling the GPS every 8 seconds as the sole 
selectable clock source and monitoring the internet servers for 
comparison.  Over the short term, minutes to hours, my GPS, even with 
NMEA only, is by far the most accurate time source I have.  Even if the 
NMEA signal wanders 70 ms either way over the course of a few days, it 
won't get any further off than I did using the internet server, and the 
clock will be much more consistent over shorter time frames.


Here are the graphs.

http://dl.dropbox.com/u/9879631/nynist01.jpg
http://dl.dropbox.com/u/9879631/nynist02.jpg

Sincerely,

Ron


PS - By the way, I've changed my ntp.conf a few times since I originally 
started this thread, including the one in dropbox.  What's in there now 
is my current ntp.conf, not the one that was in there when I started the 
thread.




--

(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] ARRGH!!! I woke up to a 50 SECOND clock error.

On 3/14/2012 3:03 AM, unruh wrote:

On 2012-03-13, Ron Frazier (NTP)timekeepingntpl...@c3energy.com wrote:

Hi all,

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

But that jump is 120ms not 50 sec.

I recently had a Garmin 18 go nuts-- giving massive amounts of noise.

That's very interesting. David Taylor also said he saw this NMEA
wandering effect on the Garmin. Did your Garmin recover? And, is it
based on a SIRF chipset?

In another thread, someone else with a BU-353 said he saw an offset
storm like the one in my graph.

Sincerely,

Ron

Here is what was showing on the Meinberg Time Server Monitor when I woke up:

http://dl.dropbox.com/u/9879631/drifting02a%20-%20insane.jpg

And the graph of the peerstats for that time:

http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg

The clock error was REAL, as confirmed by my atomic wrist watch.

However, the loopstats graph for the same time period shows no problem
with the GPS:

http://dl.dropbox.com/u/9879631/drifting02c%20-%20gps%20NOT%20insane.jpg

So, I shut down NTPD and reset the time with a batch file that calls
ntpdate and querys the New York NIST server:

http://dl.dropbox.com/u/9879631/drifting02d%20-%20set%20with%20ntpdate.jpg

Here is the time server monitor shortly after NTPD restart:

http://dl.dropbox.com/u/9879631/drifting02e%20-%20shortly%20after%20ntpd%20restart.jpg

And after a 2nd restart:

http://dl.dropbox.com/u/9879631/drifting02f%20-%202nd%20ntpd%20restart%20after%20insane.jpg

And here are the current peerstats, which look normal. The offset to
the internet servers tends to drift and will eventually cross the zero
line and get positive.

http://dl.dropbox.com/u/9879631/drifting02g%20-%20peerstats%20after%20insane%20and%202nd%20reset.jpg

The GPS appears to have been stable all through this, and was never
powered off or unplugged. It looks like NTPD went crazy and reset my
clock for some reason.

It also reset all of the remote servers at the same time? Since it was
an offset of your system with respect to the remote systems.

Here are the peerstats and loopstats during the insane period.

http://dl.dropbox.com/u/9879631/loopstats.20120313-1-restart%20around%201350%20utc
http://dl.dropbox.com/u/9879631/peerstats.20120313-1-insane

Here is my current ntp.conf:

http://dl.dropbox.com/u/9879631/ntp.conf

My system is Windows 7, NTP 4.2.7p259, GPS GlobalSat BU-353 USB NMEA
only with GPGGA sentence at 57,600 baud.

If anyone can shed some light on what happened, please do. It's driving
me bonkers. I don't believe the GPS is at fault, and I suspect NTPD.

Again, the remote servers all agree. The GPS time does not (driving your
system time) .

Thanks in advance.

Sincerely,

Ron

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/14/2012 7:14 AM, David Lord wrote:

Ron Frazier (NTP) wrote:

On 3/13/2012 5:39 PM, David Lord wrote:

Ron Frazier (NTP) wrote:

On 3/13/2012 2:40 PM, Chris Albertson wrote:

On Tue, Mar 13, 2012 at 9:52 AM, Ron Frazier (NTP)
timekeepingntpl...@c3energy.com  wrote:

Hi all,

I just woke up to a 50 SECOND clock error.  Prior to the error, 
with my PC
locked into the GPS and the internet servers noselected, here's 
what my
peerstats looked like.  Baseline is the GPS.  Colored lines are 
internet

servers.

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Looks to me like that GPS, maybe lock lock and was able to coast on
hold over for a while then fell off a cliff. If you have a log of
satellite  signal to noise ratios you might be able to figure out 
why.


The internet servers appear to be 100% reliable seeing as they all 
agree.


These kinds of things are why some hobbysts end up buying multiple 
GPS

(different brands)  Otherwise it is hard to sort out a GPS firmware
bug from a solar storm or just that there were not sats visable to
your indoor antenna for a few minutes

I think your goal is to learn about all of this so these problems are
a good thing.  No one learns much from working systems.   But if the
goal is a reliable NTP server, the pool NTP servers can't be beat
except by a good timing mode GPS, that has good self diagnostics and
PPS.  The self diagnostics part is important


The link you quoted just now is not the one that bugs me so much 
today.  This one is the one that bugs me today, where my clock was 
stepped by 50 seconds for some reason.


http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg 



I'm on a text mostly system so why do you require me to use
a web browser to help you?

What is your current ntp.conf, ntpd version, operating system
and response of ntpq -crv -p after ntpd has had at least
a day to stabilise?

Not so long ago you posted that you had an offset within
+/- 6 ms but didn't give any evidence. Response from
ntpq -crv -p or better a day from peer_summary or couple
of days from loop_summary would be enough.


David


When I get the Sure board, I plan to hang it on the pc in tandem 
with this GPS and compare.


Sincerely,

Ron




Hi David L.,

I just figured the images and dropbox would be the fastest way to 
distribute the information.  I didn't think I could attach files to 
messages going to the NTP questions mailing list.


I'll be glad to provide stats files if anyone is interested.  Just 
tell me how to distribute them.


Based on advice from David Taylor, I just changed my configuration.  
Previously, I had only the GPS selectable and the internet servers 
noselected for testing purposes to try to determine where a slow 
drifting behavior is coming from.  Now, I have changed that so the 
GPS is noselected and the New York NIST server is the preferred and 
only selectable peer.  I am monitoring the GPS and other internet 
servers for comparison.  So, it will be a couple of days before this 
configuration accumulates some stats files.


Even though I have been tinkering with this GPS for a couple of 
months, I have never seen anything like the 50 second jump I started 
this thread about.  That problem may not be reproducible for some 
time, if at all.


Faulty GPS, incorrect configuration, anybodies guess?

Internet servers give me an rms offset about 610us, whilst GPS
with PPS gives about 4us. There are day to day variations and
some rare 'events' when GPS or an internet server goes bad.



You must LIVE on the internet backbone and have blazing fast routers to 
get performance like that.  My typical performance from internet servers 
is offsets of + / - 60 ms.



GPS without PPS, Globalsat BR304, wasn't worth using as ntp
source due to large variations in offset from the NMEA sentences
that were tried with RMC being best giving 50% of offsets under
10ms but maximum offsets being near 100ms.



With my BU-353, which is similar, by setting the baud rate to 57,600, 
programming for ONLY GPGGA sentence, and polling every 8 seconds, I can 
keep my offsets from the GPS's estimate of true time to usually around + 
/ - 5 ms with spikes to 10 ms and almost never higher.  If I use ONLY 
the GPZDA sentence, which is essentially fixed length and reports only 
time, I can get that down to + / - 3 ms most of the time with spikes to 
6 ms.  However, David Taylor pointed out that the GPZDA sentence doesn't 
have any validity check field, and the GPGGA sentence does.  We verified 
that the refclock.c code does check for this.  So, I'm back to using 
GPGGA even with a bit more jitter.  That way, if the GPS fails, ntpd is 
more likely to react gracefully.


The problem with using my BU-353 in this way is that the start times for 
the NMEA sentence seem to wander over about 60 ms in either direction 
over a period of about 4 days.  So, over a few days, my computer's time 
will drift away from true UTC time by that amount, and back

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


Hi David,

OK.  You asked for it.  8-)


Well, I actually suggested /all/ the Internet servers being enabled, 
allowing NTP to make its best choice.


When I'm through testing, I'll open up the other internet servers as a 
backup in case the GPS fails.  For now, I'm just running with one clock 
source at a time.  Still trying to document and chase down this 
wandering effect.


I ran with NY NIST as the only selectable clock source and monitoring 
the GPS for comparison all night.  The results were horrible.  My 
offsets from NIST time were in the + 65 ms / - 75 ms range.  I had the 
polling interval set to start at 1 minute and go up to 4 minutes.  There 
is way too much clock wander to even think about testing the accuracy of 
the GPS.  I've gone back to polling the GPS every 8 seconds as the sole 
selectable clock source and monitoring the internet servers for 
comparison.  Over the short term, minutes to hours, my GPS, even with 
NMEA only, is by far the most accurate time source I have.  Even if the 
NMEA signal wanders 70 ms either way over the course of a few days, it 
won't get any further off than I did using the internet server, and the 
clock will be much more consistent over shorter time frames.


Here are the graphs.

http://dl.dropbox.com/u/9879631/nynist01.jpg
http://dl.dropbox.com/u/9879631/nynist02.jpg

Sincerely,

Ron


I'm not surprised that using a single Internet server is worse than the 
GPS/USB, but that's not how NTP is designed to work.  With two or more 
Internet servers active, your GPS 50-second glitch would not have affected 
your PC's timekeeping anything like as severely, when you have the GPS/USB 
included to help improve the offset and more like the narrow band (about 
15 milliseconds wide) shown in:


 http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/14/2012 10:41 AM, David J Taylor wrote:

Hi David,

OK.  You asked for it.  8-)


Well, I actually suggested /all/ the Internet servers being enabled, 
allowing NTP to make its best choice.


When I'm through testing, I'll open up the other internet servers as 
a backup in case the GPS fails.  For now, I'm just running with one 
clock source at a time.  Still trying to document and chase down this 
wandering effect.


I ran with NY NIST as the only selectable clock source and monitoring 
the GPS for comparison all night.  The results were horrible.  My 
offsets from NIST time were in the + 65 ms / - 75 ms range.  I had 
the polling interval set to start at 1 minute and go up to 4 
minutes.  There is way too much clock wander to even think about 
testing the accuracy of the GPS.  I've gone back to polling the GPS 
every 8 seconds as the sole selectable clock source and monitoring 
the internet servers for comparison.  Over the short term, minutes to 
hours, my GPS, even with NMEA only, is by far the most accurate time 
source I have.  Even if the NMEA signal wanders 70 ms either way over 
the course of a few days, it won't get any further off than I did 
using the internet server, and the clock will be much more consistent 
over shorter time frames.


Here are the graphs.

http://dl.dropbox.com/u/9879631/nynist01.jpg
http://dl.dropbox.com/u/9879631/nynist02.jpg

Sincerely,

Ron


I'm not surprised that using a single Internet server is worse than 
the GPS/USB, but that's not how NTP is designed to work.  With two or 
more Internet servers active, your GPS 50-second glitch would not have 
affected your PC's timekeeping anything like as severely, when you 
have the GPS/USB included to help improve the offset and more like the 
narrow band (about 15 milliseconds wide) shown in:


 http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Cheers,
David



OK.  Here are the loopstats from another computer for 7 days (in the 
chart).  I don't have any peerstats for it.  It has the same server 
list.  One is preferred.  All servers are active.  Performance is no better.


http://dl.dropbox.com/u/9879631/TAZ%20loopstats%202012-03-07%20to%202012-03-14.jpg
http://dl.dropbox.com/u/9879631/ntp.conf-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120313-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120314-TAZ

Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-14 Thread David Lord


Ron Frazier (NTP) wrote:


On 3/14/2012 7:14 AM, David Lord wrote:

Ron Frazier (NTP) wrote:




Based on advice from David Taylor, I just changed my configuration.  
Previously, I had only the GPS selectable and the internet servers 
noselected for testing purposes to try to determine where a slow 
drifting behavior is coming from.  Now, I have changed that so the 
GPS is noselected and the New York NIST server is the preferred and 
only selectable peer.  I am monitoring the GPS and other internet 
servers for comparison.  So, it will be a couple of days before this 
configuration accumulates some stats files.


Even though I have been tinkering with this GPS for a couple of 
months, I have never seen anything like the 50 second jump I started 
this thread about.  That problem may not be reproducible for some 
time, if at all.


Faulty GPS, incorrect configuration, anybodies guess?

Internet servers give me an rms offset about 610us, whilst GPS
with PPS gives about 4us. There are day to day variations and
some rare 'events' when GPS or an internet server goes bad.



You must LIVE on the internet backbone and have blazing fast routers to 
get performance like that.  My typical performance from internet servers 
is offsets of + / - 60 ms.


Hi Ron

I don't live on the internet backbone nor do I have  blazingly
fast anything. I have a slow 2Mbit/s ADSL connection.

You must have a very broken internet connection to get offsets
that high. A few times I've been routed by satelite or some
wireless connection and I also sometimes use mobile broadband
but still don't see offsets as large as 60ms.





GPS without PPS, Globalsat BR304, wasn't worth using as ntp
source due to large variations in offset from the NMEA sentences
that were tried with RMC being best giving 50% of offsets under
10ms but maximum offsets being near 100ms.



With my BU-353, which is similar, by setting the baud rate to 57,600, 
programming for ONLY GPGGA sentence, and polling every 8 seconds, I can 
keep my offsets from the GPS's estimate of true time to usually around + 
/ - 5 ms with spikes to 10 ms and almost never higher.  If I use ONLY 
the GPZDA sentence, which is essentially fixed length and reports only 
time, I can get that down to + / - 3 ms most of the time with spikes to 
6 ms.  However, David Taylor pointed out that the GPZDA sentence doesn't 
have any validity check field, and the GPGGA sentence does.  We verified 
that the refclock.c code does check for this.  So, I'm back to using 
GPGGA even with a bit more jitter.  That way, if the GPS fails, ntpd is 
more likely to react gracefully.



What are you using as a reference to verify the offsets you
get are offsets from UTC?


The problem with using my BU-353 in this way is that the start times for 
the NMEA sentence seem to wander over about 60 ms in either direction 
over a period of about 4 days.  So, over a few days, my computer's time 
will drift away from true UTC time by that amount, and back again.  
However, over the short term, my pc's clock is much more stable than if 
I use internet servers as my primary source.


Can you give your ntp.conf that result in that level of
offset from internet servers?

The ntp distribution might still have some advice and
tools for selection of suitable sources. I just select
from the list of uk public servers at ntp.org and try
each one to get rtt and their sources then select the
ones that are closest with different sources. If you
don't want to do that you can specify your local ntp
pool. You should select at least four sources. I have
about eight different sources split between
ntp0.lordynet.org and ntp1.lordynet.org.


David

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f60bc0c.8040...@c3energy.com...

[]
OK.  Here are the loopstats from another computer for 7 days (in the 
chart).  I don't have any peerstats for it.  It has the same server 
list.  One is preferred.  All servers are active.  Performance is no 
better.


http://dl.dropbox.com/u/9879631/TAZ%20loopstats%202012-03-07%20to%202012-03-14.jpg
http://dl.dropbox.com/u/9879631/ntp.conf-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120313-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120314-TAZ

Sincerely,

Ron


That's horrible, Ron!  Much worse than David Lord reports.  It makes me 
want to ask a number of questions:


- is this PC connected over wireless or wired?

- what else is going through the router?  Someone else downloading large 
files or using streaming audio or video?


- who else might be sharing your connection?

- what type of service do you have?  Presumably not dial-up!  But what 
speed?


- having checked you speed, would you describe your connection as 
stable?


The quiet periods (e.g early Monday morning, Tuesday lunchtime) are much 
nearer to what I would hope for, which makes me wonder whether something 
is interfering with the connection outside those times.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-14 Thread unruh

On 2012-03-14, David J Taylor david-tay...@blueyonder.co.uk.invalid wrote:
 unruh un...@invalid.ca wrote in message 
 news:I1T7r.36416$l12.35...@newsfe23.iad...
 []
 Did you shut down and restart your computer? Did you perchance do this
 during the daylight savings time transition on a Windows system? Could
 the error be related to the fact that Windows like time on localtime not
 UTC?

 Windows uses UTC internally, not local time.  Local time is simply a 
 presentation layer issue.  Windows is unaffected by a DST transition.

That must be new, since windows certainly used to maintain system time
as local time. Caused numberous headaches for people using both Windows
and Linux. 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-14 Thread unruh

On 2012-03-14, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote:
On 3/14/2012 3:03 AM, unruh wrote:
On 2012-03-13, Ron Frazier (NTP)timekeepingntpl...@c3energy.com wrote:

Hi all,

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

But that jump is 120ms not 50 sec.

I recently had a Garmin 18 go nuts-- giving massive amounts of noise.

That's very interesting. David Taylor also said he saw this NMEA
wandering effect on the Garmin. Did your Garmin recover? And, is it
based on a SIRF chipset?

No idea. It is the old Garmin 18LVC (not 18x)

In another thread, someone else with a BU-353 said he saw an offset
storm like the one in my graph.

Sincerely,

Ron

Here is what was showing on the Meinberg Time Server Monitor when I woke up:

http://dl.dropbox.com/u/9879631/drifting02a%20-%20insane.jpg

And the graph of the peerstats for that time:

http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg

The clock error was REAL, as confirmed by my atomic wrist watch.

However, the loopstats graph for the same time period shows no problem
with the GPS:

http://dl.dropbox.com/u/9879631/drifting02c%20-%20gps%20NOT%20insane.jpg

So, I shut down NTPD and reset the time with a batch file that calls
ntpdate and querys the New York NIST server:

http://dl.dropbox.com/u/9879631/drifting02d%20-%20set%20with%20ntpdate.jpg

Here is the time server monitor shortly after NTPD restart:

http://dl.dropbox.com/u/9879631/drifting02e%20-%20shortly%20after%20ntpd%20restart.jpg

And after a 2nd restart:

http://dl.dropbox.com/u/9879631/drifting02f%20-%202nd%20ntpd%20restart%20after%20insane.jpg

And here are the current peerstats, which look normal. The offset to
the internet servers tends to drift and will eventually cross the zero
line and get positive.

http://dl.dropbox.com/u/9879631/drifting02g%20-%20peerstats%20after%20insane%20and%202nd%20reset.jpg

The GPS appears to have been stable all through this, and was never
powered off or unplugged. It looks like NTPD went crazy and reset my
clock for some reason.

It also reset all of the remote servers at the same time? Since it was
an offset of your system with respect to the remote systems.

Here are the peerstats and loopstats during the insane period.

http://dl.dropbox.com/u/9879631/loopstats.20120313-1-restart%20around%201350%20utc
http://dl.dropbox.com/u/9879631/peerstats.20120313-1-insane

Here is my current ntp.conf:

http://dl.dropbox.com/u/9879631/ntp.conf

My system is Windows 7, NTP 4.2.7p259, GPS GlobalSat BU-353 USB NMEA
only with GPGGA sentence at 57,600 baud.

If anyone can shed some light on what happened, please do. It's driving
me bonkers. I don't believe the GPS is at fault, and I suspect NTPD.

Again, the remote servers all agree. The GPS time does not (driving your
system time) .

Thanks in advance.

Sincerely,

Ron

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

unruh un...@invalid.ca wrote in message 
news:HI48r.39505$zd5.1...@newsfe12.iad...

On 2012-03-14, David J Taylor  wrote:

[]

Windows uses UTC internally, not local time.  Local time is simply a
presentation layer issue.  Windows is unaffected by a DST transition.


That must be new, since windows certainly used to maintain system time
as local time. Caused numberous headaches for people using both Windows
and Linux.


Not new at all.  It's been that way since 1992 for the whole of the NT 
family.  Perhaps you are thinking of what is stored in the real-time clock 
chip?  Windows and UNIX have different conventions for that, Windows using 
wall-clock time.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/14/2012 12:35 PM, David J Taylor wrote:
Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f60bc0c.8040...@c3energy.com...

[]
OK.  Here are the loopstats from another computer for 7 days (in the 
chart).  I don't have any peerstats for it.  It has the same server 
list.  One is preferred.  All servers are active.  Performance is no 
better.


http://dl.dropbox.com/u/9879631/TAZ%20loopstats%202012-03-07%20to%202012-03-14.jpg 


http://dl.dropbox.com/u/9879631/ntp.conf-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120313-TAZ
http://dl.dropbox.com/u/9879631/loopstats.20120314-TAZ

Sincerely,

Ron


That's horrible, Ron!  Much worse than David Lord reports.  It makes 
me want to ask a number of questions:




Hi David T,

NOW  you understand.

I have 4 PC's connected to the LAN, plus my wife's work computer 3 days 
/ week, and on rare occasions my son's computer.  All are connected by 
wifi.  All do pretty mundane things: web browser, email, sometimes 
downloading patches, sometimes doing online backup.  My 4 are running 
NTPD.  3 run windows most of the time and dual boot into linux.  My 4th 
machine runs linux all the time.  When my wife is here, she does a 
remote desktop type of thing into her work system.  Two of my PC's are 
running Vista, one is running Windows 7.  Those three dual boot into 
Ubuntu 11.04 and the always linux machine runs Ubuntu 11.04.  Almost all 
the discussions I've had on this mailing list are for my Windows 7 machine.


The path out of my house is:

PC Wifi -- Wifi router -- wired router -- cable modem -- ISP -- internet


- is this PC connected over wireless or wired?



Wifi G

- what else is going through the router?  Someone else downloading 
large files or using streaming audio or video?




See above.  Normally, no huge data hogs.


- who else might be sharing your connection?



It's cable.  Who knows?  I also get cable TV and telephone through the 
same wire.


- what type of service do you have?  Presumably not dial-up!  But what 
speed?




Comcast Cable

Just tested it with speedtest.net
 Ping to near city: 91 ms, Download: 29.63 Mbps, Upload: 5.3 Mbps

- having checked you speed, would you describe your connection as 
stable?




See above for speed.  Generally, it's very stable.  However, for the 
purposes we're discussing, I think it's latencies and delays that are 
the problem.


As I mentioned in my reply to David L, I'm not concerned over trying to 
get stellar performance from internet servers.  I just want to get a 
good GPS server system running and use the internet servers as a backup.


Sincerely,

Ron

The quiet periods (e.g early Monday morning, Tuesday lunchtime) are 
much nearer to what I would hope for, which makes me wonder whether 
something is interfering with the connection outside those times.


Cheers,
David





--

(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] ARRGH!!! I woke up to a 50 SECOND clock error.


Hi David T,

NOW  you understand.

I have 4 PC's connected to the LAN, plus my wife's work computer 3 days 
/ week, and on rare occasions my son's computer.  All are connected by 
wifi.  All do pretty mundane things: web browser, email, sometimes 
downloading patches, sometimes doing online backup.  My 4 are running 
NTPD.  3 run windows most of the time and dual boot into linux.  My 4th 
machine runs linux all the time.  When my wife is here, she does a 
remote desktop type of thing into her work system.  Two of my PC's are 
running Vista, one is running Windows 7.  Those three dual boot into 
Ubuntu 11.04 and the always linux machine runs Ubuntu 11.04.  Almost all 
the discussions I've had on this mailing list are for my Windows 7 
machine.


The path out of my house is:

PC Wifi -- Wifi router -- wired router -- cable modem -- ISP --  
internet



- is this PC connected over wireless or wired?



Wifi G

- what else is going through the router?  Someone else downloading 
large files or using streaming audio or video?




See above.  Normally, no huge data hogs.


- who else might be sharing your connection?



It's cable.  Who knows?  I also get cable TV and telephone through the 
same wire.


- what type of service do you have?  Presumably not dial-up!  But what 
speed?




Comcast Cable

Just tested it with speedtest.net
 Ping to near city: 91 ms, Download: 29.63 Mbps, Upload: 5.3 Mbps

- having checked you speed, would you describe your connection as 
stable?




See above for speed.  Generally, it's very stable.  However, for the 
purposes we're discussing, I think it's latencies and delays that are 
the problem.


As I mentioned in my reply to David L, I'm not concerned over trying to 
get stellar performance from internet servers.  I just want to get a 
good GPS server system running and use the internet servers as a backup.


Sincerely,

Ron


Ron,

Thanks for that clarification.  I think you should be getting /very much/ 
better performance from your Internet servers.  That ping is poor as well. 
Here I have 30 Mb/s down, just 1 Mb/s up, and NTP delays show as 18-34 ms 
(most in 22-30 ms).


To that end, if your cable modem has multiple ports, connect one of the 
PCs direct to the CM and run it as your local NTP server.  Wi-Fi doesn't 
help NTP.  Later, you can add GPS/PPS to that PC as well.  At the very 
least, connect your timekeeping PC direct to the wired router.  No Wi-Fi! 
For my main NTP server, I got a low-powered and fan-less Intel Atom 
system, and it runs FreeBSD.  It /only/ runs NTP, no interactive stuff at 
all.


You might also consider getting rid of the two routers and just using the 
wireless one.  You might also see whether you can run NTP on your router - 
perhaps it's a model which can run the DD-WRT firmware.  I think some 
variants of DD-WRT can run NTP, but please check.  I have a WRT 54GL in my 
system where I run the DD-WRT firmware.


 http://www.dd-wrt.com/site/index

Online backup could well affect the performance of the connection for 
timekeeping, and your imminent Sure GPS/PPS will help enormously.


Just some thoughts which may help you along the way.

Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/14/2012 4:00 PM, David J Taylor wrote:

Hi David T,

NOW  you understand.

I have 4 PC's connected to the LAN, plus my wife's work computer 3 
days / week, and on rare occasions my son's computer.  All are 
connected by wifi.  All do pretty mundane things: web browser, email, 
sometimes downloading patches, sometimes doing online backup.  My 4 
are running NTPD.  3 run windows most of the time and dual boot into 
linux.  My 4th machine runs linux all the time.  When my wife is 
here, she does a remote desktop type of thing into her work system.  
Two of my PC's are running Vista, one is running Windows 7.  Those 
three dual boot into Ubuntu 11.04 and the always linux machine runs 
Ubuntu 11.04.  Almost all the discussions I've had on this mailing 
list are for my Windows 7 machine.


The path out of my house is:

PC Wifi -- Wifi router -- wired router -- cable modem -- ISP --  
internet



- is this PC connected over wireless or wired?



Wifi G

- what else is going through the router?  Someone else downloading 
large files or using streaming audio or video?




See above.  Normally, no huge data hogs.


- who else might be sharing your connection?



It's cable.  Who knows?  I also get cable TV and telephone through 
the same wire.


- what type of service do you have?  Presumably not dial-up!  But 
what speed?




Comcast Cable

Just tested it with speedtest.net
 Ping to near city: 91 ms, Download: 29.63 Mbps, Upload: 5.3 Mbps

- having checked you speed, would you describe your connection as 
stable?




See above for speed.  Generally, it's very stable.  However, for the 
purposes we're discussing, I think it's latencies and delays that are 
the problem.


As I mentioned in my reply to David L, I'm not concerned over trying 
to get stellar performance from internet servers.  I just want to get 
a good GPS server system running and use the internet servers as a 
backup.


Sincerely,

Ron


Ron,

Thanks for that clarification.  I think you should be getting /very 
much/ better performance from your Internet servers.  That ping is 
poor as well. Here I have 30 Mb/s down, just 1 Mb/s up, and NTP delays 
show as 18-34 ms (most in 22-30 ms).


To that end, if your cable modem has multiple ports, connect one of 
the PCs direct to the CM and run it as your local NTP server.  Wi-Fi 
doesn't help NTP.  Later, you can add GPS/PPS to that PC as well.  At 
the very least, connect your timekeeping PC direct to the wired 
router.  No Wi-Fi! For my main NTP server, I got a low-powered and 
fan-less Intel Atom system, and it runs FreeBSD.  It /only/ runs NTP, 
no interactive stuff at all.


You might also consider getting rid of the two routers and just using 
the wireless one.  You might also see whether you can run NTP on your 
router - perhaps it's a model which can run the DD-WRT firmware.  I 
think some variants of DD-WRT can run NTP, but please check.  I have a 
WRT 54GL in my system where I run the DD-WRT firmware.


 http://www.dd-wrt.com/site/index

Online backup could well affect the performance of the connection for 
timekeeping, and your imminent Sure GPS/PPS will help enormously.


Just some thoughts which may help you along the way.

Cheers,
David



Hi David,

I really appreciate all these suggestions you shared, as well as past 
ones.  If I decide to revamp my network, I'll probably put some of them 
into use.  However, that's not really practical right now.  All the 
networking gear is in the basement and all the PC's are upstairs.  I've 
already spent 2 months working on this GPS stuff and ignoring some other 
things I need to be doing.  I think I'm just going to focus on getting 
the Sure board up and running on a time server when it comes and, 
perhaps, use my BU-353 as a backup time source, and use the internet 
servers as a third level backup source.  Most of the time, I won't care 
what they're doing  Hopefully, I can spend less time thinking about time 
and just know that my PC's clocks are right.  Regardless, I'm going to 
continue to have an interest in the topic and have enjoyed all the 
discussions and learning that have occurred.  It's just that I have to 
do at least a few other things besides this.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

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


On 3/14/2012 5:04 PM, Ron Frazier (NTP) wrote:

On 3/14/2012 4:00 PM, David J Taylor wrote:

Hi David T,

NOW  you understand.

I have 4 PC's connected to the LAN, plus my wife's work computer 3 
days / week, and on rare occasions my son's computer.  All are 
connected by wifi.  All do pretty mundane things: web browser, 
email, sometimes downloading patches, sometimes doing online 
backup.  My 4 are running NTPD.  3 run windows most of the time and 
dual boot into linux.  My 4th machine runs linux all the time.  When 
my wife is here, she does a remote desktop type of thing into her 
work system.  Two of my PC's are running Vista, one is running 
Windows 7.  Those three dual boot into Ubuntu 11.04 and the always 
linux machine runs Ubuntu 11.04.  Almost all the discussions I've 
had on this mailing list are for my Windows 7 machine.


The path out of my house is:

PC Wifi -- Wifi router -- wired router -- cable modem -- ISP --  
internet



- is this PC connected over wireless or wired?



Wifi G

- what else is going through the router?  Someone else downloading 
large files or using streaming audio or video?




See above.  Normally, no huge data hogs.


- who else might be sharing your connection?



It's cable.  Who knows?  I also get cable TV and telephone through 
the same wire.


- what type of service do you have?  Presumably not dial-up!  But 
what speed?




Comcast Cable

Just tested it with speedtest.net
 Ping to near city: 91 ms, Download: 29.63 Mbps, Upload: 5.3 Mbps

- having checked you speed, would you describe your connection as 
stable?




See above for speed.  Generally, it's very stable.  However, for the 
purposes we're discussing, I think it's latencies and delays that 
are the problem.


As I mentioned in my reply to David L, I'm not concerned over trying 
to get stellar performance from internet servers.  I just want to 
get a good GPS server system running and use the internet servers as 
a backup.


Sincerely,

Ron


Ron,

Thanks for that clarification.  I think you should be getting /very 
much/ better performance from your Internet servers.  That ping is 
poor as well. Here I have 30 Mb/s down, just 1 Mb/s up, and NTP 
delays show as 18-34 ms (most in 22-30 ms).


To that end, if your cable modem has multiple ports, connect one of 
the PCs direct to the CM and run it as your local NTP server.  Wi-Fi 
doesn't help NTP.  Later, you can add GPS/PPS to that PC as well.  At 
the very least, connect your timekeeping PC direct to the wired 
router.  No Wi-Fi! For my main NTP server, I got a low-powered and 
fan-less Intel Atom system, and it runs FreeBSD.  It /only/ runs NTP, 
no interactive stuff at all.


You might also consider getting rid of the two routers and just using 
the wireless one.  You might also see whether you can run NTP on your 
router - perhaps it's a model which can run the DD-WRT firmware.  I 
think some variants of DD-WRT can run NTP, but please check.  I have 
a WRT 54GL in my system where I run the DD-WRT firmware.


 http://www.dd-wrt.com/site/index

Online backup could well affect the performance of the connection for 
timekeeping, and your imminent Sure GPS/PPS will help enormously.


Just some thoughts which may help you along the way.

Cheers,
David



Hi David,

I really appreciate all these suggestions you shared, as well as past 
ones.  If I decide to revamp my network, I'll probably put some of 
them into use.  However, that's not really practical right now.  All 
the networking gear is in the basement and all the PC's are upstairs.  
I've already spent 2 months working on this GPS stuff and ignoring 
some other things I need to be doing.  I think I'm just going to focus 
on getting the Sure board up and running on a time server when it 
comes and, perhaps, use my BU-353 as a backup time source, and use the 
internet servers as a third level backup source.  Most of the time, I 
won't care what they're doing  Hopefully, I can spend less time 
thinking about time and just know that my PC's clocks are right.  
Regardless, I'm going to continue to have an interest in the topic and 
have enjoyed all the discussions and learning that have occurred.  
It's just that I have to do at least a few other things besides this.


Sincerely,

Ron




PS to my prior message.

I don't think the problem so much is the delay to the internet servers, 
or even to get out of my house.  NTPD is supposed to take care of that 
as long as it's pretty much symmetrical.  I think the problem is that 
the Windows clock is like a wild tiger that doesn't want to be tamed and 
which is running every which way.  For whatever reason, cpu load, heat, 
cosmic vibrations, whatever, the intrinsic frequency of the windows 
clock is always changing.  In order to avoid beating up on the internet 
servers too much, I have to poll them at least every 4 minutes apart.  
If you let it, NTPD will extend that out to 16 minutes or more.  So, 
when the clock source is polled, say the PC

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

Ron Frazier (NTP) wrote:
 My typical performance from internet servers is offsets of + / - 60 ms.

# Why not try some that have a closer network distance, or are at least 
geographically closer?
# Georgia / Comcast Hints:

tos cohort 1
restrict source nomodify
pool us.pool.ntp.org iburst # supposed to give you 
geographically close servers

# server rolex.usg.edu iburst
# server timex.usg.edu iburst
# server ntp2.stsn.net iburst
# server tick.gatech.edu iburst
# server time.intersecur.net iburst
# server nist1-atl.ustiming.org iburst
# server nist1.columbiacountyga.gov iburst

# _Your_ ISP router is likely already picking up the closest couple of these 
all by itself already
# server ntp01.comcastbusiness.net iburst
# server ntp02.comcastbusiness.net iburst
# server ntp.whm.comcastcommercial.net iburst
# server ntp01.inflow.pa.bo.comcast.net iburst
# server ntp02.inflow.pa.bo.comcast.net iburst
# server ntp01.cmc.co.denver.comcast.net iburst
# server ntp02.cmc.co.denver.comcast.net iburst
# server cr01.atlanta.ga.ibone.comcast.net iburst
# server pr01.atlanta.ga.ibone.comcast.net iburst
# server pe02.56marietta.ga.ibone.comcast.net iburst
# server te-0-1-0-4-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-1-4-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-2-2-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-1-5-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-4-3-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-0-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-0-10-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-3-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-4-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-4-12-0-0-cr01.atlanta.ga.ibone.comcast.net iburst
# server pos-0-0-0-0-pe01.56marietta.ga.ibone.comcast.net iburst
# ...

-- 
E-Mail Sent to this address blackl...@anitech-systems.com
  will be added to the BlackLists.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-14 Thread Rick Jones

Any chance these PCs are using a timesource (in the system somewhere)
that isn't constant in the face of power management events?

The other pink tiger (vs elephant) in your house could/would be the
wifi - at least in terms of being a stable network type.  Some of
the bufferbloat http://www.bufferbloat.net/ folks have little nice
to say about wireless.

rick jones
http://www.netperf.org/
-- 
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
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] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread David J Taylor


Hi all,

I just woke up to a 50 SECOND clock error.  Prior to the error, with my 
PC locked into the GPS and the internet servers noselected, here's what 
my peerstats looked like.  Baseline is the GPS.  Colored lines are 
internet servers.

[]


My system is Windows 7, NTP 4.2.7p259, GPS GlobalSat BU-353 USB NMEA 
only with GPGGA sentence at 57,600 baud.


If anyone can shed some light on what happened, please do.  It's driving 
me bonkers.  I don't believe the GPS is at fault, and I suspect NTPD.


Thanks in advance.

Sincerely,

Ron


As all the Internet servers agreed (in another graph you showed me), I 
would suggest that you stick with the Internet servers and discard that 
GPS!  I hope it will be better with the PPS from the Sure board.  At least 
remove the noselect from the Internet servers so that NTP can do its job 
properly.  At the moment you are telling NTP to trust the GPS no matter 
what it says.  Can't think that sounds the wisest option.  I might be 
inclined to add noselect to the GPS and measure it against the Internet 
servers.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread Chris Albertson

On Tue, Mar 13, 2012 at 9:52 AM, Ron Frazier (NTP)
timekeepingntpl...@c3energy.com wrote:
 Hi all,

 I just woke up to a 50 SECOND clock error.  Prior to the error, with my PC
 locked into the GPS and the internet servers noselected, here's what my
 peerstats looked like.  Baseline is the GPS.  Colored lines are internet
 servers.

 http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Looks to me like that GPS, maybe lock lock and was able to coast on
hold over for a while then fell off a cliff. If you have a log of
satellite  signal to noise ratios you might be able to figure out why.

The internet servers appear to be 100% reliable seeing as they all agree.

These kinds of things are why some hobbysts end up buying multiple GPS
(different brands)  Otherwise it is hard to sort out a GPS firmware
bug from a solar storm or just that there were not sats visable to
your indoor antenna for a few minutes

I think your goal is to learn about all of this so these problems are
a good thing.  No one learns much from working systems.   But if the
goal is a reliable NTP server, the pool NTP servers can't be beat
except by a good timing mode GPS, that has good self diagnostics and
PPS.  The self diagnostics part is important
-- 

Chris Albertson
Redondo Beach, California
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread David J Taylor



Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f5f9233.1080...@c3energy.com...

[]
The question is, what reset my clock abruptly 50 seconds off at around 
0637 UTC.


I would suspect your GPS.

My loopstats file shows that the GPS was humming along quite nicely at 
that point with no anomalies at all.  I don't believe it's the cause of 
the problem.  It looks like NTPD abruptly decided to step my clock 50 
seconds, for reasons unknown.  As far as I know, NTPD is the only thing 
active on the system that will alter the clock.  The Windows internet 
time function is disabled.  The noselects are there for testing only.  I 
won't keep them there permanently.  I'm trying to determine where these 
anomalous readings are coming from.


Sincerely,

Ron


Yes, I appreciate you are testing, but I think you are testing the wrong 
way round (in view of the results).  Lock your PC as best you can to the 
Internet servers, and watch the GPS with noselect against it.


Cheers,
David 


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

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

Ron Frazier (NTP) wrote:
 I put the following in ntp.conf to allow the clock to coast in local
 mode if the GPS goes insane.
 # Allow system to coast on local clock if GPS is insane
 server 127.127.1.1 minpoll 3 maxpoll 6  # LCL, local clock
 fudge  127.127.1.1 stratum 12   # increase stratum

I can't see how that will make any difference
 if the GPS is still selected,
 as your meinberg billboard seemed to indicate.
http://dl.dropbox.com/u/9879631/drifting02a%20-%20insane.jpg

... and you would likely be better off using orphan than local clock,
 (not that it would make any diff if the GPS was still selected).



-- 
E-Mail Sent to this address blackl...@anitech-systems.com
  will be added to the BlackLists.

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/13/2012 4:27 PM, David J Taylor wrote:


Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote in message 
news:4f5f9233.1080...@c3energy.com...

[]
The question is, what reset my clock abruptly 50 seconds off at 
around 0637 UTC.


I would suspect your GPS.

My loopstats file shows that the GPS was humming along quite nicely 
at that point with no anomalies at all.  I don't believe it's the 
cause of the problem.  It looks like NTPD abruptly decided to step my 
clock 50 seconds, for reasons unknown.  As far as I know, NTPD is the 
only thing active on the system that will alter the clock.  The 
Windows internet time function is disabled.  The noselects are there 
for testing only.  I won't keep them there permanently.  I'm trying 
to determine where these anomalous readings are coming from.


Sincerely,

Ron


Yes, I appreciate you are testing, but I think you are testing the 
wrong way round (in view of the results).  Lock your PC as best you 
can to the Internet servers, and watch the GPS with noselect against 
it.


Cheers,
David


Hi David,

OK, you've convinced me.  I've put noselect on the GPS and taken it away 
on the New York NIST server.  The NY NIST server is now preferred and 
polling from 1 - 4 minutes.  Hopefully they won't ban me for hitting it 
too often.  I think the NIST server will have more jitter, particularly 
as the polling interval increases, but we'll see what happens.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread David Lord


Ron Frazier (NTP) wrote:

On 3/13/2012 2:40 PM, Chris Albertson wrote:

On Tue, Mar 13, 2012 at 9:52 AM, Ron Frazier (NTP)
timekeepingntpl...@c3energy.com  wrote:
  

Hi all,

I just woke up to a 50 SECOND clock error.  Prior to the error, with 
my PC

locked into the GPS and the internet servers noselected, here's what my
peerstats looked like.  Baseline is the GPS.  Colored lines are internet
servers.

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg
 

Looks to me like that GPS, maybe lock lock and was able to coast on
hold over for a while then fell off a cliff. If you have a log of
satellite  signal to noise ratios you might be able to figure out why.

The internet servers appear to be 100% reliable seeing as they all agree.

These kinds of things are why some hobbysts end up buying multiple GPS
(different brands)  Otherwise it is hard to sort out a GPS firmware
bug from a solar storm or just that there were not sats visable to
your indoor antenna for a few minutes

I think your goal is to learn about all of this so these problems are
a good thing.  No one learns much from working systems.   But if the
goal is a reliable NTP server, the pool NTP servers can't be beat
except by a good timing mode GPS, that has good self diagnostics and
PPS.  The self diagnostics part is important
   


The link you quoted just now is not the one that bugs me so much today.  
This one is the one that bugs me today, where my clock was stepped by 50 
seconds for some reason.


http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg


I'm on a text mostly system so why do you require me to use
a web browser to help you?

What is your current ntp.conf, ntpd version, operating system
and response of ntpq -crv -p after ntpd has had at least
a day to stabilise?

Not so long ago you posted that you had an offset within
+/- 6 ms but didn't give any evidence. Response from
ntpq -crv -p or better a day from peer_summary or couple
of days from loop_summary would be enough.


David


When I get the Sure board, I plan to hang it on the pc in tandem with 
this GPS and compare.


Sincerely,

Ron




___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

On 3/13/2012 5:01 PM, E-Mail Sent to this address will be added to the 
BlackLists wrote:

Ron Frazier (NTP) wrote:
   

I put the following in ntp.conf to allow the clock to coast in local
mode if the GPS goes insane.
# Allow system to coast on local clock if GPS is insane
server 127.127.1.1 minpoll 3 maxpoll 6  # LCL, local clock
fudge  127.127.1.1 stratum 12   # increase stratum
 

I can't see how that will make any difference
  if the GPS is still selected,
  as your meinberg billboard seemed to indicate.
http://dl.dropbox.com/u/9879631/drifting02a%20-%20insane.jpg

... and you would likely be better off using orphan than local clock,
  (not that it would make any diff if the GPS was still selected).

   


At that time, I had the GPS as the only selectable clock, for testing.  
I'm monitoring the internet servers for comparison.  I've since selected 
1 NIST server as the preferred and only selectable clock, and am 
monitoring the GPS and other internet clocks for comparison.


My thinking was simply that if all the available clocks vanished 
(internet down), or the GPS went insane, I just want the system to coast 
on its internal clock until a viable clock source returns.  I figure it 
may gain or lose up to 10 ms / minute this way, but at least it 
shouldn't do anything radical like jumping 50 seconds.


I looked at the docs page for the orphan command for a few minutes and 
my eyes just glazed over.  I decided to try the local clock option 
instead for now.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/13/2012 5:39 PM, David Lord wrote:

Ron Frazier (NTP) wrote:

On 3/13/2012 2:40 PM, Chris Albertson wrote:

On Tue, Mar 13, 2012 at 9:52 AM, Ron Frazier (NTP)
timekeepingntpl...@c3energy.com  wrote:

Hi all,

I just woke up to a 50 SECOND clock error.  Prior to the error, 
with my PC
locked into the GPS and the internet servers noselected, here's 
what my
peerstats looked like.  Baseline is the GPS.  Colored lines are 
internet

servers.

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Looks to me like that GPS, maybe lock lock and was able to coast on
hold over for a while then fell off a cliff. If you have a log of
satellite  signal to noise ratios you might be able to figure out why.

The internet servers appear to be 100% reliable seeing as they all 
agree.


These kinds of things are why some hobbysts end up buying multiple GPS
(different brands)  Otherwise it is hard to sort out a GPS firmware
bug from a solar storm or just that there were not sats visable to
your indoor antenna for a few minutes

I think your goal is to learn about all of this so these problems are
a good thing.  No one learns much from working systems.   But if the
goal is a reliable NTP server, the pool NTP servers can't be beat
except by a good timing mode GPS, that has good self diagnostics and
PPS.  The self diagnostics part is important


The link you quoted just now is not the one that bugs me so much 
today.  This one is the one that bugs me today, where my clock was 
stepped by 50 seconds for some reason.


http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg


I'm on a text mostly system so why do you require me to use
a web browser to help you?

What is your current ntp.conf, ntpd version, operating system
and response of ntpq -crv -p after ntpd has had at least
a day to stabilise?

Not so long ago you posted that you had an offset within
+/- 6 ms but didn't give any evidence. Response from
ntpq -crv -p or better a day from peer_summary or couple
of days from loop_summary would be enough.


David


When I get the Sure board, I plan to hang it on the pc in tandem with 
this GPS and compare.


Sincerely,

Ron




Hi David L.,

I just figured the images and dropbox would be the fastest way to 
distribute the information.  I didn't think I could attach files to 
messages going to the NTP questions mailing list.


I'll be glad to provide stats files if anyone is interested.  Just tell 
me how to distribute them.


Based on advice from David Taylor, I just changed my configuration.  
Previously, I had only the GPS selectable and the internet servers 
noselected for testing purposes to try to determine where a slow 
drifting behavior is coming from.  Now, I have changed that so the GPS 
is noselected and the New York NIST server is the preferred and only 
selectable peer.  I am monitoring the GPS and other internet servers for 
comparison.  So, it will be a couple of days before this configuration 
accumulates some stats files.


Even though I have been tinkering with this GPS for a couple of months, 
I have never seen anything like the 50 second jump I started this thread 
about.  That problem may not be reproducible for some time, if at all.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread Chuck Swiger

On Mar 13, 2012, at 3:19 PM, Ron Frazier (NTP) wrote:
 At that time, I had the GPS as the only selectable clock, for testing.  I'm 
 monitoring the internet servers for comparison.  I've since selected 1 NIST 
 server as the preferred and only selectable clock, and am monitoring the GPS 
 and other internet clocks for comparison.

ntpd is probably better able to judge which timeserver to use then forcing the 
choice via prefer, as it continues to evaluate the servers available to it and 
will use another one if the chosen peer happens to become unreachable.

 My thinking was simply that if all the available clocks vanished (internet 
 down), or the GPS went insane, I just want the system to coast on its 
 internal clock until a viable clock source returns.  I figure it may gain or 
 lose up to 10 ms / minute this way, but at least it shouldn't do anything 
 radical like jumping 50 seconds.

If you let ntpd run long enough to estimate the intrinsic drift, it will 
continue to adjust the clock even without external timesources. However, if 
your system clock really is off by a rate of 1:600 or worse, it's broken and 
ntpd probably wouldn't be able to fix it, at least without tinkering the max 
allowable slew rate-- running ntpdate via cron might do.

 I looked at the docs page for the orphan command for a few minutes and my 
 eyes just glazed over.  I decided to try the local clock option instead for 
 now.

Why would you want to use the local clock option?  It's rarely the right 
solution, barring unusual circumstances...

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/13/2012 6:42 PM, Chuck Swiger wrote:

On Mar 13, 2012, at 3:19 PM, Ron Frazier (NTP) wrote:
   

At that time, I had the GPS as the only selectable clock, for testing.  I'm 
monitoring the internet servers for comparison.  I've since selected 1 NIST 
server as the preferred and only selectable clock, and am monitoring the GPS 
and other internet clocks for comparison.
 

ntpd is probably better able to judge which timeserver to use then forcing the 
choice via prefer, as it continues to evaluate the servers available to it and 
will use another one if the chosen peer happens to become unreachable.

   

My thinking was simply that if all the available clocks vanished (internet 
down), or the GPS went insane, I just want the system to coast on its internal 
clock until a viable clock source returns.  I figure it may gain or lose up to 
10 ms / minute this way, but at least it shouldn't do anything radical like 
jumping 50 seconds.
 

If you let ntpd run long enough to estimate the intrinsic drift, it will 
continue to adjust the clock even without external timesources. However, if 
your system clock really is off by a rate of 1:600 or worse, it's broken and 
ntpd probably wouldn't be able to fix it, at least without tinkering the max 
allowable slew rate-- running ntpdate via cron might do.

   

I looked at the docs page for the orphan command for a few minutes and my 
eyes just glazed over.  I decided to try the local clock option instead for now.
 

Why would you want to use the local clock option?  It's rarely the right 
solution, barring unusual circumstances...

Regards,
   


I was speculating that perhaps my only selectable clock, the GPS, 
failed, and that something went nuts, and that's why I found the clock 
50 seconds off this morning.  However, I don't have any evidence of a 
GPS failure.  In any case, I just figured the local option might prevent 
any major clock changes if all other sources are not available.  I only 
wanted the local option to kick in if there were no other sources.  I 
did not have that option in the ntp.conf file when I started this 
thread.  When I started this thread, my GPS was the only selectable 
clock, and there was no local option.


For now, I'm mainly wanting to compare the GPS to one primary other 
source because I've been experiencing a slow drift in NMEA time with a 
variation of about 120 ms and an oscillation period of several days.  
I'm trying to isolate the source, either the GPS, or the subsystem 
that's getting time from the internet servers.  I'm assuming all the 
internet servers are not drifting, but my instrumentation, ie the 
Meinberg time server monitor, or whatever drives it, could be off.  
That's why only have one source selectable, either the GPS, or one NIST 
server.


Sincerely,

Ron



--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread Chuck Swiger

On Mar 13, 2012, at 4:08 PM, Ron Frazier (NTP) wrote:
 I was speculating that perhaps my only selectable clock, the GPS, failed, and 
 that something went nuts, and that's why I found the clock 50 seconds off 
 this morning.  However, I don't have any evidence of a GPS failure.  In any 
 case, I just figured the local option might prevent any major clock changes 
 if all other sources are not available.  I only wanted the local option to 
 kick in if there were no other sources.  I did not have that option in the 
 ntp.conf file when I started this thread.  When I started this thread, my GPS 
 was the only selectable clock, and there was no local option.

One problem is that the local clock will always claim to be perfectly sync'ed, 
regardless of how close or far from real time it actually happens to be.  The 
fact that ntpd's stats will look wonderful doesn't mean anything in this case.

If you configured a reasonable # of internet NTP servers, and maybe your GPS in 
noselect mode while you try to debug whatever the issue is with it, you'd 
likely avoid a number of the issues you've been reporting.

 For now, I'm mainly wanting to compare the GPS to one primary other source 
 because I've been experiencing a slow drift in NMEA time with a variation of 
 about 120 ms and an oscillation period of several days.  I'm trying to 
 isolate the source, either the GPS, or the subsystem that's getting time from 
 the internet servers.  I'm assuming all the internet servers are not 
 drifting, but my instrumentation, ie the Meinberg time server monitor, or 
 whatever drives it, could be off.  That's why only have one source 
 selectable, either the GPS, or one NIST server.

Well, it's hardly unexpected that the NMEA sentences would show variable 
timing; they are only supposed to be correct to the nearest second, so 120 ms 
is well within specs.  It's the PPS signal which is expected to provide 
sub-millisecond precision.

[ Hasn't this already been discussed? ]

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/13/2012 7:24 PM, Chuck Swiger wrote:

On Mar 13, 2012, at 4:08 PM, Ron Frazier (NTP) wrote:
   

I was speculating that perhaps my only selectable clock, the GPS, failed, and 
that something went nuts, and that's why I found the clock 50 seconds off this 
morning.  However, I don't have any evidence of a GPS failure.  In any case, I 
just figured the local option might prevent any major clock changes if all 
other sources are not available.  I only wanted the local option to kick in if 
there were no other sources.  I did not have that option in the ntp.conf file 
when I started this thread.  When I started this thread, my GPS was the only 
selectable clock, and there was no local option.
 

One problem is that the local clock will always claim to be perfectly sync'ed, regardless 
of how close or far from real time it actually happens to be.  The fact that 
ntpd's stats will look wonderful doesn't mean anything in this case.

If you configured a reasonable # of internet NTP servers, and maybe your GPS in 
noselect mode while you try to debug whatever the issue is with it, you'd 
likely avoid a number of the issues you've been reporting.

   

For now, I'm mainly wanting to compare the GPS to one primary other source 
because I've been experiencing a slow drift in NMEA time with a variation of 
about 120 ms and an oscillation period of several days.  I'm trying to isolate 
the source, either the GPS, or the subsystem that's getting time from the 
internet servers.  I'm assuming all the internet servers are not drifting, but 
my instrumentation, ie the Meinberg time server monitor, or whatever drives it, 
could be off.  That's why only have one source selectable, either the GPS, or 
one NIST server.
 

Well, it's hardly unexpected that the NMEA sentences would show variable 
timing; they are only supposed to be correct to the nearest second, so 120 ms 
is well within specs.  It's the PPS signal which is expected to provide 
sub-millisecond precision.

[ Hasn't this already been discussed? ]

Regards,
   


I don't have PPS on this computer.  It has no serial port.  When I get 
my Sure board, assuming I can solder it without killing it, I'm going to 
try bringing the PPS signal through a Prolific chipset based serial - 
USB converter which is supposed to pass handshaking signals.  I don't 
know if that will work.


Of course, this thread was started because of a mysterious 50 second 
jump in my system clock.  That's still a mystery.


Regarding the NMEA though.  If I can get those data sentences to my PC 
with a jitter of 3 ms through USB, which I can, I don't see why the 
start and end time of the sentence should vary by 120 ms over 2-4 days.  
I'm trying to figure out where that variance is coming from.  If I can 
consistently keep time with this device, or some other USB device, to 
within + / - 6 ms or even 10 ms of true time, that's plenty good 
enough for my purposes.  If I can only keep time to within + / - 70 ms, 
then the device is more or less worthless, no better than the internet 
servers.  So, I'm trying to figure out whether it's good enough, or 
worthless.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread Chuck Swiger

On Mar 13, 2012, at 5:05 PM, Ron Frazier (NTP) wrote:
 I don't have PPS on this computer.  It has no serial port.  When I get my 
 Sure board, assuming I can solder it without killing it, I'm going to try 
 bringing the PPS signal through a Prolific chipset based serial - USB 
 converter which is supposed to pass handshaking signals.  I don't know if 
 that will work.

You should be able to get reasonable time via USB, but not of the quality that 
a serial or parallel connection would provide, especially one where the ISR 
does timestamping.

 Of course, this thread was started because of a mysterious 50 second jump in 
 my system clock.  That's still a mystery.

Yes.  I've seen that sort of thing with VMs; some older Linux kernels also had 
some fairly bad timekeeping issues.

 Regarding the NMEA though.  If I can get those data sentences to my PC with a 
 jitter of 3 ms through USB, which I can, I don't see why the start and end 
 time of the sentence should vary by 120 ms over 2-4 days.  I'm trying to 
 figure out where that variance is coming from.  If I can consistently keep 
 time with this device, or some other USB device, to within + / - 6 ms or even 
 10 ms of true time, that's plenty good enough for my purposes.  If I can 
 only keep time to within + / - 70 ms, then the device is more or less 
 worthless, no better than the internet servers.  So, I'm trying to figure out 
 whether it's good enough, or worthless.

You shouldn't have too much difficulty getting timekeeping accuracy to within 
~6 ms using public internet NTP servers which are nearby, although if you just 
use the global ntp pool and get some servers which are not very close, that 
might be on the order of +/- ~20 ms instead.

Regards,
-- 
-Chuck

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.

2012-03-13 Thread unruh

On 2012-03-13, Ron Frazier (NTP) timekeepingntpl...@c3energy.com wrote:
Hi all,

Did you shut down and restart your computer? Did you perchance do this
during the daylight savings time transition on a Windows system? Could
the error be related to the fact that Windows like time on localtime not
UTC?

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

Here is what was showing on the Meinberg Time Server Monitor when I woke up:

http://dl.dropbox.com/u/9879631/drifting02a%20-%20insane.jpg

And the graph of the peerstats for that time:

http://dl.dropbox.com/u/9879631/drifting02b%20-%20peerstats%20insane.jpg

The clock error was REAL, as confirmed by my atomic wrist watch.

However, the loopstats graph for the same time period shows no problem
with the GPS:

http://dl.dropbox.com/u/9879631/drifting02c%20-%20gps%20NOT%20insane.jpg

So, I shut down NTPD and reset the time with a batch file that calls
ntpdate and querys the New York NIST server:

http://dl.dropbox.com/u/9879631/drifting02d%20-%20set%20with%20ntpdate.jpg

Here is the time server monitor shortly after NTPD restart:

http://dl.dropbox.com/u/9879631/drifting02e%20-%20shortly%20after%20ntpd%20restart.jpg

And after a 2nd restart:

http://dl.dropbox.com/u/9879631/drifting02f%20-%202nd%20ntpd%20restart%20after%20insane.jpg

And here are the current peerstats, which look normal. The offset to
the internet servers tends to drift and will eventually cross the zero
line and get positive.

http://dl.dropbox.com/u/9879631/drifting02g%20-%20peerstats%20after%20insane%20and%202nd%20reset.jpg

The GPS appears to have been stable all through this, and was never
powered off or unplugged. It looks like NTPD went crazy and reset my
clock for some reason.

Here are the peerstats and loopstats during the insane period.

http://dl.dropbox.com/u/9879631/loopstats.20120313-1-restart%20around%201350%20utc
http://dl.dropbox.com/u/9879631/peerstats.20120313-1-insane

Here is my current ntp.conf:

http://dl.dropbox.com/u/9879631/ntp.conf

My system is Windows 7, NTP 4.2.7p259, GPS GlobalSat BU-353 USB NMEA
only with GPGGA sentence at 57,600 baud.

If anyone can shed some light on what happened, please do. It's driving
me bonkers. I don't believe the GPS is at fault, and I suspect NTPD.

Thanks in advance.

Sincerely,

Ron

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.


On 3/13/2012 10:05 PM, unruh wrote:

On 2012-03-13, Ron Frazier (NTP)timekeepingntpl...@c3energy.com  wrote:
   

Hi all,

I just woke up to a 50 SECOND clock error.  Prior to the error, with my
PC locked into the GPS and the internet servers noselected, here's what
my peerstats looked like.  Baseline is the GPS.  Colored lines are
internet servers.
 

Did you shut down and restart your computer? Did you perchance do this
during the daylight savings time transition on a Windows system? Could
the error be related to the fact that Windows like time on localtime not
UTC?

   


Good question, but no.  The change to DST occurred early Sunday 
morning.  This event occurred early Monday morning and I noticed it 
today, Tuesday morning.  By that time, the system was already well 
stabilized on DST.


Sincerely,

Ron


--

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ARRGH!!! I woke up to a 50 SECOND clock error.