Hi, On Thu, Mar 6, 2014 at 5:30 PM, Tobias Bocanegra <[email protected]> wrote: > I think you need to use a higher clock-drift interval. IIUC, you > currently use 1 second. but on some machines, the > System.getTimeMillis() can be as inaccurate than 2 seconds.
The intention is to remain in sync with currentTimeMillis() without any big jumps, which is why the sync interval is intentionally pretty small. > however, since a long can hold up to more than 200 years of > nano-seconds, I don't think we need an accurate system time > measurement for the benchmarks. and I wouldn't use > System.getTimeMillis() at all. We need the wall clock time for SessionMBean. Also, since the Fast clock can by design only achieve up to millisecond accuracy (unless we want to use a dedicated thread for timekeeping), we might as well use the wall clock time instead of potentially more accurate interval timings. > also, using a background task, that executes every MS is IMO a overhead. Yes, but since it's a background task it won't block any client code. The CPU overhead is also pretty low, much lower than calling the same currentTimeMillis()/nanoTime() methods repeatedly in each SessionDelegate.perform(). If this overhead does show up in a benchmark, reducing the execution frequency should be fine as it would only further reduce the accuracy of the gathered timing statistics. BR, Jukka Zitting
