A METHOD AND APPARATUS FOR NETWORK TIME SYNCING

Abstract

Disclosed is a method of operating a network, the network having one or more nodes which are in communication with a server, the server including or being in communication with a high precision time source, to estimate a time delay between the server and each node, comprising initiating a delay request from the server which is transported over a transport layer to the node, the server receiving a delay response from the node receiving the delay request, wherein a timestamp for the delay request and a timestamp for the delay response are times recorded from the high precision time source, wherein the time delay is estimated from half of a time difference between the timestamps.

Claims

1. A method of operating a network, the network having one or more nodes which are in communication with a server, the server including or being in communication with a high precision time source, the method comprising estimating a time delay between the server and each node, which comprises: initiating a delay request from the server which is transported over a transport layer to node of the one or more nodes, wherein a first timestamp for the delay request is recorded from the high precision time source; receiving at the server a delay response from the node receiving the delay request, wherein a second timestamp for the delay response is recorded from the high precision time source; and estimating the time delay from half of a time difference between the first and second timestamps.

2. The method of claim 1, wherein each node includes a passive reflector which is adapted to both passively reflect data from the server and let received data through to the node, wherein the delay response is a passive reflection of the delay request.

3. The method of claim 1, wherein the passive reflector is built into a network interface card at the node.

4. The method of claim 1, wherein the passive reflector is embedded into a component insertable or otherwise connectable to a network interface card at the node.

5. The method of claim 4, wherein the component is a type of a small form pluggable.

6. The method of claim 1, wherein the transport layer is a physical layer.

7. The method of claim 6, wherein the transport layer is configurable to provide a physical connection for bidirectional communication between the transport layer and one of the one or more nodes at a time, and one-way communication from the transport layer to the remaining one(s) of the one or more nodes.

8. The method of claim 7, wherein estimating the time delay between the server and each node includes: configuring the physical layer for transport of time protocol data between the server and each node, sending the delay request, and receiving the delay response from the node, one node at a time.

9. The method of claim 8, wherein the physical layer comprises a matrix of switches and/or optical splitters.

10. The method of claim 1, further including issuing a time synchronisation request to the one or more nodes.

11. The method of claim 10, wherein the time synchronisation request is handled by a time synchronisation logic.

12. The method of claim 11, wherein the server stores the time delay for each node, and the time synchronisation logic is a slave clock logic.

13. The method of claim 11, wherein the time synchronisation logic is implemented in hardware connectable or embedded in network interface cards at the nodes.

14. The method of claim 11, wherein the time synchronisation logic is implemented in software.

15. The method of claim 1, wherein a time protocol data transport between the server and the one or more nodes is enabled over a physical layer, which is reconfigurable to provide a physical connection, over which bidirectional communication between the physical layer and one of the nodes is enabled, one node at a time.

16. The method of claim 1, wherein the delay response is a passive reflection of the delay request.

17. An adapter for allowing a device to access a shared bus of a network, comprising: an interface device configured to receive incoming packets from the bus and output outgoing packets to the bus; and a passive reflector to reflect incoming packets back to the bus.

18. The adapter of claim 17, wherein the passive reflector is embedded in the interface device.

19. The adapter of claim 17, wherein the passive reflector is embedded in a component which is insertable into or connectable to the interface device.

20. An adapter for allowing a device to access a shared bus of a network, comprising: an interface device configured to receive incoming packets from the bus and output outgoing packets to the bus; and a time synchronisation logic module which is a slave clock module to a grandmaster time module of the network.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Embodiments will now be described by way of example only, with reference to the accompanying drawings in which

[0027] FIG. 1 is a is a schematic depicting a traditional Precision Time Protocol;

[0028] FIG. 2 is a is a schematic depicting a High Precision Time Protocol in accordance with one embodiment of the present invention;

[0029] FIG. 3 is a is a schematic depicting a High Precision Time Protocol in accordance with another embodiment of the present invention;

[0030] FIG. 4 is a is a schematic depicting a High Precision Time Protocol in accordance with another embodiment of the present invention;

[0031] FIG. 5 is a schematic depiction of a data flow between a data transport layer and a node in one embodiment;

[0032] FIG. 6 is a schematic depiction of a data flow between a data transport layer and a node in a different embodiment; and

[0033] FIG. 7 is a is a schematic depicting a High Precision Time Protocol in accordance with a further embodiment of the present invention.

DETAILED DESCRIPTION

[0034] In the following detailed description, reference is made to accompanying drawings which form a part of the detailed description. The illustrative embodiments described in the detailed description, depicted in the drawings and defined in the claims, are not intended to be limiting. Other embodiments may be utilised and other changes may be made without departing from the spirit or scope of the subject matter presented. It will be readily understood that the aspects of the present disclosure, as generally described herein and illustrated in the drawings can be arranged, substituted, combined, separated and designed in a wide variety of different configurations, all of which are contemplated in this disclosure.

[0035] FIG. 1 is a schematic depicting a traditional Precision Time Protocol (PTP) 100. The grandmaster 102 is the server component which includes or is in communication with a time source 104 which generates a “true” time or an accepted standard of true time. The time source 104 is different depending on the specific implementation, but can be from a global positioning system (GPS) module, a pulse-per-second (PPS) signal, a crystal oscillator, etc. The grandmaster 102 is adapted to be in bidirectional communication with a data link layer 108 which acts as a message distribution layer. The data link layer 108 is adapted to be in bidirectional communication with one or more host computing systems, or nodes 106. Thus, the communication between the grandmaster 102 and the host computing systems 106 is facilitated by or performed over the data link layer 108.

[0036] In the prior art protocol, the host computing system 106, from time to time, issues a “delay request” which is sent over the data link layer 108 to the grandmaster 102. The time at which the delay request is sent, T.sub.1, as measured by the local clock on the host computing system 106, is recorded. The grandmaster 102, upon receipt of the delay request, issues a delay response message to the host computing system 106 from which the delay request was generated. The time at which the delay response is received by the host computing system, T.sub.2, as measured by the local clock on the host computing system 106, is also recorded. The “round trip” delay is therefore T.sub.2−T.sub.1. The one-way delay, estimated for data traffic from the host computing system to the grandmaster, or vice versa, is ½ (T.sub.2−T.sub.1).

[0037] The grandmaster 102 is adapted to send out synchronisation requests—being an instruction for the host computing systems 106 to synchronise their time with an incoming timestamp T.sub.3 (not shown). The host computing systems 106 then each set the time to T.sub.3 plus the delay calculated for that host computing system 106.

[0038] In the prior art, the connection layer between the grandmaster 102 and the host computing systems 106 is the data link layer 108, with reference to the Open Systems Interconnection Model (OSI model). The OSI model is known in the art.

[0039] An improved time synchronisation protocol 200 according to one embodiment of the present invention is shown in FIG. 2. In this embodiment, the delay request is initiated by the grandmaster 102, and includes the timestamp T.sub.S1. When the host computing system 106 receives the request, it generates a delay response and transmits the delay response back to the grandmaster 102. Upon receiving the delay response, the grandmaster 102 records the time the receipt with the timestamp T.sub.S2. The delay is thus calculated as ½ (T.sub.S2−T.sub.S1). The timestamps T.sub.S1 and T.sub.S2 are generated using the grandmaster's time source 104. They are of a higher precision compared the timestamps T.sub.1 and T.sub.2 taken using the local clocks on the host computing systems. The delay which is calculated is therefore of an improved precision. This particular embodiment does not require any modification of the equipment connected to the network.

[0040] It is preferred that a single message type is used, for both measuring the network delay (i.e. the delay request and the delay response messages), and for sending the current time (sync) messages, and where required for sending the “follow up” message with the timestamp for synchronisation. The message type can be for example, the same as the message type used by the conventional PTP to send the time synchronisation message. Optionally, these messages are layered over standard PTP messages for backwards compatibility.

[0041] With reference to FIG. 1, the data link layer 108 performs an aggregation of the delay request messages, and determine data routing for the messages, where queuing potentially occurs, degrading the overall synchronisation quality. There is therefore a “jitter” which is inherently associated with the data transport over the data link layer 108, which contributes to a lessening in the accuracy or precision of the time synchronisation process.

[0042] An improved time synchronisation protocol 300 according to another embodiment of the present invention is shown in FIG. 3. In this embodiment, the communication layer, being an intermediate layer between the grandmaster 102 and the host computing system 106, is a physical layer 110, i.e. layer “1” with reference to the OSI model. The physical layer 110 will be used to enable time protocol data transport. The physical layer 110 is configurable, comprising a matrix of switches and/or broadcasting optical splitters.

[0043] The switches used for the proposed physical layer 110 are the type disclosed in WO/2015/179895, the contents of which are incorporated herein. The switches in the physical layer 110 are “crosspoint” switches which connect ports physically, rather than conventional ethernet switches. Thus, the layer “1” fabric (i.e. physical layer) 110 creates physical channels of communication, and does not perform any higher level interpretation as to the routing of the data packet.

[0044] The physical layer 110 is configurable for bidirectional communication with one host computing system 106 at a time. The host computing system for which the physical layer 110 is configured to enable bidirectional communication is referenced 106′. The remaining host computing systems 106 connected to the network are able to receive data from the physical layer 110, but are not able to send data to the physical layer 110.

[0045] The delay estimate process needs to be performed for each node (host computing system) connected to the network. Thus, once the delay response from the host computing system 106′ is received by the grandmaster 102, the physical layer 110 will be reconfigured to enable bidirectional communication with the next host computing system. The reconfiguration is performed by the grandmaster 102.

[0046] Using the layer “1” fabric 110 to distribute the messages, data transport jitter which would otherwise occur in the data link layer 108 is reduced or avoided. By using, in particular, the physical switches which connect ports and do not interpret data packets, the jitter is avoided. Minimising or avoiding the jitter over the physical layer 110 acting as the message distribution layer enables an improvement of the time synchronisation accuracy.

[0047] Therefore, the transport of the delay messages, delay responses, time synchronisation requests, and where applicable the follow up messages to the synchronisation requests, occurs over the physical layer 110. The performance of the tasks associated with these messages will be improved, i.e. done with a better time precision.

[0048] Selectively configuring the layer “1” fabric 110 (e.g. via a matrix switch or selectable optical switch), so that the return messages can be received by the grandmaster 102 from individual nodes (i.e. host computing systems) 106 can be a slower process, relative to the prior art process where multiple nodes 106 can initiate and send delay requests. However, the delay request initiation occurs infrequently, and therefore does not affect the critical distribution of data.

[0049] FIG. 4 depicts the protocol in accordance with a further embodiment of the invention. This embodiment is similar to the embodiments shown in FIG. 2, and adds the further feature that each of the host computing system 106 includes a reflector component 114 that is adapted to passively reflect the delay request message initiated from the grandmaster 102, back to the grandmaster 102.

[0050] The message handling which occurs in the process described above in relation to FIG. 4, is schematically depicted in FIG. 5 and FIG. 6.

[0051] The passive reflection of the request data means that there is no queuing or buffering of the request data, which could otherwise create jitter in the data routing. With the passive reflection, data is reflected bit by bit. That is, every bit of data that that arrives at the host computing system 106 gets sent back out again without first being processed at the host computing system 106.

[0052] This is implemented by, for example, a PMA (physical medium attachment) loop back, which is a low level bit by bit loop back. It functions as a transceiver, without decoding the data. The PMA can be an electrical or optical reflector, although an optical reflector would be more expensive. Data is also permitted to passes through the PMA. Thus, in the event of a receipt of a time synchronisation request, the PMA will pass the time synchronisation request to be processed by the time synchronisation logic (see FIGS. 5 and 6) associated with the host computing system 106.

[0053] The PMA can be in the form of a transceiver or a transmitter-receiver, or any other component capable of the aforementioned functionality. The passive reflector 114 is embedded in a pluggable component 118 (see FIG. 5) such as a small form factor pluggable or “SFP”, which is a small module that is insertable or otherwise connectable to the network interface card. E.g., it is plugged into the network interface card. Different types of SFP, such as but not limited to, a quad channel small form factor pluggable (QSFP) or an enhanced small form factor pluggable (SFP+), can also be used. The network card can be the standard network card, and does not need to be replaced in order for the reflector function to be implemented. It can receive PTP format messages and be still be used with the proposed protocol, by modifying the software implementation at the host computing system to accommodate or implement the proposed protocol.

[0054] Alternatively, the hardware or firmware circuitry of the network interface card can be modified to implement the passive reflection functionality. Thus the passive reflector component 114 is the part of the modified circuitry that implements the passive reflection. However, doing so would require new network interface cards to be issued to the users/clients, and is less preferable in cases where it is desired to retrofit existing network interface cards to adopt the proposed protocol.

[0055] In the embodiments shown in FIGS. 4 to 6, there is no requirement for a hardware or software implementation at the host computing systems 106 to actively process the delay requests. Thus, the jitter in the overall network is reduced.

[0056] Under the conventional PTP protocol, the clients are responsible for maintaining their own state—that is, maintain the implementation to comply with the PTP protocol, to, e.g., send delay requests, manage delay responses, respond to synchronisation messages, etc. The implementation adds complexity which may also contribute to the further delay or inaccuracy in network time synchronisation.

[0057] By using simple hardware components for some or all of the protocol processes, the implementation is simplified. The delay request implementation is handled by the hardware as shown in FIGS. 4 to 6.

[0058] As mentioned, the passive reflector 114 allows data to pass through, thus a time synchronisation request can still reach the destination for processing.

[0059] It is preferred that the system state information, relating to the host computing systems 106, is stored at the grandmaster 102. The system state will include, but is not limited to, a list of host computing systems and their relative path delays as calculated in the manner described above with reference to FIG. 2.

[0060] It is preferred that some or all of the management of the system state information, the complexity of protocol implementation and adherence thereto, be kept at the grandmaster level. In the embodiment shown in FIG. 4, the complexity involved in addressing the delay requests is reduced to a passive hardware circuitry at the host computing system.

[0061] It is further preferred that the remaining complexity is retained at the grandmaster 102. For instance, the grandmaster 102 will keep track of the delays in the network.

[0062] In the embodiment shown in FIG. 5, the host computing system includes or is associated with a time synchronisation logic module 116 which implements the time synchronisation logic. This is a simple logic located at the client's location. The only requirement is that it receives the timestamp data. The module 116 can be, e.g., a Field Programmable Gate Array (FPGA) or an application specific integrated circuit (ASIC). It can also be a pluggable component which works with an existing network interface card or which is embedded in a modified network interface card. If the time delay information associated with each node or host computing system is managed by the grandmaster, then the logic would only need to be a slave clock to the grandmaster 102.

[0063] Alternatively, as shown in FIG. 6, the time synchronisation logic is software implemented, and the existing network interface card 120 remains. A high precision time protocol (HTPT) software 122 which embodies the proposed protocol controls the time synchronisation function.

[0064] FIG. 7 schematically depicts an improved high precision time protocol 400 in accordance with a further embodiment which is the preferred embodiment, combining the features discussed above with reference to FIGS. 2 to 6. It also offers the best time precision compared with the previously described embodiments. In the testing performed, it has been found that a precision of +/−50 picoseconds (PS) can be achieved.

[0065] The variation in the implementation discussed thus are also included in the variation in the scope of the implementation for the most preferred embodiment. In FIG. 7, the dashed arrows represent the protocol where the grandmaster 102 initiates the delay request message, and receives the delay response message. The delay response message is a passive reflection from the reflector 114 back to the grandmaster 102. The transport of these messages, as well as of the time synchronisation request (and if required, the follow up message), is enabled over a physical switch layer 110.

[0066] Depending on the equipment requirement—i.e. preference to replace client equipment or issue new equipment, and/or the protocol management requirement, a more specific variation of the generally most preferred embodiment can be selected.

[0067] In the above, the “Grandmaster” 102 can be a software program or module which is running on a server or host device, as long as that device has or is in communication with a high precision clock, and can timestamp messages going in and out. For example, the grandmaster 102 can be provided by a host or server computer having a HPT network card (ExaNIC HPT) —that can provide the high quality timestamps to send/receive message events. Some components of the protocol can be software implemented on the computer which hosts the grandmaster 102.

[0068] Variations and modifications may be made to the parts previously described without departing from the spirit or ambit of the disclosure. For instance, variations in the implementation of FIG. 4 are discussed with reference to FIGS. 5 and 6. In some embodiments, the passive reflection may be performed at the server 102 instead of the host computing systems.

[0069] In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word “comprise” or variations such as “comprises” or “comprising” is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.