You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Konstantin Preißer <kp...@apache.org> on 2015/10/31 10:27:15 UTC
[OT] RE: 80ms delay switching between worker threads
Hi Christopher,
> -----Original Message-----
> From: Christopher Schultz [mailto:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
That's correct André. That is my point.
On Tue, Nov 3, 2015 at 8:18 AM, André Warnier (tomcat) <aw...@ice-sa.com> wrote:
> 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 there is 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 each case, 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 <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
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 there
is 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 each
case, 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 <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
Chris - I am running a mac book pro. I will try to setup a simple test
case when I get a chance and post the results.
On Wed, Nov 4, 2015 at 11:54 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Farzad,
>
> On 11/3/15 2:45 PM, Farzad Panahi wrote:
>> I wish I could get my hands on a real server : )
>
> What computer do you use to access the server? That one will certainly
> work for this kind of testing.
>
> -chris
>
>> On Mon, Nov 2, 2015 at 12:23 PM, David kerber <dc...@verizon.net> 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.
>>>
>>>
>>>
>>>>
>>>> Cheers
>>>>
>>>> Farzad
>>>>
>>>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Farzad,
On 11/3/15 2:45 PM, Farzad Panahi wrote:
> I wish I could get my hands on a real server : )
What computer do you use to access the server? That one will certainly
work for this kind of testing.
-chris
> On Mon, Nov 2, 2015 at 12:23 PM, David kerber <dc...@verizon.net> 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.
>>
>>
>>
>>>
>>> Cheers
>>>
>>> Farzad
>>>
>>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
I wish I could get my hands on a real server : )
On Mon, Nov 2, 2015 at 12:23 PM, David kerber <dc...@verizon.net> 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.
>
>
>
>>
>> Cheers
>>
>> Farzad
>>
>> On Mon, Nov 2, 2015 at 4:56 AM, David kerber <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by David kerber <dc...@verizon.net>.
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 <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by Farzad Panahi <fa...@gmail.com>.
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 <dc...@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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] RE: 80ms delay switching between worker threads
Posted by David kerber <dc...@verizon.net>.
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:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [OT] RE: 80ms delay switching between worker threads
Posted by David Balažic <da...@comtrade.com>.
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 )
David Balažic
Software Engineer
www.comtrade.com
> -----Original Message-----
> From: Konstantin Preißer [mailto:kpreisser@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:chris@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org