perfSONAR User Q&A and Other Discussion

["Garnizov, Ivan (RRZE)" <>]

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