I'm checking the energy profiling of an app that loads a lot of content into web view. I'm greeted with the following gauge. I see that the energy impact is high, and there's a consistently high overhead (54% in the screenshot).
What is the meaning of the Overhead stat for energy gauge ?
Overhead, that's the amount of power that's needed to bring the hardware up to be able to do your work as well as put it back to sleep.
And overhead is the energy that is required to bring up the radios and all the other system hardware which is required for your application to perform work.
A case about considering that your application is also utilizing the networking component. Networking is going to bring up the radios which will require power for prolonged periods. So in this case you can try to optimize your networking utilization. Try to batch up all your networking activity within your application whenever possible so that it reduces the impact on the networking as well as the corresponding overhead which has resulted from it.
From WWDC's script https://developer.apple.com/videos/play/wwdc2017/238/
just search the key word "Overhead"
Turns out I had to scroll down, as expected, overhead is the cost of keeping the radio/wifi on to do network requests.
Related
I am in the process of creating a C++ application that measures disk usage. I've been able to retrieve current disk usage (read and write speeds) by reading /proc/diskstats at regular intervals.
I would now like to be able to display this usage as a percentage (I find it is more user-friendly than raw numbers, which can be hard to interpret). Therefore, does anyone know of a method for retrieving maximum (or nominal) disk I/O speed programmatically on Linux (API call, reading a file, etc)?
I am aware of various answers about measuring disks speeds(eg https://askubuntu.com/questions/87035/how-to-check-hard-disk-performance), but all are through testing. I would like to avoid such methods as they take some time to run and entail heavy disk I/O while running (thus potentially degrading the performance of other running applications).
In the advent of IBM PC era, there was a great DOS utility, I forgot its name, but it was measuring the speed of the computer (maybe Speedtest? whatever). There was a bar in the 2/3 bottom of the screen, which is represented the speed of the CPU. If you had a 4.0 MHz (not GHz!) the bar occupied the 10% of the screen.
2-3 years later, '386 computers has risen, and the speed indicator bar overgrown not just the line but the screen, and it looked crappy.
So, there is no such as 100% disk speed, CPU speed etc.
The best you can do: if you program runs for a while, you can remember the highest value and set it as 100%. Probably you may save the value into a tmp file.
I have a Windows 7 embedded device which is frequently power cycled like this: a local application writes an entry to the Application event log and a few seconds later it commands the custom power supply to cycle power. A clean Windows shutdown cannot be done. After the device boots back up, I check the Windows event log and notice the last entry missing.
Is there some way to flush the Windows event log to disk so that I don't miss that last entry? The application is written in C++.
Thanks,
Adnan
You have a hardware problem so the best solution is to resolve it in hardware. But moving on.
Use BIOS to ensure computer always starts after a power cycle
You have a hardware tool to perform the reboot. Could you reconfigure that so that rather than doing a hard power cycle while the computer is running, you:
notify the hardware power cycle tool,
perform an orderly shutdown, then
power the computer on again using the hardware power switch?
There is usually a bios setting which allows you to specify the action after a power cycle, e.g.
Leave the computer off,
Turn it on,
Turn it on only if it was on when power was lost.
If you can do this, then you can still do an orderly shutdown and wait for that to complete before powering on again.
Software Solution: Turn off disk write caching
It's not exactly clear what is causing your issue, but the following seem relevant.
Most likely, this is a result of disk write caching either by the disc controller hardware, or by the operating system.
You may be able to turn this off through the Disk Management tool:
http://www.thewindowsclub.com/enable-disable-disk-write-caching-windows-7-8
Software Solution: Flush the disk programmatically
Alternatively, you may be able to flush the disk cache programmatically. This tool may help:
https://superuser.com/questions/833552/manually-flushing-write-cache-on-window
Or indeed with WMI and PowerShell:
https://technet.microsoft.com/en-us/library/dn454975.aspx
I am writing a VoIP program and one of the standard features is press-to-talk, meaning while holding down a key you record and send audio. The key will react no matter if you are in a videogame or has focus on another window.
My questions;
do all VoIP programs explicitly use keyboard hooks to achieve this? For example, ventrilo/teamspeak/skype/mumble
I have heard keyboard hooks incur a peformance hit on the system since every keyboard message is sent to the VoIP application too. Is there a way to reduce the cost, and how big is the performance hit? My number one priority in my application is performance and effective, low use of computer resources.
Thanks in advance
Is there a way to reduce the cost, and how big is the performance hit?
The performance hit and cost are directly proportional to the amount of work your handler code does.
If you read the documentation it says that these are some of the reasons to do so (emphasis mine):
Monitor messages for debugging purposes
Provide support for recording and playback of macros
Provide support for a help key (F1)
Simulate mouse and keyboard input
Implement a computer-based training (CBT) application
I don't know what other programs use.
Use it and see if there is a performance problem. You're probably pre-optimizing at this point. I've seen it used in Windows apps on Pentium I hardware with no noticeable impact.
I need to find the bandwidth available at a particular time. The code must be developed in Visual C++ or in .Net family . If anyone knows how, please help me out.
The only way to check your bandwidth is to actually try to use it, i.e. by downloading a file from somewhere else and measuring the throughput.
Even then it'll only be an approximation, because other network effects will affect the results:
latency
asymmetric upload / download
other traffic
If you mean the current network utilisation, you can call
DeviceIoControl(hDevice, OID_GEN_STATISTICS, ...)
on Vista and above to get the device-specific information. Otherwise, call GetIpStatisticsEx for system-wide information or use WMI's Win32_PerfRawData_Tcpip_NetworkInterface.
Trying to get the "available" bandwidth by attempting to saturate the connection is not a sensible or reliable measure. Just try some of the online speed tests available, and consider that it involves non-scalable bandwidth, and is susceptible to congestion control, QoS and traffic shaping.
Checking the bandwidth will be tricky even by using it. if you try to download data from remote machine X for example and you estimate a figure of N Kbs then how will you know whether that's your bandwidth limitation or the limitation of remote machine X's connection?
You'd need to start simultaneous downloads (or uploads if that's the direction you want to measure) with several remote machines simultaneously and keep increasing the load until the throughput stops increasing.
But as Alnitak said you still won't know what other factors might be affecting the result. Is some other process on your machine using the connection for example? or is the kid next door piggybacking on your wireless LAN and stealing your bandwidth? Maybe that's what you're trying to find out!
I've recently bought myself a new cellphone, running Windows Mobile 6.1 Professional. And of course I am currently looking into doing some coding for it, on a hobby basis. My plan is to have a service running as a DLL, loaded by Services.exe. This needs to gather som data, and do som processing at regular intervals (every 5-10 minutes).
Since I need to run this at regular intervals, it is a bit of a problem for me, that the system typically goes to sleep (suspend) after a short period of inactivity by the user.
I have been reading all the documentation I could find on MSDN, and MSDN blogs about this subject, and it seems to me, that there are three possible solutions to this problem:
Keep the system in an "Always On"-state, by calling SystemIdleTimerReset periodically. This seems a bit excessive, and is therefore out of the question.
Have the system periodically waken up with CeRunAppAtTime, and enter the unattended state, to do my processing.
Use the unattended state instead of going into a full suspend. This would be transparent to the user, but the system would never go into sleep.
The second approach seems to be preferred, however, this would require an executable to be called by the system on wake up, with the only task of notifying my service that it should commence processing. This seems a bit unnecessary and I would like to avoid this extra executable. I could of course move all my processing into this extra executable, but I would like to use some of the facilities provided when running as a service, and also not have a program pop up (even if its in the background) whenever processing starts.
At first glance, the third approach seems to have the same basic problem as the first. However, I have read on some of the MSDN blogs, that it might be possible to actually conserve battery consumption with this approach, instead of going in and out of suspend mode often (The arguments for this was that the nature of the WM platform is to have a very little battery consumption, when the system is idle. And that going in and out of suspend require quite a bit of processing).
So I guess my questions are as following:
Which approach would you recommend in my situation? With respect to keeping a minimum battery consumption, and a nice clean implementation.
In the case of approach number two, is it possible to eliminate the need for a notifying executable? Either through alternative API functions, or existing generic applications on the platform?
In the case of approach number three, do you know of any information/statistics relevant to the claim, that it is possible to extend the battery lifetime when using unattended mode over going into suspend. E.g. how often do you need to pull the system out of suspend, before unattended mode is to be preferred.
Implementation specific (bonus) question: Is it necessary to regularly call SystemIdleTimerReset to stay in unattended mode?
And finally, if you think I have prematurely eliminated approach number one, please tell me why.
Please include in your response whether you base your response on knowledge, or are merely guessing (the latter is also very welcome!).
Please leave a comment, if you think I need to clarify any parts of this question.
CERunAppAtTime is a much-misunderstood API (largely because of the terrible name). It doesn't have to run an app. It can simply set a named system event (see the description of the pwszAppName parameter in the MSDN docs). If you care to know when it has fired (to lat your app put the device to sleep again when it's done processing) simply have a worker thread that is doing a WaitForSingleObject on that same named event.
Unattended state is often used for devices that need to keep an app running continuously (like an MP3 player) but conserve power by shutting down the backlight (probably the single most power consuming subsystem).
Obviously unattended mode uses significantly more powr than suspend, becasue in suspend the only power draw is for RAM self-refresh. In unattended mode the processor is stuill powered and running (and several peripherals may be too - depends on how the OEM defined their unattended mode).
SystemIdleTimerReset simply prevents the power manager from putting the device into low-power mode due to inactivity. This mode, whether suspended, unattended, flight or other, is defined by the OEM. Use it sparingly because when your do it impacts the power consumption of the device. Doing it in unattended mode is especially problematic from a user perspective because they might think the device is off (it looks that way) but now their battery life has gone south.
I had a whole long post detailing how you shouldn't expect to be able to get acceptable battery life because WM is not designed to support what you're trying to do, but -- you could signal your service on wakeup, do your processing, then use the methods in this post to put the device back to sleep immediately. You should be able to keep the ratio of on-time-to-sleep-time very low this way -- but as you say, I'm only guessing.
See also:
Power-Efficient Apps (MSDN)
Power To The People (Developers 1, Developers 2, Devices)
Power-Efficient WM Apps (blog post)