Re: [OT] RE: 80ms delay switching between worker threads

tomcat Tue, 03 Nov 2015 08:19:35 -0800

On 02.11.2015 21:23, David kerber wrote:

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.

I am no specialist in the matter, but I believe that what the OP is saying, is that thereis a clear and systematic difference between 2 cases :

- when the threads are switching
- versus when they are not switching

If so, and assuming that his measurements use the same method and instruments in eachcase, statistically-speaking there would still be an as yet unexplained difference, no ?

(even if it is only a blink of an eye, repeated blinks can amount to something 
significant)


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

Re: [OT] RE: 80ms delay switching between worker threads

Reply via email to