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.
Summary: | One initial calibration not enough on notebooks with CPU changing frequency | ||
---|---|---|---|
Product: | profiler | Reporter: | Antonin Nebuzelsky <anebuzelsky> |
Component: | Base | Assignee: | Jiri Sedlacek <jis> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | issues, ttran |
Priority: | P3 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Antonin Nebuzelsky
2005-02-16 13:20:01 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. 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. > 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. 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. 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. will not do anything more in M7 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. I tried Profiler 1.0 RC1 with NB 5.0 and I don't see any warning. Reopening. OK, I see it is there. Profiler 070313 |