currentTimeMillis

[Aaron Fude]

Hi,

Time to satisfy my curiosity. The output of the following program
public static void main(String[] inArgv) {
int N = 1000000;
long[] times = new long[N];

for (int i = 0; i < N; i++)
times = System.currentTimeMillis();

for (int i = 0; i < 10; i++)
System.out.println(times[i*(N/10)]);
}

....is

1085719861549
1085719861559
1085719861569
1085719861580
1085719861590
1085719861600
1085719861610
1085719861620
1085719861620
1085719861630

It seems that the java clock ticks in 10's of milliseconds. Is there
anything interesting anyone can say about this?

Aaron Fude

 

[Elie De Brauwer]

Hi,

Time to satisfy my curiosity. The output of the following program
public static void main(String[] inArgv) {
int N = 1000000;
long[] times = new long[N];

for (int i = 0; i < N; i++)
times = System.currentTimeMillis();

for (int i = 0; i < 10; i++)
System.out.println(times[i*(N/10)]);
}

...is

1085719861549
1085719861559
1085719861569
1085719861580
1085719861590
1085719861600
1085719861610
1085719861620
1085719861620
1085719861630

It seems that the java clock ticks in 10's of milliseconds. Is there
anything interesting anyone can say about this?

Aaron Fude

Well, I can't but the api can ;-), see
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#currentTimeMillis()

Where there is stated:
"Returns the current time in milliseconds. Note that while the unit of
time of the return value is a millisecond, the granularity of the value
depends on the underlying operating system and may be larger. For example,
many operating systems measure time in units of tens of milliseconds."

On my GNU/Linux box I get the following output:
1085720831892
1085720831968
1085720832038
1085720832108
1085720832177
1085720832247
1085720832317
1085720832387
1085720832457
1085720832527

And if I alter the for loop I can output any individual tick.

hth

--
Elie De Brauwer
http://www.de-brauwer.be

No animals were hurt and no microsoft products were used during the
creation of this e-mail

 

[Frank]

This is an OS issue... AFAIKT, most OSs will cache the currentTimeMillis()
so that repeated calls won't slow down while the system checks with the
RTC. On windows, the timing resolution is around 10ms... I think I've
heard Linux folks claim they can adjust the default to be as sensative as
1 ms.

Hope this helps!

Frank

 

[Roedy Green]

It seems that the java clock ticks in 10's of milliseconds. Is there
anything interesting anyone can say about this?

Java can't do anything about the granularity of the underlying system
clock.

The original PC's used a very crude tick timer where a tick is
65536/1193180 sec : 18.2065 per second.

I don't know if newer models are now using a more accurate clock.

 

[Chris Uppal]

1085719861549
1085719861559
1085719861569
1085719861580
1085719861590
1085719861600
1085719861610
1085719861620
1085719861620
1085719861630

It seems that the java clock ticks in 10's of milliseconds. Is there
anything interesting anyone can say about this?

You must have a very slow machine for it to take 10 milliseconds for each
iteration of such a simple loop.

;-)

-- chris

 

[Lee Fesperman]

Java can't do anything about the granularity of the underlying system
clock.

The original PC's used a very crude tick timer where a tick is
65536/1193180 sec : 18.2065 per second.

I don't know if newer models are now using a more accurate clock.

Actually, it's the way Microsoft programs the clock. The clocks on PC's provide sub-ms
granularity. I know, I wrote a real-time operating system that ran with DOS and
reprogrammed the clock to under a ms. It then interrupted DOS at the interval it
expected.

 

[Aaron Fude]

You must have a very slow machine for it to take 10 milliseconds for each
iteration of such a simple loop.

;-)

Oh yeah? Aren't I printing out every 100000th iteration?

 

[Tony Morris]

It seems that the java clock ticks in 10's of milliseconds. Is there

anything interesting anyone can say about this?

Hint: Microsoft Windows
Bigger Hint: API Specification
Further Reference: http://www.google.com

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

If you want something with very fine resolution consider the RDTSC
instruction and some JNI.

Somebody surely has cooked up the trivial JNI to access it. If not,
I'll do it for $25 US.

The problem is there is high overhead to the JNI call.

 

[Liz]

I believe the resolution of time used in NTP is
something like 128 picoseconds. Maybe we
should be using that. Actually, I don't know what
the meaning of 'java click ticks' is, normally I
think about hardware and ticks, not software and ticks.

 

[Roedy Green]

If you want something with very fine resolution consider the RDTSC
instruction and some JNI.

Somebody surely has cooked up the trivial JNI to access it. If not,
I'll do it for $25 US.

see the spec for the class at
http://mindprod.com/projects/pentium.html

It does RDTSC, cpuid, and cpuserno.

 

[Chris Uppal]

Oh yeah? Aren't I printing out every 100000th iteration?

tsk, tsk... Yes, I missed the [i*(N/10)] in the println(). <grovel/>

-- chris

 

[Roedy Green]

see the spec for the class at
http://mindprod.com/projects/pentium.html

The Pentium specific JNI code is now written and working. I need to
package it for distribution with some docs.

Basically it has methods to get you the cpuId fields, the brand name,
the RDTSC, and the cpu serial number. I can't test that last function
since I have an AMD cpu.

The biggest problem was the lack of docs on how C++ inline assembler
worked.

I never did figure out how to write something like

mov byte ptr someintvar,0

So I arranged the code so I would never have to.

 

[Roedy Green]

You can download the code to implement the Pentium CPUID, Serial
number and RDTSC high res timeer from
http://mindprod.com/products.html#PENTIUM

 

[Mark Thornton]

There already is one.
It's called java.lang.System#currentTimeMillis()

I don't know what duplicating the core API will achieve.

As noted earlier in this thread the resolution provided by
System.currentTimeMillis is variable and particularly poor on some
versions of Windows (~55ms for Windows 9x and ME, typically 10ms for NT,
2000, XP on single processors and usually 15.625ms for dual processor
machines). In JDK 1.5 (now at beta2) a new method System.nanoTime has
been added which offer much greater resolution, but is not synchronized
to UTC time in any way.

Mark Thornton

 

[Roedy Green]

There already is one.
It's called java.lang.System#currentTimeMillis()

I don't know what duplicating the core API will achieve.

I don't think currentTimeMillis uses RDTSC otherwise you would not see
such coarse resolution. In any case, the source code to use RDTSC is
now posted. See http://mindprod.com/products.html#PENTIUM

 

[P.Hill]

In JDK 1.5 (now at beta2) a new method System.nanoTime has
been added which offer much greater resolution, but is not synchronized
to UTC time in any way.

Note that the contract on that also may only change every 20 nanos
or even less often.

"This method provides nanosecond precision, but not necessarily
nanosecond accuracy. No guarantees are made about how frequently
values change."

-Paul

 

[Liz]

Note that the contract on that also may only change every 20 nanos
or even less often.

"This method provides nanosecond precision, but not necessarily
nanosecond accuracy. No guarantees are made about how frequently
values change."

-Paul

They probably round up from picoseconds.