Command prompt window priority on Windows Server 2008 R2 (Windows 7) - c

Is an application running in a console window treated "less important" by the windows scheduler, i.e. does Windows allow it to "sleep" longer if it's minimized? I thought I read something about Windows lowering its priority if it's minimized, but perhaps I just mixed something up.
The thing is, I have a C console app (written in VS2015, but running on Windows Server 2008 R2, so no GetSystemTimePrecise support, unfortunately), which does some socket communication, but sometimes the receiving threads (IOCP) get paused and packets get merged together.
So, in my main function I wrote something like this:
timeBeginPeriod(1);
while (true)
{
QueryPerformanceCounter(&start);
Sleep(1);
QueryPerformanceCounter(&stop);
LogTimeElapsed(start, stop);
}
I obviously didn't expect to get millisecond accuracy out of Sleep(1), but I was surprised to get numerous delays of ~50 milliseconds, with maximum reaching more than 120 milliseconds on several occasions.
Of course, during this time, there were other active processes consuming CPU (doing some database exporting and similar, with total CPU going to ~50%), but since this is a quad core CPU I thought that the thread scheduler would still prevent such long delays from happening.
Is this an artifact of running as a plain console app, or should I expect similar delays in any Windows desktop/service application?

Windows is not a real time system, so it is allowed to suspend a task for a non deterministic time. If other tasks use the 4 cores during a short time (some tenths of seconds) any program (be it console of GUI) can be suspended for that time. And as Windows is a feature rich OS, many system services can compete for the CPU in addition to other tasks, so latencies up to few tenths of seconds can be expected at any time
Simply the TCP stack guarantees that the program will get all the data received during that time in correct order, but it is allowed to concatenate several packets in on single read because TCP is a stream protocol. So you program should be prepared for that. The only alternative is to use a real time OS, either on the main machine or on a dedicated one.

Related

Sage Maker Studio CPU Usage

I'm working in sage maker studio, and I have a single instance running one computationally intensive task:
It appears that the kernel running my task is maxed out, but the actual instance is only using a small amount of its resources. Is there some sort of throttling occurring? Can I configure this so that more of the instance is utilized?
Your ml.c5.xlarge instance comes with 4 vCPU. However, Python only uses a single CPU by default. (Source: Can I apply multithreading for computationally intensive task in python?)
As a result, the overall CPU utilization of your ml.c5.xlarge instance is low. To utilize all the vCPUs, you can try multiprocessing.
The examples below are performed using a 2 vCPU + 4 GiB instance.
In the first picture, multiprocessing is not set up. The instance CPU utilization peaks at around 50%.
single processing:
In the second picture, I created 50 processes to be run simultaneously. The instance CPU utilization rises to 100% immediately.
multiprocessing:
It might be something off with these stats your seeing, or they are showing different time spans, or the kernel has a certain resources assignment out of the total instance.
I suggest opening a terminal and running top to see what's actually going on and which UI stat it matches (note your opening the instance's terminal, and not the Jupyter UI instance terminal).

Programming a relatively large, threaded application for old systems

Today my boss and I were having a discussion about some code I had written. My code downloads 3 files from a given HTTP/HTTPS link. I had multi-threaded the download so that all 3 files are downloading simultaneously in 3 separate threads. During this discussion, my boss tells me that the code is going to be shipped to people who will most likely be running old hardware and software (I'm talking Windows 2000).
Until this time, I had never considered how a threaded application would scale on older hardware. I realize that if the CPU has only 1 core, threads are useless and may even worsen performance. I have been wondering if this download task is an I/O operation. Meaning, if an API is blocked waiting for information from the HTTP/HTTPS server, will another thread that wants to do some calculation be scheduled meanwhile? Do older OSes do such scheduling?
Another thing he said: Since the code is going to be run on old machines, my application should not eat the CPU. He said use Sleep() calls after CPU intensive tasks to allow other programs some breathing space. Now I was always under the impression that using Sleep() is terrible in any program. Am I wrong? When is using Sleep() justified?
Thanks for looking!
I have been wondering if this download task is an I/O operation.
Meaning, if an API is blocked waiting for information from the
HTTP/HTTPS server, will another thread that wants to do some
calculation be scheduled meanwhile? Do older OSes do such scheduling?
Yes they do. That's the joke of having blocked IO. The thread is suspended and other calculations (threads) take place until an event wakes up the blocked thread. That's why it makes completely sense to split it up into threads even for single core machines instead of doing some poor man scheduling between the downloads yourself in a single thread.
Of course your downloads affect each other regarding bandwith, so threading won't help to speedup the download :-)
Another thing he said: Since the code is going to be run on old
machines, my application should not eat the CPU. He said use Sleep()
calls after CPU intensive tasks to allow other programs some breathing
space.
Actually using sleep AFTER the task finished won't help here. Doing Sleep after a certain time of calculation (doing sort of time slicing) before going on with the calculation could help. But this is only true for cooperative systems (e.g. like Windows 3.11). This does not play a role for preemptive systems where the scheduler uses time slicing to allocate calculation time to threads. Here it would be more important to think about lowering the priority for CPU intensive tasks in order to give other tasks precedence...
Now I was always under the impression that using Sleep() is terrible
in any program. Am I wrong? When is using Sleep() justified?
This really depends on what you are doing. If you implement sort of busy waiting for a certain flag being set which is set maybe after few seconds it's better to recheck if it's set after going to sleep for a while in order to give up your scheduled time slice instead of just buring CPU power with checking for a flag never being set.
In modern systems there is no sense in introducing Sleep in a calculation as it will only slow down your calculation.
Scheduling is subject to the OS's scheduler. He's the one with the "big picture". In my opinion every approach to "do it better" is only valid inside the scope of a specific application where you have the overview over certain relationships that are not obvious to the scheduler.
Addendum:
I did some research and found that Windows supports preemptive multitasking from Windows 95. The Windows NT-line (where Windows 2000 belongs to) always supported preemptive multitasking.

Timers and Sleep on windows

I am trying to port some linux code that uses nanosleep() and get_clocktime() to windows. As far as I have read there really isn't that many performance timers on windows and there are no real sleep functions other than Sleep(). I found QueryPerformanceCounter and QueryPerformanceFrequency on windows, but how would I adapt those to use with a fast sleep function. The code in which I am trying to port is located at this StackOverflow post: https://stackoverflow.com/a/13559213/1161270
Overall I'm trying to port linux code to windows that uses nanosleep(), get_clocktime() and struct timespec, but there seems to be no real equivalent. I am also open to other ideas on how to add throttle delays. I've read into the PdhGetFormattedCounterArray() functions and I have working code to monitor the output bandwidth of the computer in bytes, but I am unsure on how to use this data to create a delay to throttle back data sending to a specific kb/s speed, and would much rather use the other method provided in the linked post.
Thank you for your time.
Bear in mind that the ACTUAL precision on most OS's types of sleeps are often in milliseconds (or even some multiple thereof). It may well appear that you can sleep shorter periods, but in reality, either the OS doesn't actually put the process to sleep, or the sleep period is "ticks". This is true for both Linux (depending on kernel configuration) and Windows.
Microsoft explains timeouts here (and Sleep is simply a timeout waiting for nothing to happen):
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms687069%28v=vs.85%29.aspx#waitfunctionsandtime-outintervals

Why does computer going to sleep mess up my WPF program and what to do about it

I have a WPF program that communicates with a specialized USB stick that is collecting data (in fact an ANT USB dongle). I noticed that the data collection simply stopped after a few hours. The reason was evident in the windows logs (system) where at the exact time the program stopped getting data, I see:
The system is entering sleep
Sleep Reason: System Idle
Questions
How do I programmatically prevent Windows from going to sleep so that I can continue to gather data?
2. Stepping backwards for the big picuture view... What's going on? Why does the computer going to sleep affect my program? Or is it just affecting the USB stick? Is it necessary to prevent sleep or should I do something else instead?
Einstein's answer is tantalizingly close. I just can't seem to get SetThreadExecutionState working in my C#/WPF program and can't find a lot of examples or discussions of it. Does it need to be called more than once? If so how? Is there a event that I receive that tell me to call it or should I call it every so often (5 minutes?) as suggested in:http://stackoverflow.com/questions/5870280/setthreadexecutionstate-is-not-working-when-called-from-windows-service
For now, I'm just going into ctrl panel -> power options and preventing sleep but it would sure be nice to have an elegant solution. Even on my own computer, I don't want to mess with the sleep settings. It's too hard to remember to set them back again!
You can prevent the computer from entering low power modes (sleep/suspend) by using the SetThreadExecutionState function.
As far as why going into low power mode is interrupting your data collection - well Windows suspends all processes in these modes and USB ports enter low power mode which likely means your USB device will not have power either. It's by design. After all, the whole reason we want our computers to go to sleep is so that the battery is not drained.
You can apply the above responses, o simply you can go in Control Panel -> Power Options and modify the settings, so your system never goes to sleep.
To 1): You can use SystemParametersInfo with one of the power related values on Windows versions less than Vista to turn on/off power savings settings. Starting with Vista, you should register for one of the power events instead, and the OS will notify you when it needs to for the event you request.
To 2): If the OS shuts down, the hardware it's managing shuts down. What else would you expect to happen? If the OS runs the USB device driver, which runs the USB device, what would you think would happen if the OS goes to sleep? The USB device begins running itself instead without the driver?

What is the minimum guaranteed time for a process in windows?

I have a process that feeds a piece of hardware (data transmission device) with a specific buffer size. What can I reasonable expect from the windows scheduler windows to ensure I do not get a buffer underflow?
My buffer is 32K in size and gets consumed at ~800k bytes per second.
If I fill it in 16k byte batches that is one batch every 20ms. However, what is my lower limit for filling it. If say, I call sleep(0) in my filling loop what is my reasonable worst case scheduling interval?
OS = Windows XP SP3
Dual Core 2.2Ghz
Note, I am making an API call to check the buffer fill level and a call to the driver API to pass it the data. I am assuming these are scheduling points that Windows could make use of in addition to the sleep(0).
I would like to (as a process) play nice and still meet my realtime deadline. The machine is dedicated to this task but needs to receive the data over the network and send it to the IO device.
What can I expect for scheduler perfomance?
What else do I need to take into account.
There is no guaranteed worst-case. Losing the CPU for hundreds of milliseconds is quite possible. You are subject to whatever kernel threads are doing, they'll always run with a higher priority than you can ever get. Running into a misbehaving NIC, USB or audio driver is a problem you'll constantly be fighting. Unless you can control the hardware.
If you can survive occasional under-runs then make sure that the I/O request you use to get the device data is a waitable event. Windows likes scheduling threads that are blocking on an I/O request that completed ahead of all other ones. Polling with a Sleep() is not a good strategy. It burns CPU cycles needlessly and the scheduler won't favor the thread at all.
If you can't survive the under-runs then you need to consider a device driver.
What is the minimum guaranteed time for a process in windows?
There is no guarantee: Windows is not a real-time O/S.
What else do I need to take into account
What else is running on the machine (something high priority might preempt you)
How much RAM you have (system performance changes a lot when RAM is in short supply)
Whether you're dong I/O (because you might e.g. stall while waiting for disk or network access)
I would like to (as a process) play nice and still meet my realtime deadline. The machine is dedicated to this task but needs to receive the data over the network and send it to the IO device.
Consider setting the priority of your process and/or thread at "real time priority".

Resources