This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 55051 - One initial calibration not enough on notebooks with CPU changing frequency
Summary: One initial calibration not enough on notebooks with CPU changing frequency
Status: CLOSED FIXED
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: Jiri Sedlacek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-16 13:20 UTC by Antonin Nebuzelsky
Modified: 2007-03-14 09:42 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2005-02-16 13:20:01 UTC
On a notebook with power saving features turned
on, especially with CPU changing frequency (e.g.
Intel SpeedStep) the initial profiler calibration
may measure and store different numbers than the
right ones which should be used when the user
starts profiling.

On my notebook with Pentium M 1.7GHz I measured
the following numbers when I repeated calibration
three times for the highest and for the lowest CPU
frequency:

1.7GHz:
absolute timestamp - 5.215, 5.225, 5.2025
thread CPU timestamp - 5.4725, 5.24, 5.47
both timestamps - 9.4675, 9.49, 9.485
sampled instrum. mode - 0.1162, 0.1162, 0.1162

600MHz:
absolute timestamp - 7.045, 7.0, 7.085
thread CPU timestamp - 7.1, 7.095, 7.0925
both timestamps - 13.8125, 13.84, 13.8325
sampled instrum. mode - 0.325, 0.325, 0.325

The numbers between 600MHz and 1.7GHz differ a lot
and may cause significant distortion when used
incorrectly.

I have a suggestion: Let's ask the user at the
time of the first calibration if she is running
the IDE on a notebook with CPU changing frequency
(or power saving in general) and in such a case
either:

* let the user switch between the power-saving
profiles and do the calibration for each of them;
asking the user for the profile currently in place
before starting each profiling

or

* doing calibration before each profiling start
Comment 1 Antonin Nebuzelsky 2005-02-17 14:28:26 UTC
But, even the two options mentioned above don't solve the problem with
automatic dynamic change of the frequency, for example done on Linux
(e.g FC3) by cpuspeed daemon.

On my notebook the frequency can automatically dynamically change up
and down between a number of frequencies (600MHz, 1GHz, 1.2GHz, ...,
1.7GHz) based on the current CPU utilization by running processes.

This could affect for example profiling of application startup. At the
very beginning of the startup CPU would be running at 600MHz and after
a few seconds it would be running at 1.7GHz.
Comment 2 mishadmitriev 2005-02-26 05:09:44 UTC
In general, I don't think a machine that dynamically and automatically
changes its speed is a proper vehicle for profiling. I think the only
way to cope with this situation is to detect this capability in the
machine (I suspect some Windows API for that exists; the trick is to
find it) and warn the user. The tool should explain the problem and
ask  user  to either turn this feature off (I guess it can be done),
or run profiler on another machine.

One thing that makes this problem less acute is the fact that
calibration, being quite CPU intensive, is likely to switch the CPU to
the highest frequency. That will mean that calibration data will
always contain the smallest possible timing for instrumentation calls.
This in turn will lead to relatively "reasonable" end results - that
is, at least no zero or negative time for any user app methods due to
instrumentation taking less time during profiling than during
calibration. 

BTW, I wonder how you determined that this problem is P2. It doesn't
seem like a showstopper for users who understands something about
nature of CPU profiling.
Comment 3 Antonin Nebuzelsky 2005-02-28 09:13:54 UTC
> In general, I don't think a machine that dynamically and
> automatically changes its speed is a proper vehicle for profiling.

Unfortunatelly notebooks with modern CPUs will be more and more
popular among developers I guess. At least here, almost all developers
have new notebooks.

> calibration, being quite CPU intensive, is likely to switch the CPU
> to the highest frequency. That will mean that calibration data will
> always contain the smallest possible timing for instrumentation calls.

The switch from the lowest to the highest frequency is not immediate.
Depends on setting of the deamon who does the switching. It takes some
time before the high CPU utilization is detected. This means that the
calibration data will be somewhere between the extremes.

> I wonder how you determined that this problem is P2. It doesn't
> seem like a showstopper for users who understands something about
> nature of CPU profiling.

I think this issue is quite dangerous because not all users may have a
clue that their CPU speed is being switched up and down "randomly" :)

If you explain this issue visibly in the UI (for example in the
calibration dialog box), feel free to downgrade to P3.
Comment 4 mishadmitriev 2005-03-01 01:16:01 UTC
Ok, I agree with your comments.

I've just added a big warning in the calibration dialog about possible
issues with a machine that has dynamically switchable CPU frequency.
So I think we can now downgrade this to P3. A real solution to the
problem should involve detecting this feature for sure (using
appropriate Windows or Linux API I guess), and then either notifying
the user about the exact problem, or maybe doing something smarter.
Such as setting this frequency to a fixed value if it's possible.
Comment 5 iformanek 2005-06-08 12:44:50 UTC
We probably cannot do more than provide a way for the user to 
select "automatically perform calibration before each profiling", which would 
solve this at least partially - the case where the CPU frequency is changed 
during profiling would not be addressed, but at least the (more common) case 
where the laptop rnning on batteries uses different CPU frequency than when 
connected to power, would be solved.
Comment 6 iformanek 2005-06-18 17:38:07 UTC
will not do anything more in M7
Comment 7 Jiri Sedlacek 2005-08-03 18:11:38 UTC
Warning about possible problems with dynamic CPU frequency switching is now 
displayed everytime calibration is performed.

I'm closing this issue and opening new one which suggests enhancement - ability 
to automatically perform calibration before each profiling session.

Marking as fixed for M8.
Comment 8 Antonin Nebuzelsky 2006-01-19 15:16:13 UTC
I tried Profiler 1.0 RC1 with NB 5.0 and I don't see any warning. Reopening.
Comment 9 Antonin Nebuzelsky 2006-01-19 15:33:38 UTC
OK, I see it is there.
Comment 10 Alexander Kouznetsov 2007-03-14 09:41:00 UTC
Profiler 070313