perfSONAR User Q&A and Other Discussion

["Bruce A. Mah" <>]

If memory serves me right, John Mann wrote:
> 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.

Well...if there's only one source, and it's valid, ntpd has to use that
one.  (One of the hazards of having only one or two time servers.)  I
would expect that perfSONAR host to (eventually) sync with that first
server.

Also it's not clear why he couldn't sync with the public timeservers.
Firewall rules / network ACLs maybe?

> https://tools.ietf.org/html/rfc5905#section-11.1
> NMIN, CMIN ...
> 
> Suggestions:
> - Wait.  Sometimes ntp comes good after 20 mins / several hours.

Yes, depending on how the local ntpd is configured.

> - Add another ntp "server" (that has sync'd time) to the setup
>      - e.g. use a router

I'm trying to resist the temptation to dive into NTP configuration
trivia, but having two servers isn't a whole lot better than one,
because if one of them misbehaves, the client can't tell which one to
trust.  My usual practice for generic (i.e. non-perfSONAR) hosts, which
mirrors what I understand to be best practice, is to pick either 3 or 5
servers, with the usual considerations for diversity.

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

Hrm, a bunch of clients that all peer with each other and get time from
a single server isn't really any better than just going to the single
server.  If that server loses sync or goes down, the client are all
going to lose sync too, eventually, unless some of them are configured
to use their local clocks as high-stratum NTP servers (I am not
recommending that step).

I'm pretty sure the original poster didn't want to set up a local NTP
infrastructure, he just wants to use what's available.

> It is a bit of a black art.

Oh it's not *that* bad.  I haven't had to sacrifice any goats for
several years now.  :-)

Bruce.

> 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 
> <
>  
> <mailto:>>
> 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 <http://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 <http://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.
> 
> 
>

Attachment: signature.asc
Description: OpenPGP digital signature