Home

Documentation

Project Support

Changes in Version 3 of GraspExtrasSoftwareControllerNTP

Author:
crae
Timestamp:
Thu Oct 11 15:35:54 2012

Legend:

Unmodified
Added
Removed
Modified
  • GraspExtrasSoftwareControllerNTP

    v2 v3
    1 1  '''[wiki:GraspExtrasSoftware STARGRASP NTP client]''' 
    2 2  [[TracNav(GraspExtrasContents)]] 
    3 3  As of SVN revision 4427 of the stage 2 software, the STARGRASP controller has included experimental support for synchronising with an NTP server to provide timing for various events. The client can be started via the '''[wiki:GraspSwControllerCmdNtp ntp]''' command. 
    4 4  == Startup Performance == 
    5 5  When first started, the NTP client first sets the system time from the first NTP transaction in a single step. Since it cannot make any assumptions about the system's clock drift, it initially starts with a drift correction of zero and attempts to figure out the drift from first principles over successive updates. The result is an initial overshoot that's typically on the order of a couple of milliseconds (the vertical scale below is in usec): 
    6 6  [[Image(stargrasp_ntp_startup.png)]] 
    7 7  After a couple of minutes, the NTP client typically settles to an NTP offset in the region of 100-200 usec, barring perturbations from the NTP server. 
    8 8  == Stargrasp Client: Observed Stability == 
    9 9  Show time offset when connected to NTP server via 100Mbit and Gigabit, long-term stability, etc. 
    10 10  == Linux NTP Daemon: Observed Stability == 
    11    Show how unstable linux NTP can be? 
      11  The Linux NTP client can be quite unstable at times. The following is the reported NTP time offset (in milliseconds) from a cluster of identical Linux systems synced with an NTP server on the local network: 
      12   
      13  [[Image(linux_ntp_stability.png)]] 
      14   
      15  There are both sudden large offsets observed (tens of milliseconds) and smaller, longer-term offsets compared to the server's clock that are believed to be real (audited by means of a simple program that returns the server's time directly and compares it against each system's clock without heed of the round-trip time on the LAN, which is typically sub-1ms). These departures are as yet unexplained.