[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |