Skip to Content.
Sympa Menu

perfsonar-user - [perfsonar-user] RE: Clock stability on VM

Subject: perfSONAR User Q&A and Other Discussion

List archive

[perfsonar-user] RE: Clock stability on VM


Chronological Thread 
  • From: Purna Mididuddi <>
  • To: "Garnizov, Ivan (RRZE)" <>, "" <>
  • Cc: Purna Mididuddi <>
  • Subject: [perfsonar-user] RE: Clock stability on VM
  • Date: Thu, 15 Dec 2016 00:29:19 +0000
  • Accept-language: en-US
  • Ironport-phdr: 9a23:u6UkhhJpF0P4zR6oq9mcpTZWNBhigK39O0sv0rFitYgXKvr9rarrMEGX3/hxlliBBdydsKMfzbSJ+Pi8EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQtFiT6zbL9oLRi7rwrdutUZjIB/Nqs/1xzFr2dSde9L321oP1WTnxj95se04pFu9jlbtuwi+cBdT6j0Zrw0QrNEAjsoNWA1/9DrugLYTQST/HscU34ZnQRODgPY8Rz1RJbxsi/9tupgxCmXOND9QL4oVTi+6apgVQTlgzkbOTEn7G7Xi9RwjKNFrxKnuxx/2JPfbIWMOPZjYq/RYdYWSGxcVchTSiNBGJuxYYsRAeQcIeZWoYrzp1UMohu/GQajC/jixSVUinPqx6A2z/gtHAPA0Qc9H9wOqnPUrNDtOakITOC11q/Iwi/eZP1R2Dfy9YnIfQ08of6RQL1wcNfaxE43FwPAj1WftI3lMC6I1usQqGWW8vBgVeWzhGE9tg5+vCKjydsrionMn48YzE3P+yt+wIYwP9K4SUh7bMa6H5tLrS2aMZV5Qt86T2F1pCk6zqcJtYSlcycX1ZQr3x/fa+CDc4SS7BPsTuiQLS1ghHJhYL6/iAuy8U26xu3zUcm0zlBHpTdGnNnUrn0ByR3e5tabRvZ440utxSqD2gXX5+1YPUw4iK/WJpw7zbM1k5cfrFzPEjLqlEnskaOaaFko9vKq5unpeLnrqJ+RO5d6ig7gMakihsmyDOE3PwUOUWWW9uGx26b+8UD7QrhHi+A6nrXbvZ/AIMkUvbK2DBJW34sl9h2xFS2p0M4CknkCNF9FeAyIj4zuO1zWJfD5AuuzjE61nDt32/zKIrPhDonOI3TfjbvtZ65961ZcyAo01tBf+4xbBawbLP3vXU/xscTUDh4/MwOq3+bqEMtx24IAVW6TB6KVLb/evUON6+8rP+WAeJIZtTP/Jvc/4vPjiGI1lUcYfaaz3JsXbH64Hu5hI0WceXfsmtIBEWYXsQo/UePqlUCNXCVIaHaoWKIz+is0B5+4AovZWo+th7mB0D+hHpJKfmBGFkyMEXDweoWcRfgMciySItRmkjwCT7ehUZYt1Qy1tADk0bpqNe7U+iwDtZL/z9h5+ffflRA09TxoEcudyWeNQH9onm8WXTM5wr1woVEugmuEhOJXiuZeFM5U+bcBcxkzM9ac9dZIJpG4ElbAYN6PDlmvWNOnEzYvZtw43pkCbhA5U5+6gwrNxC2sCqVQiqeGHrQ19L7RxX78O5w7xnrbnuF1l1Q8TNBIM2S8w7Nk+hL7BojVnl+fmrrwM6kQwXie2n2EyD+2oVteWUZVUKnEUW0Takqe+cz850/DQ6KiIZ49NQBIxcPEIaxPPI66xW5aTevubYyNK1m6nH29UFPRnuuB

Hello Ivan,

Yes, I’m looking for comments from the community.

Thanks for your response. In your deployments, what other measures do you take to have a stable clock on VMs (apart from dedicated NIC, cpu and running ntp).

 

Thx,

Purna

 

From: Garnizov, Ivan (RRZE) [mailto:]
Sent: Wednesday, December 14, 2016 4:57 AM
To: Purna Mididuddi <>;
Subject: RE: Clock stability on VM

 

Hi Purna,

 

I believe you are looking for comments from the community and not inquiring us for support on perfSONAR.

Generally I agree and have also seen very stable system clocks on virtual machines.

 

Regards,

Ivan Garnizov

 

GEANT SA1T2: pS deployments GN Operations

GEANT SA2T3: pS development team

GEANT SA3T5: eduPERT team

 

-----Original Message-----
From: [] On Behalf Of Purna Mididuddi
Sent: Mittwoch, 14. Dezember 2016 09:53
To:
Cc: Purna Mididuddi
Subject: [perfsonar-user] Clock stability on VM

 

Hi,

As mentioned in the documentation, clock stability and accuracy are very important for tests like latency measurement.

We are looking to run a perfsonar node on a VM, with dedicated NIC, dedicated CPU cores and disabling VM swapping. Also we are running NTP on the VM. Given these, can we assume clock on VM will be accurate? If not, what other factors will play a role in VM environment that aren't in bare-metal case.

 

The "ntpq -p" output on VM shows the offset column is changing slightly over a period. But same behavior is seen on bare-metal output too. So, how can we say baremetal has more clock accuracy than VM?

 

On VM:

---------

root@VM:~# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

+chronos.asda.gr .GPS.            1 u   55   64  177  231.542  -13.305   7.205

-tick.ucla.edu   .GPS.            1 u   57   64  177   28.798   -1.070   4.894

+ntp.itl.waw.pl  .ATOM.           1 u   50   64  177  203.149   -7.759   2.650

-saturn.es.net   .CDMA.           1 u   58   64  177   24.740    1.389   2.615

*tempus1.gum.gov .PPS.            1 u   57   64  177  204.282  -11.470   5.082

root@VM:~#

root@VM:~#

root@VM:~# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

-chronos.asda.gr .GPS.            1 u  136  256  377  231.800  -15.517   3.405

+tick.ucla.edu   .GPS.            1 u   85  256  377   29.182   -0.619   1.417

+ntp.itl.waw.pl  .ATOM.           1 u  166  256  377  203.748   -9.379   0.435

*saturn.es.net   .CDMA.           1 u  221  256  377   25.082   -0.908   1.344

-tempus1.gum.gov .PPS.            1 u  142  256  377  204.425  -10.678   0.749

 

 

 

On bare-metal:

-----------------

root@HOST:~# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

eth-0.nms-rlat. .INIT.          16 u    -   64    0    0.000    0.000   0.000

nms-rlat.hous.n .INIT.          16 u    -   64    0    0.000    0.000   0.000

nms-rlat.losa.n .INIT.          16 u    -   64    0    0.000    0.000   0.000

eth-1.nms-rlat. .INIT.          16 u    -   64    0    0.000    0.000   0.000

+chronos.es.net  .CDMA.           1 u   59   64  177   89.979   10.674   5.734

*saturn.es.net   .CDMA.           1 u   57   64  177   24.547   10.046   5.885

root@HOST:~#

root@HOST:~#

root@HOST:~# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

nms-rlat.chic.n .INIT.          16 u    -  512    0    0.000    0.000   0.000

eth-1.nms-rlat. .INIT.          16 u    -  512    0    0.000    0.000   0.000

eth-1.nms-rlat. .INIT.          16 u    -  512    0    0.000    0.000   0.000

nms-rlat.newy32 .INIT.          16 u    -  512    0    0.000    0.000   0.000

+chronos.es.net  .CDMA.           1 u   59   64  377   90.446    4.540   6.255

*saturn.es.net   .CDMA.           1 u   59   64  377   24.889   -4.279   5.590

 




Archive powered by MHonArc 2.6.19.

Top of Page