[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 
a 
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 
the 
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.

Roger.

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

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users

 


Rackspace

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