perfsonar-user - [perfsonar-user] RE: Clock stability on VM
Subject: perfSONAR User Q&A and Other Discussion
List archive
- 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:]
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----- 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 |
- [perfsonar-user] Clock stability on VM, Purna Mididuddi, 12/14/2016
- [perfsonar-user] RE: Clock stability on VM, Garnizov, Ivan (RRZE), 12/14/2016
- [perfsonar-user] RE: Clock stability on VM, Purna Mididuddi, 12/15/2016
- <Possible follow-up(s)>
- Re: [perfsonar-user] Clock stability on VM, Mark Feit, 12/14/2016
- RE: [perfsonar-user] Clock stability on VM, Purna Mididuddi, 12/15/2016
- Re: [perfsonar-user] Clock stability on VM, Mark Feit, 12/15/2016
- RE: [perfsonar-user] Clock stability on VM, Purna Mididuddi, 12/15/2016
- [perfsonar-user] RE: Clock stability on VM, Garnizov, Ivan (RRZE), 12/14/2016
Archive powered by MHonArc 2.6.19.