Re: KVM-Clock

[Marcelo Tosatti <mtosatti@redhat.com>]

On Wed, Feb 24, 2016 at 08:15:46AM +0000, Avi Cohen wrote:
> >> 
> >> 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?  
> 
> >You need realtime KVM to run a time sensitive application on a VM.  What are your requirements?
> 
> >RHEL-RT-KVM achieves 20us maximum latency (and that is effectively the best clock resolution you can give to users, irrespective of synchronization between guest clock and host clock).
> 
> The requirement is that the guest VM will be synced to the host clock - I'm not talking on real-time in the meaning of speed, but I need that the guest clock will measure the exact delay between packet transmission from the host to the packet received in the guest. 

This makes no sense - if you want a "reliable clock synchronized up to X
microseconds", then you have to take into account any possible delay
incurred by scheduling (as scheduling determines how reliable a clock
read can be) into the clock reliability calculation.

> My problem now is that sometimes when I receive the packet in the guest I calculate a negative delay because my clock in the guest is in delay relative to the host clock.

Use the guest TSC and host TSC values (rdtsc in both).

Then subtract from host TSC timestamps the tsc_offset value. 

You'll get a "perfect" synchronized RDTSC clock. 

To find out the tsc_offset value, enable kvm_write_tsc_offset tracepoint
in the host (before the particular guest boots).

> I expect to get a positive (jittered) delay in the order of 10s of us.  
> 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.