Re: [ntp:questions] How common is LI=3 - solved.

[Robert Scott]

On Fri, 03 Feb 2017 03:15:09 GMT, no-one@notreal.invalid (Robert
Scott) wrote:

>I am writing some parsing code for reading Time Server packets.  The
>first 32 bits of the returned packet are:
>
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|LI | VN  |Mode |Stratum| Poll  |   Precision|   
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
>
>When the two LI bits come back as 11 (clocks not synchronized) I have
>been treating that as a fatal error for that server.  I ignore that
>packet and do not attempt to retry my query for that server.  However
>I have found that LI=11 is not all that uncommon for servers from the
>pool.  Is my response to LI=11 the correct one?  Should I discard the
>response and should I write off that server for retries?  So far, the
>only reason I might retry a server is if my recvfrom() socket call
>times out.
>
>-Robert Scott
> Hopkins, MN
>

I think I found a bug in my software that was causing this.  I was
fetching four IP addresses from pool.ntp.org just fine, but I was
mistakenly always accessing just the first one of those IP addresses
when I thought I was looping through all four.  The result is I was
trying to hit the same server four times in quick succession.  With
some servers this worked fine.  But with other servers, the first
response came back good, the second response came back LI=3, the third
and fourth responses never came back at all.  (recvfrom() has to be
aborted).

Is this possibly a defense mechanism against a DOS attack?  In any
case I only did it a few times before I found my error.  A big clue
was that the responses from all four hosts had the same stratum.
Sometimes 2, sometimes 3.  Now I get a mixture of strata in the four
hosts so I know I am quering each host only once.

-Robert Scott
 Hopkins, MN

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

Re: [ntp:questions] How common is LI=3 (clocks not synchronized)?

[Majdi S. Abbas]

On Fri, Feb 03, 2017 at 09:09:51AM -, William Unruh wrote:
> Those pool sources you probably would want to blackball.

No.  The leap alarm is normally declared when a server
has just been restarted, and is not yet synchronized; I'd give
it some time to settle down and then retry (say, wait 1024s.)

I wouldn't disqualify the server outright; just because
it's not stable at the time of the poll doesn't mean it won't
be so later.

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

Re: [ntp:questions] Time syncing with something other than ntpd

[Jakob Bohm]

On 01/02/2017 12:56, David Taylor wrote:

On 01/02/2017 10:59, Jakob Bohm wrote:
[]

As I am looking at the BBB myself, here are some extra questions:

1. Do you know if anyone has tried using the real-time coprocessors on
  the BBB to more accurately track the PPS signal?

2. I presume the BBB could be put in a shielded case (I see some
  offered online).  Any experience with that?

Enjoy
Jakob


Jakob,

(1) No.  Do you mean using the counters to record the timing of the PPS
more precisely?



No, I was thinking about the two "PRU" 200MHz low latency I/O
controllers on the chip, one of those could be made to run its own
little timing PLL loop directly watching the PPS GPIO pin, then
allowing the ARM CPU (running NTPD) to check the high resolution delta
between its own (NTP/Linux) time and the PPS synced loop.



(2) No, but without the BBB radiates more interference than the RPi.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: [ntp:questions] Time syncing with something other than ntpd

[David Taylor]

On 03/02/2017 07:42, sean wrote:
[]

Just curious, any experience with those?

[]

I'm running a couple of Sure boards here one feeding one PC and the 
other feeding two PCs in parallel (only one PC has TX connected).  No 
problems.  I'm on the top storey of a two storey building, and both 
devices are using indoor puck antennas.

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

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

Re: [ntp:questions] Time syncing with something other than ntpd

[William Unruh]

On 2017-02-03, sean  wrote:
> On 2017-02-02, William Unruh  wrote:

 Another low-cost device is the Sure evaluation board:

http://www.satsignal.eu/ntp/Sure-GPS.htm

  
 http://www.ebay.com/itm/SKG16A-Bluetooth-RS232-USB-UART-GPS-Module-Demo-Board-/230844194302

>>>
>>> Thanks for the link! That's about half the price of the garmin and would
>>> likely get me better precision than just syncing to the NTP pool.
>>
>> Yes.
>>>
>
> Just curious, any experience with those?

Sure:-) Loads of it. I have used a couple for the past 4 years. Work
well. Needs a little bit of work to get out the PPS signal (soldering a
wire between a couple of points on the board). The GPS18 (both samples I
had) I found would
die after a few years. No idea why. Have not had that problem with the
Sure boards, except one antenna was flakey and then died after a few
months. No support from Sure-Electronics for that, so it seems it is a
WYSIWYG. (Mind you a new antenna was just a copule of bucks, and a
month wait. The free shipping is paid for in shipping time).


>
 Windows uses NTP but not with the reference implementation, so of 
 unknown quality, and not manageable in the same way.  It used to be 
 lousy, and I've not tested since then.

>>>
>>> I think I'll install the ntp client on my windows machine and see what
>>> kind of time I can get.
>>
>> You would probably be better off syncing a linux machine to the gps
>> board and then syncing the windows machine to that over the local Lan.
>>
>>
>
> Yes, but if the windows machine isn't at home, it won't sync. Allowing
> remote access will come later. :)

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

Re: [ntp:questions] How common is LI=3 (clocks not synchronized)?

[William Unruh]

On 2017-02-03, Miroslav Lichvar  wrote:
> On 2017-02-03, Jakob Bohm  wrote:
>> On 03/02/2017 04:15, Robert Scott wrote:
>>> When the two LI bits come back as 11 (clocks not synchronized) I have
>>> been treating that as a fatal error for that server.  I ignore that
>>> packet and do not attempt to retry my query for that server.  However
>>> I have found that LI=11 is not all that uncommon for servers from the
>>> pool.  Is my response to LI=11 the correct one?  Should I discard the
>>> response and should I write off that server for retries?  So far, the
>>> only reason I might retry a server is if my recvfrom() socket call
>>> times out.
>>>
>>
>> I suspect this is the expected response from a time server which has
>> recently booted and has not yet synchronized itself, probably combined
>> with stratum=15 or more.  But I haven't double checked this against
>> code or RFCs.
>
> Another reason for the "unsynchronized" leap bits might be a recent step
> of the system clock. If the clock is unstable, ntpd may need to step the
> clock often (after reaching the threshold of 128ms). I think I've
> seen some servers in the pool that behaved like that.

Those pool sources you probably would want to blackball.
>

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

Re: [ntp:questions] How common is LI=3 (clocks not synchronized)?

[Miroslav Lichvar]

On 2017-02-03, Jakob Bohm  wrote:
> On 03/02/2017 04:15, Robert Scott wrote:
>> When the two LI bits come back as 11 (clocks not synchronized) I have
>> been treating that as a fatal error for that server.  I ignore that
>> packet and do not attempt to retry my query for that server.  However
>> I have found that LI=11 is not all that uncommon for servers from the
>> pool.  Is my response to LI=11 the correct one?  Should I discard the
>> response and should I write off that server for retries?  So far, the
>> only reason I might retry a server is if my recvfrom() socket call
>> times out.
>>
>
> I suspect this is the expected response from a time server which has
> recently booted and has not yet synchronized itself, probably combined
> with stratum=15 or more.  But I haven't double checked this against
> code or RFCs.

Another reason for the "unsynchronized" leap bits might be a recent step
of the system clock. If the clock is unstable, ntpd may need to step the
clock often (after reaching the threshold of 128ms). I think I've
seen some servers in the pool that behaved like that.

-- 
Miroslav Lichvar

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

Re: [ntp:questions] Time syncing with something other than ntpd

[sean]

On 2017-02-02, William Unruh  wrote:
>>>
>>> Another low-cost device is the Sure evaluation board:
>>>
>>>http://www.satsignal.eu/ntp/Sure-GPS.htm
>>>
>>>  
>>> http://www.ebay.com/itm/SKG16A-Bluetooth-RS232-USB-UART-GPS-Module-Demo-Board-/230844194302
>>>
>>
>> Thanks for the link! That's about half the price of the garmin and would
>> likely get me better precision than just syncing to the NTP pool.
>
> Yes.
>>

Just curious, any experience with those?

>>> Windows uses NTP but not with the reference implementation, so of 
>>> unknown quality, and not manageable in the same way.  It used to be 
>>> lousy, and I've not tested since then.
>>>
>>
>> I think I'll install the ntp client on my windows machine and see what
>> kind of time I can get.
>
> You would probably be better off syncing a linux machine to the gps
> board and then syncing the windows machine to that over the local Lan.
>
>

Yes, but if the windows machine isn't at home, it won't sync. Allowing
remote access will come later. :)

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