[POLL] System.currentTimeMillis()

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[POLL] System.currentTimeMillis()

Jörg Schaible
Hi folks,

I have written a generator for commons-id, that is based in the end on the
system clock. Unfortunately I have sporadic failures in Gump that I cannot
explain. I developed this on a Windows box, but had now a chance for a test
with Linux. Suddenly I have also sporadic failing tests. First I thought my
algorithm is flawed, but then I wrote this little unit test:

   
    public void testSystemTimeIsIncreasing() {
        long last = System.currentTimeMillis();
        for (int i = 0; i < 50000; i++) {
            long now = System.currentTimeMillis();
            assertTrue("Iteration " + i,  now >= last);
            last = now;
        }
    }


Believe it or not, this test will quite always fail within the first 10000
iterations on my Linux box. So how does this test behave on your boxes?
Please also note OS and JDK ...

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gump & VM (was: [POLL] System.currentTimeMillis())

Jörg Schaible
Jörg Schaible wrote:

> Hi folks,
>
> I have written a generator for commons-id, that is based in the end on the
> system clock. Unfortunately I have sporadic failures in Gump that I cannot
> explain. I developed this on a Windows box, but had now a chance for a
> test with Linux. Suddenly I have also sporadic failing tests. First I
> thought my algorithm is flawed, but then I wrote this little unit test:
>
>    
>     public void testSystemTimeIsIncreasing() {
>         long last = System.currentTimeMillis();
>         for (int i = 0; i < 50000; i++) {
>             long now = System.currentTimeMillis();
>             assertTrue("Iteration " + i,  now >= last);
>             last = now;
>         }
>     }
>
>
> Believe it or not, this test will quite always fail within the first 10000
> iterations on my Linux box. So how does this test behave on your boxes?
> Please also note OS and JDK ...

OK, I can analyse the situation. My current box was not totally synchronized
and I had a daemon running, that adjusted the time smoothly. After compete
synchronization the tests passes. Nevertheless, this does not solve the
Gump problem, since I know, that they have often problems with the system
time (we had last week one VM where 1 second exactly took 2 real ones). So
what can we do?

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Filip Defoort
In reply to this post by Jörg Schaible
Hi Joerg,

I just tried it on my box (linux, suse 9.3, 2.6.11.4-21.9-smp
kernel) and I don't have a problem; I did slightly modify the
test to run it standalone:

public class Test {

public static final void main(String[] args) throws Exception {
        long last = System.currentTimeMillis();
        System.out.println("start is " + last);

        for (int i = 0; i < 50000; i++) {
            long now = System.currentTimeMillis();
            assert(now >= last);
            last = now;
        }

        System.out.println("end is " + last);
    }

}

Cheers,
- Filip


> Hi folks,
>
> I have written a generator for commons-id, that is based in the end on the
> system clock. Unfortunately I have sporadic failures in Gump that I cannot
> explain. I developed this on a Windows box, but had now a chance for a
> test
> with Linux. Suddenly I have also sporadic failing tests. First I thought
> my
> algorithm is flawed, but then I wrote this little unit test:
>
>
>     public void testSystemTimeIsIncreasing() {
>         long last = System.currentTimeMillis();
>         for (int i = 0; i < 50000; i++) {
>             long now = System.currentTimeMillis();
>             assertTrue("Iteration " + i,  now >= last);
>             last = now;
>         }
>     }
>
>
> Believe it or not, this test will quite always fail within the first 10000
> iterations on my Linux box. So how does this test behave on your boxes?
> Please also note OS and JDK ...
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Jason H King
Several runs on Windows 2k sp 5.00.2195 worked correctly for me.
H:\>java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b03)
Java HotSpot(TM) Client VM (build 1.5.0_05-b03, mixed mode)
[hidden email] wrote:

>Hi Joerg,
>
>I just tried it on my box (linux, suse 9.3, 2.6.11.4-21.9-smp
>kernel) and I don't have a problem; I did slightly modify the
>test to run it standalone:
>
>public class Test {
>
>public static final void main(String[] args) throws Exception {
>        long last = System.currentTimeMillis();
>        System.out.println("start is " + last);
>
>        for (int i = 0; i < 50000; i++) {
>            long now = System.currentTimeMillis();
>            assert(now >= last);
>            last = now;
>        }
>
>        System.out.println("end is " + last);
>    }
>
>}
>
>Cheers,
>- Filip
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Leo Sutic
In reply to this post by Jörg Schaible
Do you run ntpd or some other clock-syncing program?

/LS

On 12/14/05, Jörg Schaible <[hidden email]> wrote:

> Hi folks,
>
> I have written a generator for commons-id, that is based in the end on the
> system clock. Unfortunately I have sporadic failures in Gump that I cannot
> explain. I developed this on a Windows box, but had now a chance for a test
> with Linux. Suddenly I have also sporadic failing tests. First I thought my
> algorithm is flawed, but then I wrote this little unit test:
>
>
>    public void testSystemTimeIsIncreasing() {
>        long last = System.currentTimeMillis();
>        for (int i = 0; i < 50000; i++) {
>            long now = System.currentTimeMillis();
>            assertTrue("Iteration " + i,  now >= last);
>            last = now;
>        }
>    }
>
>
> Believe it or not, this test will quite always fail within the first 10000
> iterations on my Linux box. So how does this test behave on your boxes?
> Please also note OS and JDK ...
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Dakota Jack
In reply to this post by Jörg Schaible
You are assuming that there will be a time difference in millis between the
two time calls.  System.currentTimeMillis() takes a relatively long time to
return.  So, I would not trust that assumption.

On 12/14/05, Jörg Schaible <[hidden email]> wrote:

>
> Hi folks,
>
> I have written a generator for commons-id, that is based in the end on the
> system clock. Unfortunately I have sporadic failures in Gump that I cannot
> explain. I developed this on a Windows box, but had now a chance for a
> test
> with Linux. Suddenly I have also sporadic failing tests. First I thought
> my
> algorithm is flawed, but then I wrote this little unit test:
>
>
>     public void testSystemTimeIsIncreasing() {
>         long last = System.currentTimeMillis();
>         for (int i = 0; i < 50000; i++) {
>             long now = System.currentTimeMillis();
>             assertTrue("Iteration " + i,  now >= last);
>             last = now;
>         }
>     }
>
>
> Believe it or not, this test will quite always fail within the first 10000
> iterations on my Linux box. So how does this test behave on your boxes?
> Please also note OS and JDK ...
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Reply | Threaded
Open this post in threaded view
|

RE: [POLL] System.currentTimeMillis()

Jörg Schaible-2
In reply to this post by Jörg Schaible
Dakota Jack wrote on Thursday, December 15, 2005 7:01 AM:

> You are assuming that there will be a time difference in millis
> between the two time calls. System.currentTimeMillis() takes a
> relatively long time to return.  So, I would not trust that
> assumption.

No, I just assume that the millis are the same or greater. This implies that the clock does not walk backwards (or you hit the millis overflow when running the test).

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [POLL] System.currentTimeMillis()

Jörg Schaible-2
In reply to this post by Jörg Schaible
Leo Sutic wrote on Wednesday, December 14, 2005 10:56 PM:

> Do you run ntpd or some other clock-syncing program?

Yes, it was indeed the cause, see my other mail.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Re: Gump & VM (was: [POLL] System.currentTimeMillis())

Jörg Schaible-2
In reply to this post by Jörg Schaible
Jörg Schaible wrote on Wednesday, December 14, 2005 10:14 PM:

> Jörg Schaible wrote:
>
>> Hi folks,
>>
>> I have written a generator for commons-id, that is based in the end
>> on the system clock. Unfortunately I have sporadic failures in Gump
>> that I cannot explain. I developed this on a Windows box, but had
>> now a chance for a test with Linux. Suddenly I have also sporadic
>> failing tests. First I thought my algorithm is flawed, but then I
>> wrote this little unit test:
[snip]

>
> OK, I can analyse the situation. My current box was not
> totally synchronized
> and I had a daemon running, that adjusted the time smoothly.
> After compete
> synchronization the tests passes. Nevertheless, this does not
> solve the
> Gump problem, since I know, that they have often problems
> with the system
> time (we had last week one VM where 1 second exactly took 2
> real ones). So
> what can we do?

Since Gump runs in a VM and the VMs have much more problems synching the clock, I might rewrite the tests, so they are only executed if the clock is reliable. OTOH any app using the class in a VM may run into troubles also (despite the Javadoc, that already has such a hint). I should probably log a warning if the class detects such a situation ... or decrease the time resolution :-/

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gump & VM

Chr. Grobmeier
In reply to this post by Jörg Schaible
 > So what can we do?

I read about timers in the book "killer game programming in java" :-),
where this things are important. Maybe this is a direction for you.

Use the following instead of System.currentTimeMillis():

1) Suns undocumented Class (Java2): sun.misc.Perf

2) Java 5: System.nanoTime()

This two have a higher resolution than currentTimeMillis() and could help.

Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Gump & VM

Jörg Schaible-2
C. Grobmeier wrote on Thursday, December 15, 2005 9:46 AM:

>  > So what can we do?
>
> I read about timers in the book "killer game programming in java" :-),
> where this things are important. Maybe this is a direction for you.
>
> Use the following instead of System.currentTimeMillis():
>
> 1) Suns undocumented Class (Java2): sun.misc.Perf

Non-portable

> 2) Java 5: System.nanoTime()

Not JDK 1.3 compatible as the rest of the classes in id

> This two have a higher resolution than currentTimeMillis()
> and could help.

And I doubt that it will help if the OS (or an appropriate daemon task) is manipulating the system clock. The problem is not too *less* resolution, it is too *much* - at least with daemons adjusting system time smoothly. Descreasing the resolution means, that the code might not be affected if such a daemon shifts the system time by some millis into the past.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Gump & VM

Martin van den Bemt
Does a Thread.sleep(1) or something similar maybe help ?

Mvgr,
Martin

Jörg Schaible wrote:

> C. Grobmeier wrote on Thursday, December 15, 2005 9:46 AM:
>
>
>> > So what can we do?
>>
>>I read about timers in the book "killer game programming in java" :-),
>>where this things are important. Maybe this is a direction for you.
>>
>>Use the following instead of System.currentTimeMillis():
>>
>>1) Suns undocumented Class (Java2): sun.misc.Perf
>
>
> Non-portable
>
>
>>2) Java 5: System.nanoTime()
>
>
> Not JDK 1.3 compatible as the rest of the classes in id
>
>
>>This two have a higher resolution than currentTimeMillis()
>>and could help.
>
>
> And I doubt that it will help if the OS (or an appropriate daemon task) is manipulating the system clock. The problem is not too *less* resolution, it is too *much* - at least with daemons adjusting system time smoothly. Descreasing the resolution means, that the code might not be affected if such a daemon shifts the system time by some millis into the past.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Gump & VM

Jörg Schaible-2
In reply to this post by Chr. Grobmeier
Hi Martin,

> Jörg Schaible wrote:
>> And I doubt that it will help if the OS (or an appropriate
>> daemon task) is manipulating the system clock. The problem is
>> not too *less* resolution, it is too *much* - at least with
>> daemons adjusting system time smoothly. Descreasing the
>> resolution means, that the code might not be affected if such
>> a daemon shifts the system time by some millis into the past.

Martin van den Bemt wrote on Thursday, December 15, 2005 10:15 AM:

> Does a Thread.sleep(1) or something similar maybe help ?

Well, no, the id generator should produce as many ids as possible. The only requirement for this one is, that you can recreate the time from the generated id and that the ids are generated in a natural order. This is currently resolved by an internal counter that is resetted everytime the current millis have changed. Decreasing the timer resolution to e.g. seconds means, that this internal counter can get quite big or may even overflow and that the creation time is not that accurate to recalculate. The current implementation works quite optimal for a non-time-shifting environment. But if time shifts into the past happen, the natural order requirement is violated (and detected by the unit tests) ... must think over it some more time ...

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Antonio Gallardo
In reply to this post by Jörg Schaible
Jörg Schaible wrote:

>Hi folks,
>
>I have written a generator for commons-id, that is based in the end on the
>system clock. Unfortunately I have sporadic failures in Gump that I cannot
>explain. I developed this on a Windows box, but had now a chance for a test
>with Linux. Suddenly I have also sporadic failing tests. First I thought my
>algorithm is flawed, but then I wrote this little unit test:
>
>    
>    public void testSystemTimeIsIncreasing() {
>        long last = System.currentTimeMillis();
>        for (int i = 0; i < 50000; i++) {
>            long now = System.currentTimeMillis();
>            assertTrue("Iteration " + i,  now >= last);
>            last = now;
>        }
>    }
>
>
>Believe it or not, this test will quite always fail within the first 10000
>iterations on my Linux box. So how does this test behave on your boxes?
>Please also note OS and JDK ...
>  
>

Jörg,

Can the StopWatch class in commons-lang help?

http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/time/StopWatch.java?view=markup

I am just thinking that this nice research is also useful for reviewing
the StopWatch class too.

Best Regards,

Antonio Gallardo.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [POLL] System.currentTimeMillis()

Jörg Schaible-2
In reply to this post by Jörg Schaible
Hi Antonio,

Antonio Gallardo wrote on Thursday, December 15, 2005 10:53 AM:
[snip]
>
> Jörg,
>
> Can the StopWatch class in commons-lang help?
>
> http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/lang/
> trunk/src/java/org/apache/commons/lang/time/StopWatch.java?view=markup

Not really, since its implementation suffers also from such a time-shifting daemon.
 
> I am just thinking that this nice research is also useful for
> reviewing the StopWatch class too.

I am quite sure, that a unit test ensuring that StopWatch.getTime() never returns a negative number can be written so that it will fail in our Gump environment. But I doubt, that the StopWatch implementation can or should really do something about it.

I wonder which other classes may be affected by such time shifts also. I never really took that into account previously (although I was aware of the problem writing the time based id generator). Since it gets quite common that applications run in VMs (especially if a company uses the VMWare servers), the problem might arise more often in future ...

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Dakota Jack
In reply to this post by Jörg Schaible-2
Right!  Sorry!

On 12/15/05, Jörg Schaible <[hidden email]> wrote:

>
> Dakota Jack wrote on Thursday, December 15, 2005 7:01 AM:
>
> > You are assuming that there will be a time difference in millis
> > between the two time calls. System.currentTimeMillis() takes a
> > relatively long time to return.  So, I would not trust that
> > assumption.
>
> No, I just assume that the millis are the same or greater. This implies
> that the clock does not walk backwards (or you hit the millis overflow when
> running the test).
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Dakota Jack
In reply to this post by Jörg Schaible-2
What other "mail" are you talking about Jorg?

On 12/15/05, Jörg Schaible <[hidden email]> wrote:

>
> Leo Sutic wrote on Wednesday, December 14, 2005 10:56 PM:
>
> > Do you run ntpd or some other clock-syncing program?
>
> Yes, it was indeed the cause, see my other mail.
>
> - Jörg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Jörg Schaible
Dakota Jack wrote:

> What other "mail" are you talking about Jorg?

Topic: Gump & VM

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [POLL] System.currentTimeMillis()

Boris Unckel-2
In reply to this post by Jörg Schaible
Hi Joerg,

this is an absolutely "normal" behaviour. It does not depend
on the operating system, but more on system speed.
Your CPU has enough power to calculate n-thousand additions
in one milli second.
It is not predictable, since it depends on the machine in use.

I have found this in an other context:
Random  r1 = new Random(); //depends on System.currentMillis()

If you have the need to randomize more than one number (and cannot
rely on the same random object) you need one random for the seed,
and one random for the number generating:

private static final Random RANDOM_FOR_SEED = new Random();
//....
public int generateRandomInt(){
 Random localRandom = new Random(RANDOM_FOR_SEED.nextLong());
 return localRandom.nextInt(100);
}

Regards
Boris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re[2]: Gump & VM

Alexey Panchenko
In reply to this post by Jörg Schaible-2
Jörg Schaible wrote:

> Well, no, the id generator should produce as many ids as possible.
> The only requirement for this one is, that you can recreate the time
> from the generated id and that the ids are generated in a natural
> order. This is currently resolved by an internal counter that is
> resetted everytime the current millis have changed.

Probably you should look at java.rmi.server.UID -- the millis are
checked only when internal counter reaches its limit.

--
Best regards,
 Alexey                            mailto:[hidden email]
12