| 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.
