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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

Please keep xen-users on Cc.

On Tue, Nov 29, 2016 at 10:58:47AM -0600, WebDawg wrote:
> On Mon, Nov 28, 2016 at 4:47 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx>
> wrote:
> 
> > 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
> 
> 
> This is what caused me to look into this more:
> 
> https://github.com/spesmilo/electrum-server/pull/155

I don't know anything about this software, but it seems to use Python's 
time.time() function, which according to the documentation:

"Note that even though the time is always returned as a floating point number, 
not all systems provide time with a better precision than 1 second"

So it seems like if delta == 0, you should just return from that function and 
wait for delta to be positive.

You can use the following trivial script to check that time.time() can indeed 
return the same time. I've run it on bare metal and the time only seems to 
change in 1 every 10 calls.

Roger.

---8<---
#!/usr/bin/env python

import time

while 1:
        prev = time.time()
        if prev == time.time():
                print "No timestep detected"
        else:
                print "Timestep detected"


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