Bug #44190 | Performance schema: nanosecond and ticks timers not implemented on windows | ||
---|---|---|---|
Submitted: | 9 Apr 2009 15:17 | Modified: | 14 Jan 2010 18:03 |
Reporter: | Marc ALFF | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Performance Schema | Severity: | S3 (Non-critical) |
Version: | mysql-6.0-perf | OS: | Any |
Assigned to: | Marc ALFF | CPU Architecture: | Any |
[9 Apr 2009 15:17]
Marc ALFF
[9 Apr 2009 16:50]
Peter Gulutzan
These are good results. Let me add a few explanatory notes about the unit test display since it's public now. The "# myt....routine" numbers are translatable as: # myt.cycles_routine : MY_TIMER_ROUTINE_ASM_X86_WIN # myt.nanoseconds_routine : nothing # myt.microseconds_routine : MY_TIMER_ROUTINE_QUERYPERFORMANCECOUNTER # myt.milliseconds_routine : MY_TIMER_ROUTINE_GETTICKCOUNT # myt.ticks_routine : nothing The ASM_X86_WIN routine is of course RDTSC, specifically "__asm {rdtsc};". The "nothing" for nanoseconds is okay since Windows has no generally useful nanoseconds timer. The use of QueryPerformanceCounter and GetTickCount is okay since these are common with Windows. The "nothing" for ticks is okay because the possible choice (GetTickCount) is already used for the milliseconds routine. The cycles frequency is nearly 3.2GHz which is what I expect, since according to our page [mysql internal address]/wiki/DevelopmentMachines this machine is "Dual Intel Xeon 3.2 GHz". The microseconds frequency is also 3.2GHz, which looks silly. But QueryPerformanceCounter often has a frequency of 3.5MHz, as on my own machine, so I called it a microseconds timer even though sometimes, as here, it's ticking over at the same speed as the cycle counter. (That is: sometimes QueryPerformanceCounter will use RDTSC if it thinks it's reliable.) The milliseconds "resolution" is 15, that is, GetTickCount proceeds in jerks 15 milliseconds at a time. When "resolution" is big, it's bad. Well, that's why we show "resolution", though, so users can be aware when something is bad. A look at rdtsc3_notes.txt (attached to WL#2373) shows that these are about the same results as I got on the same machine with rdtsc3.c years ago. And rdtsc3_notes.txt shows other platforms which lack timers for some frequencies, but that's because the platform doesn't supply. We can only regard it as a flaw if if we fail to take what's supplied, and even then I didn't worry if my initial tests showed that what's supplied didn't look useful. In fact I think there may be too many choices -- "ticks" looks generally un-useful. Therefore I claim the results are okay, and the "failures" in this test should be ignored. There is another pushbuild unit test for Windows, vm-win2003-a. This one is a little worse. " # ----- Routine --------------- # myt.cycles_routine : 4 # myt.nanoseconds_routine : 0 # myt.microseconds_routine : 14 # myt.milliseconds_routine : 15 # myt.ticks_routine : 0 # ----- Frequency ------------- # myt.cycles_frequency : 2989859262 # myt.nanoseconds_frequency : 0 # myt.microseconds_frequency : 3579545 # myt.milliseconds_frequency : 1011 # myt.ticks_frequency : 0 # ----- Resolution ------------ # myt.cycles_resolution : 1 # myt.nanoseconds_resolution : 0 # myt.microseconds_resolution : 1 # myt.milliseconds_resolution : 16 # myt.ticks_resolution : 0 # ----- Overhead -------------- # myt.cycles_overhead : 1458 # myt.nanoseconds_overhead : 0 # myt.microseconds_overhead : 5031 # myt.milliseconds_overhead : 18 # myt.ticks_overhead : 0 " The routine choices are the same as for the win2003-x86, but look at that overhead. If overhead is 1458 cycles even for a cycles counter, performance schema will be too slow. I notice that the "vm" in "vm-win2003-a" stands for "VMWare", and if so perhaps we should have a note in the documentation: if you use VMware, SELECT * FROM performance_schema.PERFORMANCE_TIMERS; and look at what it says for overhead. Don't assume it's a small number just because the machine itself can do a RDTSC with low overhead. That's not a bug though, we can't make it faster. So I recommend that this be closed as "Not a bug".
[10 Apr 2009 12:42]
Peter Laursen
If I understand, I disagree with PG. If *no information* is available it is incorrect to return '0' (ZERO). NULL or a 'placeholder' like 'N/A' would be acceptable if information cannot be found due to some system/platform specific problem - but not ZERO as ZERO is *exact (and wrong) information*.
[10 Apr 2009 18:57]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/71869 2860 Marc Alff 2009-04-10 Bug#44190 Performance schema: nanosecond and ticks timers not implemented on windows Some timers may not be implemented on all platforms, and this is an expected edge condition that is not properly handled. Fixed the code for non implemented timers to: - be robust, in the timer to picosecond conversion - display NULL in PERFORMANCE_TIMERS Fixed the unit test my_rdtsc-t to handle non implemented timers.
[10 Apr 2009 21:55]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/71875 2861 Marc Alff 2009-04-10 Bug#44190 Performance schema: nanosecond and ticks timers not implemented on windows Test cleanup
[1 Jun 2009 16:53]
Marc ALFF
Queued in mysql-6.0-perfschema
[14 Jan 2010 10:01]
Marc ALFF
Merged in: - mysql-next-mr (Celosia / 5.5.99-m3) - mysql-6.0-codebase (6.0.14)
[14 Jan 2010 18:03]
Paul DuBois
Not in any released version. No changelog entry needed.