[concurrency-interest] High resolution timers and JSR 310

[David Holmes]

Hmm well the cycle counter is *bad* enough that it's not used as a timing
source by the major OSes anymore. The Linux folk have abandoned it until we
have cycle counters that are synchronized across cores. Windows swapped it
for the pmTimer back in the XP SP2 days and only uses it on systems where it
can't cause a problem. Of course you can also get utilities from Intel and
AMD to synchronize the TSC across processors if you really want to use it.
Solaris can still use the TSC on x86 but, as far as I know, performs its own
synchronization.

If you need a monotonic counter then the cycle counter is only useful on
uniprocessors/single-cores. And of couse you need to disable sped-step or
any other energy saving mechanism that alters the cycle counter frequency.

So caveat emptor. ;-)

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Jeremy
> Manson
> Sent: Wednesday, 21 May 2008 5:41 PM
> To: Osvaldo Pinali Doederlein
> Cc: concurrency-interest
> Subject: Re: [concurrency-interest] High resolution timers and JSR 310
>
>
> Hi, Osvaldo,
>
> This is what we tried.  There are two issues:
>
> 1) The CPU can slow down the cycle counter to save speed, and
>
> 2) The cycle counter can be different on each CPU on systems with
> multiple processors.
>
> It's good enough for a lot of uses, although you can imagine the
> confusion it causes from time to time.
>
> 					Jeremy
>
>
> Osvaldo Pinali Doederlein wrote:
> > Hi,
> >
> > Now I'll fully expose my ignorance on the subject of computer time
> > measurement: Why can't a system rely on the CPU, which supposedly
> > contains a high frequency, stable oscillator for its clock? For
> example,
> > on a 2.0GHz CPU, the cycle counter provides a timer with 0,5ns
> > precision, and I can read this counter with the RDRTSC opcode. I should
> > be able to adjust this value to nanoseconds (in this case just a divide
> > by 2), add it to the boot-time wallclock provided by the motherboard
> > (since the RTSC is zeroed at boot), and be done with it - using
> only the
> > RTSC as the source for all clock needs afterwards. I know there are
> > problems like energy-efficient CPUs that change their clock frequency
> > dynamically, and synchronization with NTP or Windows Time servers, but
> > the system should be able to monitor these factors and adjust the
> > nano-clock, just like it does for the low-precision clock.
> >
> > BTW, I don't need an atomic-quality clock that's extremely
> accurate with
> > the real time of my timezone... even in distributed systems, I
> only need
> > a reasonably good accuracy within a cluster or the local
> network. I need
> > nanosecond-level accuracy, though, within a single computer system or
> > application node, so I can measure the duration, order, and correlation
> > of events, with extremely good precision.
> >
> > A+
> > Osvaldo
> >> David Holmes wrote:
> >>
> >>> I always come back to wondering why you need a high
> resolution value that is
> >>> tied to wall-clock time?
> >>>
> >> Convenience. Why do we need multiple clocks, why can't we have
> a single
> >> clock with nanosecond precision? Well we could if every computer was
> >> fitted with an atomic clock. So we have multiple clocks
> because that is
> >> easier to implement with available hardware. Yet a single high
> >> resolution clock synchronized to real time does appear to be possible
> >> (that appears to be what I get on the latest Ubuntu). Using the
> >> techniques applied by NTP it would also seem possible to synchronize
> >> System.nanoTime() to real time to provide typically microsecond
> >> resolution and a delta from real time kept below 0.1s or better.
> >>
> >> If you are an engineer familiar with the internal implementation, you
> >> will be happy to choose an appropriate clock for each purpose. Other
> >> people just want THE time, and don't bother them with all
> those details,
> >> UTC, UT1, NTP, HPET, TSC, ... Nor are they very understanding
> about why
> >> they can't have (sub)microsecond resolution when the processors have
> >> clock rates in the GHz.
> >>
> >> ;-)
> >>
> >> Mark Thornton
> >>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at altair.cs.oswego.edu
> >> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>
> >>
> >
> >
> > --
> > -----------------------------------------------------------------------
> > Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
> > osvaldo at visionnaire.com.br                http://www.visionnaire.com.br
> > Arquiteto de Tecnologia                          +55 (41) 337-1000 #223
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at altair.cs.oswego.edu
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>