AFAIK, this is expected, on Windows (or some Windows versions), System.currentTimeMillis() only has a resolution of 15ms
http://stackoverflow.com/questions/7859019/system-currenttimemillis-is-not-accurate-on-windows-xp Cheers, Alex > On 19.03.2015, at 09:11, Julian Reschke <[email protected]> wrote: > > So, > > as they plague the new Jenkins build and they also occur sometimes over here, > I spent some time with them... > > 1) There was a single test for all of the clocks (simple, accurate, fast); I > have refactored these so that they execute separately. > > 2) Most of the failures seem to be related to Clock.Fast. This is a clock > that relies on Clock.ACCURATE and a regular (10ms) update from that clock. At > least on my platform, I can see that if the updates occur, they actually > happen every 15ms (not 10ms). > > Thoughts: > > - we need to find out whether the actual code fails, or whether it's a > problem in the test case > > - Relying on a scheduled thread to be executed in precise intervals seems > like asking for trouble > > - As far as I can tell, the reason why we even have Clock.Fast is the > assumption that Clock.SIMPLE (== System.currentTimeMillis()) may be "slow". > Does anybody know what exactly is the problem? (Because, after all, the > simplest possible fix would be to get rid of this apparently fragile code) > > Best regards, Julian
