Re: [OT] RE: 80ms delay switching between worker threads
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 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 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 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 }; >>>>>>> >>>>>>>
Re: [OT] RE: 80ms delay switching between worker threads
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 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 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; >>>>>>
Re: [OT] RE: 80ms delay switching between worker threads
That's correct André. That is my point. On Tue, Nov 3, 2015 at 8:18 AM, André Warnier (tomcat) 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 >>> 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
Re: [OT] RE: 80ms delay switching between worker threads
I wish I could get my hands on a real server : ) On Mon, Nov 2, 2015 at 12:23 PM, 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. > > > >> >> Cheers >> >> Farzad >> >> On Mon, Nov 2, 2015 at 4:56 AM, David kerber 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 ite
Re: [OT] RE: 80ms delay switching between worker threads
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 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
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 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
Re: [OT] RE: 80ms delay switching between worker threads
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 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
Re: [OT] RE: 80ms delay switching between worker threads
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
RE: [OT] RE: 80ms delay switching between worker threads
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: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
[OT] RE: 80ms delay switching between worker threads
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