[concurrency-interest] High resolution timers and JSR 310
jmanson at cs.umd.edu
Mon May 19 19:24:56 EDT 2008
Well, in our case, we actually didn't want that; we just wanted
something that was cheap to execute. Both System.nanoTime() and
System.currentTimeMillis() are CPU hogs on Linux, and this approach
solved that problem. I was thinking that a similar approach could be
used to solve the other problem (I'm sure it would be much more
expensive). However, if it isn't worth solving the problem, then it
sounds like it wouldn't be a very valuable use of anyone's time.
David Holmes wrote:
> There are no doubt techniques for trying to synchronize two clock sources.
> It becomes an issue of the cost involved and the accuracy achievable. I
> don't claim to know what these techniques are nor how to characterise their
> I always come back to wondering why you need a high resolution value that is
> tied to wall-clock time? A timestamp that simply needs to look similar to
> wall-clock time does not need to be synchronized with wall-clock time after
> startup. And a timestamp that is guaranteed monotonic increasing is far more
> useful than one that is not.
>> -----Original Message-----
>> From: Jeremy Manson [mailto:jmanson at cs.umd.edu]
>> Sent: Tuesday, 20 May 2008 8:10 AM
>> To: dholmes at ieee.org
>> Cc: Osvaldo Pinali Doederlein; Kasper Nielsen; concurrency-interest
>> Subject: Re: [concurrency-interest] High resolution timers and JSR 310
>> When I tried to implement a high speed timer based on the cycle counter
>> on Linux, I had some luck with reading the cycle counter every few
>> seconds and coordinating that with the actual time (repeating the
>> coordination until you were sure that it was accurate to within a given
>> interval by checking the cycle counter both before and after the check
>> of the current time).
>> Then, when people actually wanted the time, we could base it off of the
>> cycle counter (base_time + cycles_since_base_time *
>> number_of_cycles_per_unit_of_time). It was lightning-fast, compared to
>> currentTimeMillis and nanoTime on Linux.
>> The problem was that this wasn't high-precision (or even particularly
>> accurate), because of clock drift and the fact that the cycle counter
>> can be different on different processors. Could something like this
>> that could be done with clock_gettime() instead of the cycle counter?
>> David Holmes wrote:
>>> As Kasper alluded the problem is that the OS doesn't
>> necessarily give you a
>>> high-precision time source that is tied to "wall clock time". Hence on
>>> Windows the update resolution is typically 10ms (15ms for some
>> versions), on
>>> Solaris/Linux it is also typically 10ms but can be 1ms
>> depending on system
>>> nanoTime doesn't use JVM tricks to get better resolution, it uses a
>>> completely different time-source to currentTimeMillis - such as TSC
>>> (rarely), HPET or ACPI Power Management timer - exposed via
>> some specific OS
>>> API such as QueryPerformanceCounter/QueryPerformanceFrequency
>> on Windows;
>>> gethrtime() on Solaris and clock_gettime(CLOCK_MONOTONIC) on
>> linux. These
>>> higher resolution time sources are not tied to wall-clock time.
>>> See my blog for some details on Windows:
>>> Trying to get a high resolution time source that is tied to changes in
>>> wall-clock time will be a real problem to implement as you would have to
>>> effectively synchronize the two different time sources in some way. This
>>> would be far from trivial.
>>> What you can do is to define the high resolution clock to be
>> based on the
>>> epoch, but not require that subsequent changes in system time
>> be reflected
>>> in the value. The real-time spec for Java does this for its
>> real-time clock
>>> source. For this all you have to do is determine the system time at VM
>>> startup and then return a (base + offset) value. Would that
>> suffice or must
>>> ntp adjustments and DST changes also be reflected?
>>> David Holmes
>>>> -----Original Message-----
>>>> From: concurrency-interest-bounces at cs.oswego.edu
>>>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Osvaldo
>>>> Pinali Doederlein
>>>> Sent: Monday, 19 May 2008 12:25 AM
>>>> To: Kasper Nielsen
>>>> Cc: concurrency-interest
>>>> Subject: Re: [concurrency-interest] High resolution timers and JSR 310
>>>> I understand the problem, but I wonder if an alternative solution would
>>>> be feasible, like a millisecond-precision timing that's actually
>>>> millisecond-accurate (instead of the current APIs currentTimeMillis(),
>>>> new Date() etc., that update values only each ~16ms, at least in the
>>>> implementations where I tested this). Right now I am forced to write a
>>>> hacked utility class that emulates System.currentTimeMillis()
>>>> its epoch - so the value can be used to create dates), but relying on
>>>> currentTimeNanos(), and I patch libraries like Log4J because my
>>>> application logs ABSOLUTELY require 1ms-accurate timestamps in
>> the logs.
>>>> 16ms is not good enough in modern multi-GHz / multicore systems, when I
>>>> want to collect performance data from logs and even a simple query in
>>>> Oracle runs in ~2ms. Even with 1ms accuracy, I observe dozens of
>>>> application operations executing in the same timestamp; but that's good
>>>> enough (for the time being) as any operation taking <1ms is fast enough
>>>> so I don't care.
>>>> Perhaps we could reimplement currentTimeMillis() with the same JVM
>>>> tricks used by the nano timer (intrinsification), so we can
>> get at least
>>>> 1ms accuracy, without the risks imposed by additional techniques
>>>> required for nanosecond timers.
>>>>> There is some ongoing talk about adding a high resolution timer
>>>>> System.currentTimeNanos() over at JSR 310. Which acts just like
>>>>> System.currentTimeMillis() but with nanosecond resolution.
>>>>> In my opinion this is practically impossible to implement correctly
>>>>> without proper os/hardware support. For example, using combinations of
>>>>> QueryPerformanceCounter and GetSystemTimeAsFileTime on
>> Windows is just a
>>>>> disaster waiting to happen.
>>>>> Maybe someone on this list has some input.
>>>>> - Kasper
>>>>> Concurrency-interest mailing list
>>>>> Concurrency-interest at altair.cs.oswego.edu
>>>> 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
>>> Concurrency-interest mailing list
>>> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest