08-25-2016 12:05 PM
Thank you Martin.
I think I missed something you and other contributors said (and in the documentation). The tsclockserver command is fabric propragated, so if I configure LOCL or an NTP server IP address, it will be the same configuration on all switches in the fabric.
It is my mistake, I understand better your messages.
Thank you again.
I would like to clarify just a bit. If you use LOCL for the time server in ANY switch in the fabric, you will not keep in sync with the stratum offset(tick count update) of the NTP source ever. Drift will occur because the LOCL source for the system and OS clock is a function of the crystal clock source on the chassis which drives all the buses, and clocks the ASICs, and it is not altered by the NTP source. I will warn you, if you let the time drift too far from the statum 2, 3, or 4 source there may be cases where you will need to reset the date/time before using tsclockserver because the drift of the LOCL source clock becomes too great and cannot be caught up with the NTP source(this is typically not an issue with modern Linux based kernel).
Further, I provided an example with three sources. The algorithm that computes the drift in local time involves comparing the tick drift of more than one NTP server to provide the best correction. The math is not important, but it's best to use a min of 2 different NTP sources provided the OS uses both of them to qualify the metric for drift correction. I believe, but will not look up that Brocade's kernel does offer multiple time source tick corrections.
And that, is all I recall about LInux NTP as it affects the FOS product.
Best of luck.
08-25-2016 01:46 PM
08-25-2016 04:29 PM - edited 08-25-2016 04:30 PM
Well, when I say 'provided the OS uses both of them to qualify the metric for drift correction. I believe, but will not look up that Brocade's kernel does offer multiple time source tick corrections.' I mean I'm not going to look it up, and that provided the OS uses both to fix the drift, then someone comes along and lets me know I 'might' be wrong, I'm ok with that.
By default, ntpd runs in continuous mode where each of possibly several external servers is polled at intervals determined by an intricate state machine. The state machine measures the incidental roundtrip delay jitter and oscillator frequency wander and determines the best poll interval using a heuristic algorithm.
The minimum system configuration is a couple of lines in your ntp configuration file, typically /etc/ntp.conf. You will need a line or two or three like this:
server some.timeserver.com server othertime.server.org
Synchronizing with more than one NTP server gives you redundancy in case of server or network problems, and it may improve the accuracy of your time synchronization.
Does the ntpd in FOS perform the heuristic math to adjust for best drift correction? Only a FOS coder will know for sure. And I will absolutely, positively not be hacking into it to find out. Alternately, one could insert a packet analyzer into the active CP, and trigger on the DNS or IP for the NTP sources and see what we will see. I won't be doing this either! :womanwink:
08-26-2016 06:57 AM
Notice the writing the CLI manual tsclockserver
When multiple NTP server addresses are specified, tsClockServer sets the first reachable address for the active NTP server. The remaining addresses are stored as backup servers, which can take over if the active NTP server fails.
Which does not sound like ntpd. And I do not see any ntpd daemon currently on my FOS 741c switch in the process list.
When I looked into this in 2004 (FOS 4.x) and using tcpdump - a query was sent out to active ntp server every 64 seconds,
and FOS was updating the RTC, and then broadcasting the time to all switches in the fabric.
For a chassis with logical switches, only the ntp server configured on the default switch will update the RTC and drift (file) from tstimezone CLI
When Virtual Fabrics are enabled, the hardware clock is updated by the default switch in the chassis, and the time zone set on any logical switch applies to all logical switches on the chassis. The tsTimeZone command requires chassis permissions.
08-30-2016 05:08 AM
Thanks a lot for these really interesting details about NTP working, on GNU-Linux OS and Brocade FOS.
A lot of work last few days, but I read closely your messages.
09-09-2016 06:19 AM
For completness, I addthe folowing notice - based on observation and from the FOS admin guide 7.4:
When Virtual Fabric is enabled - all chassis is in fact quering the ntp server as specified in the tsclockserver
• All switches in a given chassis must be configured for the same set of NTP servers. This ensures that
time does not go out of sync in the chassis. It is not recommended to configure LOCL in the NTP
• All default switches in the fabric can query the NTP server. If Virtual Fabrics is not enabled, only the
principal or primary FCS switch can query the NTP server.
• The logical switches in a chassis get their clock information from the default logical switch, and not
from the principal or primary FCS switch.