KVM-Clock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,
Last week I've sent a mail regarding the kvm-clock accuracy.
Now I try to draw-up my question again, any answer/partial/hint  is greatly appreciated

Our application is running in  a Tenant's Virtual Machine in a data-centre.
We have some OAM functions running in  the VMs.
One OAM function is to measure one-way delay between VMa and VMb. 
One way delay measurement requires that all machines should be synchronized to a common central clock.
Accuracy requirement is in order of 10s nano-seconds, hence only the 1588v2/PTP is suitable here.
Since we cannot use HW timestamping in a virtual machine (we cannot force using SR-IOV), I thought to run PTP on the physical machines and to sync the VMs to the host by the kvm-clock.
But now I see that the clock in the VM is far away from the host ( ~ Hundreds of micro-second) , and this before I even run the PTP in the host...
My test is very simple - I send a packet from host to the VM, I set the host time (tx_time) in the packet.  When the guest receives the packet it reads its time (rx_time)  and calculate the delay as :
Delay = rx_time - tx_time
I use the clock_gettime(REALTIME) in the host to set tx-time and in the guest to read rx_time. 
My questions :
1. Assuming my HW support the paravirtualization clock requirements - (see below output of cpuinfo)  , In Theory  - Is it possible to achieve 10s ns accuracy between VM clock and the host clock ? 
or I'm too naïve and have  to abandon the idea to run this timing sensitive application on a VM, and instead run it in  Linux  container for example?  

2. I understand that in the  kvm-clock process, the kvm writes (whenever it enters the VM)  its system_time and the VM_TSC @ current time to the pvclock page , then the guest OS can calculate its current time by:
Current-time = system_time + multiplier (RDTSC() -VM_TSC)   (system_time and VM_TSC as set by the kvmas set by the kvm))
I understand that there is no VM-exit when the VM calls RDTSC().  - is that description correct ?   I understand that this is supported by the guest OS and this should be transparent to my application, correct ?
My guest and host are Fedora 22.
 
3. Other idea how to achieve this accuracy ?   
Thanks in advance
Avi

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

Here's the 1st segment  of /proc/cpuinfo:

processor         : 0
vendor_id        : GenuineIntel
cpu family       : 6
model              : 63
model name     : Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz stepping           : 2 microcode       : 0x31 cpu MHz                     : 1200.062 cache size        : 30720 KB physical id       : 0 siblings            : 24 core id             : 0 cpu cores         : 12 apicid              : 0 initial apicid    : 0 fpu                   : yes fpu_exception : yes cpuid level       : 15 wp                   : yes flags                : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc cqm_occup_llc bugs                 :
bogomips         : 5199.72
clflush size      : 64
cache_alignment         : 64
address sizes   : 46 bits physical, 48 bits virtual power management:

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux