Re: [ntp:questions] PPS versus serial offset

[David Taylor]

On 28/08/2013 13:19, Steve Kostecke wrote:

On 2013-08-28, David Taylor  wrote:


detha  wrote:


http://detha.co.za/ntp/ntpmon.20130828.jpg


I would be more worried about the 11 ms step in the PPS at about -155
hours...


The PPS signal is plotted in green and does not diverge visibly from 0.

The blue line, which displays the 11ms jump, is labled "stratum 1". It
is very likely the system offset.


Yes, I meant "stratum-1".

Thanks to Detha for the explanation.
--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] Start of new GPS 1024 week epoch

[David Taylor]

On 28/08/2013 13:34, Rob wrote:
[]

No, I mean when compiling ntpd for Windows.  I think that requires Cygwin.


Not so, it compiles purely with the free MS Visual Studio Express (C++ 
branch).  It does need the OpenSSL source installed as well, but that 
also works with MS VS.  No Cygwin needed at all.

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] Start of new GPS 1024 week epoch

[Rob]

David Taylor  wrote:
> On 28/08/2013 13:34, Rob wrote:
> []
>> No, I mean when compiling ntpd for Windows.  I think that requires Cygwin.
>
> Not so, it compiles purely with the free MS Visual Studio Express (C++ 
> branch).  It does need the OpenSSL source installed as well, but that 
> also works with MS VS.  No Cygwin needed at all.

Sorry... mistake.  I mean when compiling *gpsd* for Windows.

Looking at the source, gpsd does not have special code for Windows SHM.
It could work, when it is compiled with Cygwin.

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

Re: [ntp:questions] Start of new GPS 1024 week epoch

[David Taylor]

On 29/08/2013 08:21, Rob wrote:
[]

Sorry... mistake.  I mean when compiling *gpsd* for Windows.

Looking at the source, gpsd does not have special code for Windows SHM.
It could work, when it is compiled with Cygwin.


Ah, OK, but I think gpsd for Windows would get a much better reception 
were it not to require Cygwin to run i.e, just like ntp, use only the 
standard Windows calls.

--
Cheers,
David
Web: http://www.satsignal.eu

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

Re: [ntp:questions] Start of new GPS 1024 week epoch

[John Hasler]

David Taylor writes:
> Ah, OK, but I think gpsd for Windows would get a much better reception
> were it not to require Cygwin to run i.e, just like ntp, use only the
> standard Windows calls.

From  : 
"No, we don't support Windows — get a better operating system."

esr is not a big Microsoft fan.
-- 
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] Start of new GPS 1024 week epoch

[unruh]

On 2013-08-29, John Hasler  wrote:
> David Taylor writes:
>> Ah, OK, but I think gpsd for Windows would get a much better reception
>> were it not to require Cygwin to run i.e, just like ntp, use only the
>> standard Windows calls.
>
> From  : 
> "No, we don't support Windows ??? get a better operating system."
>
> esr is not a big Microsoft fan.

Looks like someone else is going to have to do the port to windows.
Volunteers?

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

[ntp:questions] NTPD silently not tracking

[Magnus Danielson]

Hi,

We had another incident where a node configured with multiple NTP
sources had an NTPD which when asked with ntpdc have peers, looks like
things are all OK, but with offsets less than a second, while the node
in fact was 6 days off the mark. Only on a number of ntpdc querries did
some of the peers expose a gigantic offset. Everything looked OK, but
time was off such that normal remote login did not work.

The error was way to non-obvious and felt like a Heisenbug in that only
when we looked more carefully at it, it started to see itself that it
was out of touch with reality.

We have now designed a script that warns of an error:

cat /etc/cron.hourly/timechecker
#!/bin/bash
awk 'BEGIN {printf "ntpdate -q "} ; $1 == "server" {printf $2" "}; END {print 
""}' /etc/ntp.conf | bash | awk '$5 == "adjust" && ( $10 > 1.0 || $10 < -1.0 ) 
{print "WARNING: timechecker says that time of host is off by "$10" seconds"}'

However, this should be addressed in a much more direct manor by NTPD. Have you 
seen this before? Do you have a remedy?

ii  ntp1:4.2.6.p5+d i386 Network Time Protocol daemon and 

Cheers,
Magnus

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

Re: [ntp:questions] NTPD silently not tracking

[E-Mail Sent to this address will be added to the BlackLists]

Magnus Danielson wrote:
> We had another incident where a node configured with multiple NTP
> sources had an NTPD which when asked with ntpdc have peers, looks like
> things are all OK, but with offsets less than a second, while the node
> in fact was 6 days off the mark. Only on a number of ntpdc querries did
> some of the peers expose a gigantic offset. Everything looked OK, but
> time was off such that normal remote login did not work.
>
> The error was way to non-obvious and felt like a Heisenbug in that only
> when we looked more carefully at it, it started to see itself that it
> was out of touch with reality.
>
> ii  ntp   1:4.2.6.p5+d i386   Network Time Protocol daemon and

What ntpdc commands did you issue, and what results did you get?

Did you also try ntpq commands, did you see differing results?
ntpq -n -c "rv 0 leap"
ntpq -n -c "rv 0 stratum"
ntpq -n -c "rv 0 refid"
ntpq -n -c "rv 0 offset"
ntpq -n -c "rv 0 rootdisp"


Have you tried a newer version of NTP ?





Don't use Undisciplined Local Clock 27.127.1.0
 Try Orphan instead is you need LAN NTP clients to stick together
  while LAN and/or Internet NTP servers become unavailable.
 ...
 keys "/etc/ntp.keys" # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY , 
...
 trustedkey 123 321
 tos cohort 1 orphan 10
 restrict source nomodify
 manycastserver  224.0.1.1
 manycastclient  224.0.1.1 key 123 preempt
 ...


-- 
E-Mail Sent to this address 
  will be added to the BlackLists.

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

Re: [ntp:questions] NTPD silently not tracking

[Magnus Danielson]

On 08/30/2013 04:17 AM, E-Mail Sent to this address will be added to the
BlackLists wrote:
> Magnus Danielson wrote:
>> We had another incident where a node configured with multiple NTP
>> sources had an NTPD which when asked with ntpdc have peers, looks like
>> things are all OK, but with offsets less than a second, while the node
>> in fact was 6 days off the mark. Only on a number of ntpdc querries did
>> some of the peers expose a gigantic offset. Everything looked OK, but
>> time was off such that normal remote login did not work.
>>
>> The error was way to non-obvious and felt like a Heisenbug in that only
>> when we looked more carefully at it, it started to see itself that it
>> was out of touch with reality.
>>
>> ii  ntp   1:4.2.6.p5+d i386   Network Time Protocol daemon and
> What ntpdc commands did you issue, and what results did you get?
>
> Did you also try ntpq commands, did you see differing results?
> ntpq -n -c "rv 0 leap"
> ntpq -n -c "rv 0 stratum"
> ntpq -n -c "rv 0 refid"
> ntpq -n -c "rv 0 offset"
> ntpq -n -c "rv 0 rootdisp"
Unfortunatly no. I got the call after the fact, but lack of remote login
due to time error would prohibit  me from doing anything anyway. The
server needed to be operational rather than optimize for NTP debugging.
> Have you tried a newer version of NTP ?
> 
> 
> 
No, I listed the affected version as packaged by Debian.
> Don't use Undisciplined Local Clock 27.127.1.0
>  Try Orphan instead is you need LAN NTP clients to stick together
>   while LAN and/or Internet NTP servers become unavailable.
>  ...
>  keys "/etc/ntp.keys" # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY 
> , ...
>  trustedkey 123 321
>  tos cohort 1 orphan 10
>  restrict source nomodify
>  manycastserver  224.0.1.1
>  manycastclient  224.0.1.1 key 123 preempt
>  ...
>
>
It has 2 stratum 1 and 3 stratum 2 unicast servers configured. NTP wise
this machine is a client with 5 configured servers. The problem was that
it was way off time with no apparent indication, which is wrong.

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