On 11/2/2015 3:09 PM, Farzad Panahi wrote:
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.
I'm with Chris on this one: I think it's due to running on a VM rather
than on real hardware.
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
