Home

Documentation

Project Support

Changes in Version 4 of GraspExtrasSoftwareControllerNTP

Author:
crae
Timestamp:
Wed Oct 17 16:19:10 2012

Legend:

Unmodified
Added
Removed
Modified

  • GraspExtrasSoftwareControllerNTP

    v3 v4
    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  == Stargrasp Client: NTP server link speed == 
      9   
      10  It has been observed that the controller's NTP client performs far better when connected to an NTP server via a Gigabit ethernet link as opposed to one serving time via an 100Mbit link. 
      11   
      12  The following two graphs are the calculated NTP offset for 16 STARGRASP servers synched to a local network NTP server on the same computing hardware first via a 100Mbit link (top) and then via a Gigabit ethernet port (bottom): 
      13   
      14  [[Image(ntp_controller_100mbit.png)]] 
      15  [[Image(ntp_controller_gigabit.png)]] 
      16   
      17  The path to the server via its Gigabit port is somewhat lower-latency, but the additional round-trip time is supposed to be accounted for by the two pairs of timestamps in the NTP packet. 
      18   
      19  It is therefore recommended that if the controller NTP client is used, the server should connect to the controller via a Gigabit link for better performance. 
      20   
    8 21  == Stargrasp Client: Observed Stability == 
    9    Show time offset when connected to NTP server via 100Mbit and Gigabit, long-term stability, etc. 
      22  The controller NTP client has been checked that it doesn't exhibit grossly incorrect behaviour, but hasn't been tuned much beyond that. As such, there are cases where it may not perform optimally. Most of these appear to be related to the NTP server's time offset bouncing around (see the following section for more examples). 
      23   
      24  Images go here... 
      25  [[Image(ntp_linux_server_bounce.png)]] 
      26   
      27  [[Image(ntp_controller_bounce.png)]] 
    10 28  == Linux NTP Daemon: Observed Stability == 
    11 29  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 30  [[Image(linux_ntp_stability.png)]] 
    13 31  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.