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

Re: [Xen-users] clocksource - XenServer 7 - AKA xen 4.6.1

On Tue, Oct 25, 2016 at 04:41:57PM -0500, WebDawg wrote:
> Hello,
> I was looking at my xen server clock source and I see:
> xl dmesg | grep -i timer
> (XEN) [ 3.306920] Platform timer is 14.318MHz HPET
> I have a E5420 and I have ran into clocksource issues with proxmox/kvm
> so I was wondering about some things while reading this documentation:
> https://wiki.xen.org/wiki/Xen_power_management#System_time.2FTSC_skew
> Quote:  "If TSC frequency is invariant across freq/voltage scaling
> (true for all Intel processors supporting VTx) and all processors
> within the box share one crystal, please give boot option
> 'consistent_tscs'."
> Is that really true?  There is no shutdown/slowdown/suspend of the tsc
> clock with VT processors?  The only reason I ask is because of the
> proxmox (kvm) issue I was having and I think I had to disable speed
> step on the system to fix at the time.  It was an i5 proc w/ VT-x...no
> VT-d though.
> I actually get more and more confused the more I read about CPU
> timers.  I have a CPU intensive domU python application that seems to
> need a more high precision timer then it has right now.
> It reads the current time, does something, and the reads again and if
> both reads are the same (which I think they are) it crashes.  I always
> thought that tsc was more precise but (as I said i was getting
> confused) I just read something that says that HPET was more precise.

How do you read the time inside this python program? TBH, it doesn't look like 
good approach. Some systems might only be capable of returning the time using 
second-precision, so there's a high chance that two consecutive calls to get 
time can return the same value.

> It could be that I do not need precision but instead the speed so it
> increments.  But I cannot understand how a clock on a CPU (that does
> not follow the speed step stuff or power save stuff) cannot be
> accurate.
> Reading this:  
> http://stackoverflow.com/questions/13950264/does-using-tsc-as-clock-source-improve-timer-and-scheduling-granularity
> Quote:  "remember that Time stamp counter is incremented at every CPU
> clock cycle."
> CPU clock cycle > HPET
> It does go on to talk about the tsc issues that have to do with idle
> states, scaling, and power but none of this applies to me right?
> (right?)
> Any suggestions on what I should do here or which is better?
> Why is xen 4.6.1 choosing HPET as default?  Also even if I switch over
> to tsc or constant_tsc is the xen clocksource in the domU able to
> handle the higher clock rate of a tsc based timer?

You are mixing things here, the HPET[0] stands for High Precision Event Timer, 
note the "Event" part of this. HPET generates time based interrupts (events), 
while the TSC[1] is just a counter, it cannot generate any events, it just 
tells you how many cycles have passed since power-on.


[0] https://en.wikipedia.org/wiki/High_Precision_Event_Timer
[1] https://en.wikipedia.org/wiki/Time_Stamp_Counter

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.