Home

Documentation

Project Support

Changes in Version 5 of GraspExtrasSoftwareControllerNTP

Author:
crae
Timestamp:
Wed Oct 17 16:34:39 2012

Legend:

Unmodified
Added
Removed
Modified

  • GraspExtrasSoftwareControllerNTP

    v4 v5
    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 == 
      8  == Stargrasp Client: NTP Server Link Speed == 
    9 9  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. 
    10    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): 
      10  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, both graphs are in usec): 
    10 10  [[Image(ntp_controller_100mbit.png)]] 
    11 11  [[Image(ntp_controller_gigabit.png)]] 
    12    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. 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. 
      12  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. 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. Nevertheless, when synchronised with the Gigabit server, the controllers take less time to settle upon their NTP clients' startup, and stay closer to zero offset than when communicating with a 100Mbit server. 
    12 12  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. 
    13 13  == Stargrasp Client: Observed Stability == 
    14 14  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). 
    15    I Images go here... 
      15  I In this example, "t29" is a Linux system running version 4.2.6p4 of the NTP server daemon, serving 16 STARGRASP controllers via a Gigabit ethernet link. At around 11am, it reported a sizeable disturbance in its reported time offset (msec): 
    15 15  [[Image(ntp_linux_server_bounce.png)]] 
      16  This impulse induced ringing in the controllers' NTP client, which persisted for some time (vertical scale in usec): 
    16 17  [[Image(ntp_controller_bounce.png)]] 
      18  Attempts will be made in future to try to tune out the effects of the sudden changes in server offset. This may prove difficult since the server's departures can often be quite long in duration. 
    17 19  == Linux NTP Daemon: Observed Stability == 
    18 20  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: 
    19 21  [[Image(linux_ntp_stability.png)]] 
    20 22  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.