Clock synchronization

Abstract

Apparatus including a shared device in communication with a plurality of computing machines external to the shared device, the shared device including at least one PTP domain coefficient storage area, the at least one PTP domain coefficient storage area receiving a PTP coefficient from a computing machine having a PTP client, and providing the PTP coefficient to a computing machine not having a PTP client. Related apparatus and methods are also provided.

Claims

1. An apparatus comprising: a shared device in communication with a plurality of computing machines external to the shared device, each of said plurality of computing machines comprising a virtual machine, each said virtual machine comprising a client synchronization driver, the shared device comprising a plurality of PTP (Precision Time Protocol) domain coefficient storage areas, said virtual machines comprising: at least one virtual machine having a PTP client to register as a provider for at least one PTP time domain of a plurality of PTP time domains, and at least one virtual machine not having a PTP client to register to one of said PTP time domains as a clock synchronization client, at least one of said PTP domain coefficient storage areas: 1) receiving a PTP coefficient associated with clock frequency correction and/or adjustment of time indications, from said at least one virtual machine having a PTP client, and, 2) providing said PTP coefficient associated with clock frequency correction and/or adjustment of time indications, to said at least one virtual machine not having a PTP client, wherein said clock synchronization client receives said PTP coefficient associated with said clock frequency correction and/or adjustment of time indications, for the PTP time domain of said clock synchronization client, via the respective client synchronization driver, wherein, upon said at least one virtual machine not having a PTP client receiving said PTP coefficient from said at least one virtual machine having a PTP client, the shared device sends an update event to said at least one virtual machine not having a PTP client.

2. The apparatus according to claim 1 and wherein said at least one virtual machine not having a PTP client comprises a plurality of virtual machines not having a PTP client.

3. The apparatus according to claim 2, and wherein, upon receiving a PTP coefficient from said virtual machine having a PTP client, the shared device sends an update event to each said virtual machine not having a PTP client.

4. The apparatus according to claim 1, and wherein said at least one virtual machine having a PTP client is in communication with a PTP grandmaster external thereto.

5. A method comprising: providing a shared device in communication with a plurality of computing machines external to the shared device, each of said plurality of computing machines comprising a virtual machine, each said virtual machine comprising a client synchronization driver, the shared device comprising a plurality of PTP (Precision Time Protocol) domain coefficient storage areas, said virtual machines comprising: at least one virtual machine having a PTP client to register as a provider for at least one PTP time domain of a plurality of PTP time domains, and at least one virtual machine not having a PTP client to register to one of said PTP time domains as a clock synchronization client, at least one of said PTP domain coefficient storage areas receiving a PTP coefficient associated with clock frequency correction and/or adjustment of time indications, from said at least one virtual machine having a PTP client; and at least one of said PTP domain coefficient storage areas providing said PTP coefficient associated with clock frequency correction and/or adjustment of time indications, to said at least one virtual machine not having a PTP client, wherein said clock synchronization client receives said PTP coefficient associated with said clock frequency correction and/or adjustment of time indications, for the PTP time domain of said clock synchronization client, via the respective client synchronization driver, wherein, upon said at least one virtual machine not having a PTP client receiving said PTP coefficient from said at least one virtual machine having a PTP client, the shared device sends an update event to said at least one virtual machine not having a PTP client.

6. The method according to claim 5 and wherein said at least one virtual machine not having a PTP client comprises a plurality of virtual machines not having a PTP client.

7. The method according to claim 6, and wherein, upon receiving a PTP coefficient from said at least one virtual machine having a PTP client, the shared device sends an update event to each said virtual machine not having a PTP client.

8. The method according to claim 5, and wherein said at least one virtual machine having a PTP client is in communication with a PTP grandmaster external thereto.

9. An apparatus comprising: shared means for communicating with a plurality of computing machines external to the shared means, said plurality of computing machines comprising respective virtual machines, each virtual machine comprising a client synchronization driver; and a plurality of PTP (Precision Time Protocol) domain coefficient storage means, said virtual machines comprising: at least one virtual machine having a PTP client to register as a provider for at least one PTP time domain of a plurality of PTP time domains, and at least one virtual machine not having a PTP client to register to one of said PTP time domains as a clock synchronization client, at least one of said PTP domain coefficient storage means: 1) receiving a PTP coefficient associated with clock frequency correction and/or adjustment of time indications, from said at least one virtual machine having a PTP client, and, 2) providing said PTP coefficient associated with clock frequency correction and/or adjustment of time indications, to said at least one virtual machine not having a PTP client, wherein said clock synchronization client receives said PTP coefficient associated with said clock frequency correction and/or adjustment of time indications, for the PTP time domain of said clock synchronization client, via the respective client synchronization driver, wherein, upon said at least one virtual machine not having a PTP client receiving said PTP coefficient from said at least one virtual machine having a PTP client, the shared means sends an update event to said at least one virtual machine not having a PTP client.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The present invention will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:

(2) FIG. 1 is a simplified pictorial illustration of a system for PTP distribution, constructed and operative in accordance with an exemplary embodiment of the present invention;

(3) FIG. 2 is a simplified flow illustration of an exemplary method of operation of the system of FIG. 1;

(4) FIG. 3 is an alternative view of the simplified flow illustration of FIG. 2; and

(5) FIG. 4 is a simplified pictorial illustration of a system for PTP distribution, in accordance with certain exemplary embodiments of the present invention.

DETAILED DESCRIPTION OF AN EMBODIMENT

(6) In the context of providing/distributing time synchronization (of which PTP is one particular non-limiting example, used herein for simplicity of description and without limiting the generality of the present invention) in virtual environments, the inventors of the present invention believe that in currently known systems a PTP slave is used per virtual machine (VM) (virtual machines being used by way of non-limiting example, it being appreciated that a computing machine which is not a virtual machine may alternatively be used). The PTP slave synchronizes the relevant time on the virtual machine, where the PTP slave runs based on synchronization (directly or indirectly via a PTP master) to a PTP grandmaster clock. When using PTP in a virtual machine environment in such a way, the inventors of the present invention believe that there are several drawbacks at least:

(7) 1. Each PTP client generates its own PTP traffic which causes load on the network and on the PTP grandmaster server, especially when there is a large number of VMs. Furthermore, the PTP grandmaster is limited in the amount of PTP clients that can be supported.
2. Generally speaking, a given physical device (computer) on which a plurality of virtual machines are instantiated usually has a single hardware (HW) clock and hence only a single PTP client can use the HW clock, while the rest of the PTP clients use a software (SW) clock which is less accurate.

(8) In exemplary embodiments, as described herein, one or more of the following advantages may be obtained:

(9) 1. Security is enhanced, as various virtual machines do not communicate directly (compare to the situation shown in FIG. 4).

(10) 2. Efficiency is enhanced, since the PTP master need not update every PTP client (again, compare to the situation shown in FIG. 4).

(11) 3. Ease of management is enhanced, since each PTP client registers to the same place, and need not find an appropriate PTP master to which to register.

(12) A general view of a system in accordance with such exemplary embodiments, as described in more detail below, is shown in FIG. 4, and generally designated 400.

(13) Reference is now made to FIG. 1, which is a simplified pictorial illustration of a system, generally designated 100, for PTP distribution, constructed and operative in accordance with an exemplary embodiment of the present invention. FIG. 1 depicts a plurality of virtual machines/hypervisor machines (shown, for simplicity of illustration, as VM0/HV0 102, VM1/HV1 104, VM2/HV2 106, VM3/HV3 108, . . . and VMn/HVn 110; it being appreciated that a larger or smaller plurality of virtual machines may be used). As is known in the art, virtual machines are implemented on a physical computer comprising one or more processors, memory, and other hardware that generally is present in physical computers. Each virtual machine is generally set up and controlled using a hypervisor or virtual machine monitor which provides resources to each virtual machine (these being HV0 . . . HVn, as also referred to above, in FIG. 1; it being appreciated that a larger or smaller plurality of hypervisors may be used).

(14) It is appreciated that, as is known in the art, each of VM0/HV0 102, VM1/HV1 104, VM2/HV2 106, VM3/HV3 108, . . . and VMn/HVn 110 is instantiated within a host device 112 (shown as a single host device 112, although it is appreciated that, in alternative exemplary embodiments, more than one host device may be used, with each host device having one or a plurality of virtual machines); the host device 112 fills the role of the physical computer as described above.

(15) The host device 112 includes a PTP master 114, which may be in communication with a PTP grandmaster (not shown) external to the system of FIG. 1.

(16) FIG. 1 also depicts a shared device 116, which may be, by way of non-limiting example, a shared memory area accessible by the VMs (e.g. memory area associated with the host machine that is running the VMs) or a ConnectX device commercially available from Mellanox Technologies, Ltd. Particular non-limiting examples of such devices, which comprise processor/s and memory, and which would generally be modified in firmware and/or software to implement exemplary embodiments of the present invention include: ConnectX-4; ConnectX-5; and ConnectX-6. As depicted in FIG. 1, the shared device 116 includes a master synchronization unit 140 and a plurality of domain coefficient storage areas 142.

(17) An exemplary mode of operation of the system of FIG. 1 is now briefly described.

(18) Certain of the virtual machines shown in FIG. 1 (by way of particular non-limiting example, VM0/HV0 102 and VM1/HV1 104) each run one or more PTP clients (118, 120, 122). Each of the virtual machines shown in FIG. 1 (VM0/HV0 102, VM1/HV1 104, VM2/HV2 106, VM3/HV3 108, . . . and VMn/HVn 110) includes a client synchronization driver (reference numerals 124, 126, 128, 130, and 132 respectively). The virtual machines shown in FIG. 1 (by way of particular non-limiting example, VM2/HV2 106, VM3/HV3 108, and VMn/HVn 110) which do not run one or more PTP clients each run a clock synchronization client (reference numerals 134, 136, and 138 respectively). Domain 0 PTP client 118 sends PTP coefficient parameters, via the client synchronization driver 124, to a domain coefficient storage area 142 for domain 0. PTP coefficient parameters comprise, for example, frequency “delta” for clock frequency correction, and “offset” for adjustment of time indication.

(19) Similarly, domain 1 PTP client 120 and domain 2 PTP client 122 send PTP coefficient parameters, via the client synchronization driver 126, to a domain coefficient storage area 142 for domains 1 and 2, respectively. Then, each clock synchronization client 134, 136, and 138 receives PTP coefficient parameters for its time domain via the respective client synchronization driver 128, 130, 132 from the appropriate coefficient storage area 142 for the appropriate PTP domain. By way of non-limiting example, it is appreciated that a given PTP domain might represent PTP time for a given time zone.

(20) The drawbacks mentioned above may be overcome by using the system of FIG. 1, in which communication channel between the virtual machines running a PTP client (depicted in FIG. 1 as VM0/HV0 102 and VM1/HV1 104) and other virtual machines which are not running a PTP client (depicted in FIG. 1 as VM2/HV2 106, VM3/HV3 108, . . . , VMn/HVn 110); those virtual machines which do not run a PTP client use the PTP coefficient parameters computed by a virtual machine that runs the PTP client, and obtain those parameters via the shared device 116, as described above. The necessity of (possibly a large number of) direct connections, as shown in FIG. 4, is thus obviated.

(21) Reference is now additionally made to FIG. 2, which is a simplified flow illustration (generally designated 200) of an exemplary method of operation of the system of FIG. 1.

(22) A shared memory (e.g., shown in FIG. 1 as comprised in a memory unit associated with the VMs or in the shared device 116 (ConnectX), comprising reference numerals 140 and 142) contains a master synchronization unit and an array of coefficient parameters per PTP domain. Each virtual machine that runs a PTP client registers itself (from the associated driver to a master synchronization unit on the shared device) as a PTP domain provider (time provider). Each virtual machine which requires PTP synchronization but does not itself run a PTP client registers itself (using a client synchronization driver, as described above) to one of the PTP domains as a clock synchronization client (“PTP user” in FIG. 2). As appropriate, deregistration may occur similarly, including by using mechanisms for registration and deregistration that are well-known and are not part of the scope of exemplary embodiments of the present invention. A PTP domain is a network (or a portion of a network) within which PTP operates, or a network within which all of the clocks are in sync. A single computer network can have multiple PTP domains operating separately, e.g., one set of clocks synchronized to a first time scale and another set of clocks synchronized to a second time scale. PTP can run over Ethernet or UDP/IP, thus a domain may correspond to a local area network or may extend across a wide area network.

(23) When a PTP client/provider's clock (for example, PTP clock) is updated, it updates (reference numeral 220) the driver for the virtual machine on which that client/provider runs, and the shared memory is also updated by the master synchronization unit (which may, e.g., may be implemented in firmware, hardware or software) that then runs with the new coefficient parameters. Once the shared memory is updated, an update event (reference numeral 230) to all clock synchronization clients of the domain is generated by the master synchronization unit. The clock synchronization client driver updates PTP timestamp (TS) and provides appropriate timing (generally world clock timing, such as, by way of non-limiting example: UTC; TAI; GPS; or another appropriate timing), according to the coefficient parameters provided by the time provider. The clock synchronization client updates its coefficient parameters, typically each time an update event is received.

(24) More specifically, the update is done from the time providers to the clock synchronization clients. The update event generally includes appropriate adjustment-relevant information (also referred to herein and in the drawings as “coefficient”) and allows the clock synchronization clients to adjust the time (such as PTP time) according to their respective domains. For example, such an update event may include an adjustment offset and a frequency offset from a domain's hardware clock, which will allow a clock synchronization client to reconstruct PTP time from hardware time.

(25) Update process: A PTP client on the time provider machine synchronizes to the PTP grandmaster using PTP protocol, such synching being a well-known PTP process. Once the PTP client updates the hardware clock in accordance with the PTP time thus obtained, the shared device (as also mentioned above) generates an update event to the clock synchronization clients, announcing the update. In exemplary embodiments, the clock synchronization clients use the most updated coefficient parameters available to them in order to translate the hardware clock time available to them to PTP format.

(26) Reference is now additionally made to FIG. 3, which is an alternative view of the simplified flow illustration of FIG. 2. The flow illustration of FIG. 3, generally designated 300, shows how the flow illustrated in FIG. 2 relates, in an exemplary embodiment, to the exemplary system of FIG. 1, and will be understood with reference to the above description of FIG. 2.

(27) It is appreciated that software components of the present invention may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example: as a computer program product or on a tangible medium. In some cases, it may be possible to instantiate the software components as a signal interpretable by an appropriate computer, although such an instantiation may be excluded in certain embodiments of the present invention.

(28) It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.

(29) It will be appreciated by persons skilled in the art that the present invention is not limited by what has been particularly shown and described hereinabove.