Quoting from David Holme's blog: > The nanoTime method uses the highest resolution clock available on the > platform, and while its return value is in nanoseconds, the update resolution > is typically only microseconds. https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks
I think we can rely on nanoTime as a clock with microsecond resolution. Having said that can't we say printing out nanoTime in websocket message handler will give us a fair number (with microsecond accuracy) to measure how quickly the message handler is being called? All I am saying is that I see an obvious hiccup in order of milliseconds when threads are switching which I have no explanation for. Please advise if you think the way I am measuring is wrong. Cheers Farzad On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dcker...@verizon.net> wrote: > On 10/31/2015 10:51 AM, David Balažic wrote: >> >> Just a note: When most of you say "resolution" what you think about is >> actually called "accuracy". >> (also see "precision" , here is a good roundup: >> http://www.tutelman.com/golf/measure/precision.php ) > > > I'm not sure about the others, but as an Electrical Engineer, I know the > difference between resolution, precision, and accuracy. In the post I made > earlier, I said and meant "resolution". > > > > >> >> David Balažic >> Software Engineer >> www.comtrade.com >> >>> -----Original Message----- >>> From: Konstantin Preißer [mailto:kpreis...@apache.org] >>> Sent: 31. October 2015 10:27 >>> To: Tomcat Users List >>> Subject: [OT] RE: 80ms delay switching between worker threads >>> Importance: Low >>> >>> Hi Christopher, >>> >>>> -----Original Message----- >>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >>>> Sent: Saturday, October 31, 2015 3:43 AM >>>> >>>> What OS are you using? IIRC, the Windows timer has horrible resolution. >>>> you can call System.currentTimeNanos all you want, but you won't get >>>> anything meaningful lower than some threshold regardless of the actual >>>> least significant digits coming back from those calls. >>> >>> >>> While that may have been true in ancient versions like XP and Vista, at >>> least >>> starting with Win7 QueryPerformanceCounter() uses the processor's TSC [1] >>> (where Vista used the HPET if available) so you should have a very high >>> resolution here. E.g. running the following Java program: >>> >>> int[] iterations = { 100, 120, 150, 250 }; >>> >>> for (int i = 0; i < iterations.length; i++) { >>> for (int j = 0; j < 3; j++) { >>> long currentTime = System.nanoTime(); >>> double startValue = 1000; >>> for (int z = 0; z < iterations[i]; z++) { >>> startValue = Math.pow(startValue, 0.99); >>> } >>> long difference = System.nanoTime() - currentTime; >>> System.out.println(iterations[i] + " pow iterations ms took >>> " + >>> (difference / 1000L) + " µs"); >>> } >>> } >>> >>> prints on my system something like: >>> >>> 100 pow iterations ms took 25 µs >>> 100 pow iterations ms took 7 µs >>> 100 pow iterations ms took 7 µs >>> 120 pow iterations ms took 8 µs >>> 120 pow iterations ms took 9 µs >>> 120 pow iterations ms took 8 µs >>> 150 pow iterations ms took 11 µs >>> 150 pow iterations ms took 10 µs >>> 150 pow iterations ms took 13 µs >>> 250 pow iterations ms took 18 µs >>> 250 pow iterations ms took 17 µs >>> 250 pow iterations ms took 17 µs >>> >>> >>> So there should at least be a microsecond resolution. On a C# program >>> using >>> Stopwatch I get similar results in the range from 5 to 12 µs. >>> >>> Note, QueryPerformanceFrequency() [2] can be used to get the frequency >>> of the timer which is exposed in .Net through static >>> System.Diagnostics.Stopwatch.Frequency field as ticks per second. On my >>> system it prints "3323580" so the resolution should be around ~0.3 >>> microseconds. >>> >>> >>> Regards, >>> Konstantin Preißer >>> >>> [1] https://msdn.microsoft.com/en- >>> us/library/windows/desktop/dn553408%28v=vs.85%29.aspx >>> [2] https://msdn.microsoft.com/de- >>> de/library/windows/desktop/ms644905%28v=vs.85%29.aspx >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
