perfSONAR User Q&A and Other Discussion

[John Mann <>]

Hi,

[ CC: list trimmed ]

If memory serves me ... ntp likes to sync to a group of servers that are giving about the same time.

If it can only see 1 source, it can't decide whether that is a truetimer or an outlying falseticker.

https://tools.ietf.org/html/rfc5905#section-11.1

NMIN, CMIN ...

Suggestions:

- Wait.  Sometimes ntp comes good after 20 mins / several hours.

- Add another ntp "server" (that has sync'd time) to the setup

     - e.g. use a router

- "peer" the ntp clients together so that they can have confidence in each other and the primary source

It is a bit of a black art.

You might end up with a ntp cloud that regains sync if you reboot one node, but if you reboot everything all at once it won't re-sync.

Thanks,

    John

On 1 April 2014 07:49, Bruce A. Mah <> wrote:

If memory serves me right, Amit Kumar wrote:
> Yes Aaron

If I'm reading the ntpq -p output correctly...

>>>      remote           refid      st t when poll reach   delay   offset
>>> jitter
>>> ============================================================================
>>> ==
>>> 10.255.255.3    10.255.255.35    2 u  519 1024  352    1.396   -4.134
>>> 12.624
>>> chronos.es.net  .INIT.          16 u    - 1024    0    0.000    0.000
>>> 0.000
>>> nms-rlat.chic.n .INIT.          16 u    - 1024    0    0.000    0.000
>>> 0.000
>>> nms-rlat.hous.n .INIT.          16 u    - 1024    0    0.000    0.000
>>> 0.000
>>> nms-rlat.losa.n .INIT.          16 u    - 1024    0    0.000    0.000
>>> 0.000
>>> nms-rlat.newy32 .INIT.          16 u    - 1024    0    0.000    0.000
>>> 0.000
>>> saturn.es.net   .INIT.          16 u    - 1024    0    0.000    0.000
>>> 0.000

...it looks like the host in question isn't synched against 10.255.255.3
(or anything else for that matter) because there's no "*" in front of
that line...that indicates a host that is the current time source.

Bruce.