In Windows 8.1 and WP 8.1, there was a slight difference between the way Background Agent used to work:
WinRT:
In WinRT, in most cases the OS will not terminate the background agent when the background agent exhausts its quota.
Instead it will simply suspend the agent and allow it to continue later. The suspension is done without any warning like
an event being raised or callback called.
The OS will not stop the background agent when it becomes idle (for example when waiting for a command to the server to respond).
Win Phone:
In Win Phone, the OS will terminate the background agent when the background agent exhausts its quota. This termination
will be done with no warning.
In Win Phone, the OS will stop the background agent when the background agent is found to be idle . In this situation the OS will raise IBackgroundTaskInstance.Canceled.
My question is, is there any such difference between Windows 10 mobile and Windows 10 desktop?
In windows 10 Background Agent has been replaced with Background Task. Whatever the type of W10 device (mobile or desktop) it's running on, a standard background task will have 5 seconds to complete its job after receiving the cancel event. Once the 5 seconds have elapsed, the background task will be terminated. The cancel event may be triggered by the user or by the system if quotas (CPU, memory or network) have been exceeded. What is variable from one W10 device to another are both the Memory and Network thresholds used to terminate the task. If you want to learn more about W10 Background tasks, I highly encourage you to watch this video that was made by Microsoft during Ignite 2015 event.
Related
I have a script where I am using Throughput Shaping Timer to achieve 100 TPS/RPS.
When the script is executed on MAC System using GUI Mode, it is able to achieve ~99 TPS/RPS. But, when I execute it on Linux System it hardly goes beyond 60 RPS/TPS.
Following logs received on Linux OS (same script, so Thread Group settings remain as is):
No free threads available in current Thread Group Device Service
Some of the details given below:
JMeter version is 5.4.3 on both the systems (copied the same JMeter to Linux VM as well)
MAC OS version is: 11.6
Linux OS version is: Red Hat Enterprise Linux 8.6 (Ootpa)
Heap setting on both the systems are given below (even increased it to 13g on Linux VM):
: "${HEAP:="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m"}"
Please let me know which settings I should do to achieve similar TPS/RPS as with my GUI on MAC.
Thread Group Setting shown in the attached image.
First of all GUI mode is for tests development and debugging, when it comes to test execution you should be running tests in command-line non-GUI mode in order to get accurate results
Make sure to use the same Java version
Make sure to use the same (or at least similar) hardware
Make sure to check resources consumption (CPU, RAM, Disk, Network, Swap usage, etc.) as it you're hitting the hardware or OS limits you might get false-negative results because JMeter cannot run requests as fast as it can and if this is the case you might need another Linux box and run JMeter in distributed mode
No free threads available in current Thread Group means that there is not enough threads in order to reach/maintain the desired throughput, you can try increasing the number of threads in the Thread Group or switch to Concurrency Thread Group and connect it to the Throughput Shaping Timer via Feedback function
I have a small script (on WSL / Debian) to rsync my files to my Debian server.
I've set the script to run every two hours.
My laptop is a Windows 10 machine.
When put to sleep / idle, the laptop goes into a Modern Standby state:
When Modern Standby-capable systems enter sleep, the system is still
in S0 (a fully running state, ready and able to do work).
This is different from the old S3 state which is where the machine truly was on idle:
Windows and the SoC hardware are always listening for interesting
events (such as a network packet or user input at a keyboard) and will
wake up instantly when needed. The system will wake when there is real
time action required, such as for OS maintenance or when a user wakes
the system
This means that even when I put my laptop to sleep, it's still running the cron job every two hours, which is unnecessary.
Is there any way that WSL can retrieve the power state, e.g. through powercfg so that it only runs the script when the computer is awake?
I saw that Windows/Linux has the ability to suspend a process.
It is wired for me why background applications are not suspended automatically.
For example, lots of resources are used by Chrome when it is in the background. Easily it can be suspended. So it will stay in RAM and it can unsuspend quickly but it will not use CPU and GPU.
My question contains two parts:
Why Windows/Linux (or applications) don't use suspend feature? (sth similar to pause in Android but in the different way)
Is there any way to suspend a background task and unsuspend it when it gets focus (when it goes to foreground)?
A process like Chrome might not have input focus on the user interface but still be "running." (Chrome consists of a set of related processes and threads.)
Yes, Linux does have the ability to actually "suspend" a process using the STOP/CONT signals, but this would be disruptive to the user interface because Chrome, now being literally frozen, could no longer respond to messages sent to it by the user interface.
Processes and threads only consume CPU resources when they actually need to (they are "runnable"), and then only when the operating system gives them a time-slice. If a thread or process is, say, "waiting for the user interface to send it a message," it's not considered to be "runnable" until a message arrives.
It's also typical that, when a process doesn't have input focus, its priority is slightly reduced so that it always gives-way to the process that does. In some systems, the priority is even more reduced when you minimize the window. (When several processes are "runnable," the operating system uses "priority" to help it to decide which one to run next.)
While shutting down QNX neutrino using phshutdown(either reboot or shutdown),system hangs while killing message queues(mqueue).the message displayed on screen is
Shutting down service providers(mqueue)
What could be the reason for this ?
This happens from time to time when you issue shutdown from the command line as well.
Some of the reasons I've seen on the web are:
Hardware issue
Driver issue
Kernel told to shut down when it didn't want to
From what I've cobbled together (and this is by no means definitive, but seems to be plausible), basically, any program that is waiting for the hardware or OS to reply has a chance of hanging the shutdown if the thing it is waiting on gets killed before it does.
A possible mitigation is to slay all your apps/servers (especially those touching hardware devices or shared memory queues) prior to issuing a shutdown, wait for a second or two, then go ahead with your shutdown.
Consider the function/process,
void task_fun(void)
{
while(1)
}
If this process were to run on a normal PC OS, it would happily run forever. But on a mobile phone, it would surely crash the entire phone in a matter of minutes as the HW watchdog expires and resets the system.
On a PC, this process, after it expires its stipulated time slice would be scheduled out and a new runnable process would be scheduled to run.
My doubt is why cant we apply the same strategy on an RTOS? What is the performance limitation involved if such a scheduling policy is implemeted on an RTOS?
One more doubt is that I checked the schedule() function of both my PC OS ( Ubuntu ) and my phone which also runs Linux Kernel. I found both of them to be almost the same. Where is the watchdog handing done on my phone? My assumption is that scheduler is the one who starts the watchdog before letting a process run. Can someone point me where in code its being done?
The phone "crashing" is an issue with the phone design or the specific OS, not embedded OSes or RTOSes in general. It would 'starve' lower priority tasks (possibly including the watchdog service), which is probably what is happening here.
In most embedded RTOSes it is intended that all processes are defined at deployment by the system designer and the design is for all processes to be scheduled as required. Placing user defined or third party code on such a system can compromise its scheduling scheme as in your example. I would suggest that all such processes should run at the same low priority as all others so that the round-robin scheduler will service user application equally without compromising system services.
Phone operating systems are usually RTOS, but user processes should not run at higher priority that system processes. It may be intentional that such processes run higher than the watchdog service exactly to protect the system from "misbehaving" applications which yours simulates.
Most RTOSes use a pre-emptive priority based scheduler (highest priority ready task runs until it terminates, yields, or is pre-empted by a higher priority task or interrupt). Some also schedule round-robin for tasks at the same priority level (task runs until it terminates, yields or consumes its time-slice and other tasks of the same priority are ready to run).
There are several ways a watchdog can be implemented, none of which is imposed by Linux:
A process or thread runs periodically to test that vital operations are being performed. If they are not, correction action is taken, like reboot the machine, or reset a troublesome component.
A process or thread runs continuously to soak up extra CPU time and reset a timer. If the task is not able to run, a timer expires and takes corrective action.
A hardware component resets the system if it is not periodically massaged; that is, a hardware timer expires.
There is nothing here that can't be done on either an RTOS or any other multitasking operating system.
Linux, on a desktop computer or on a mobile phone, is not a RTOS. Its scheduling policy is time-driven.
On a RTOS, scheduling is triggered by events, either from environment through ISR or from software itself through system calls (send message, wait for mutex, ...)
In a normal OS, we have two types of processes. User process & kernel Process. Kernel processes have time constraints.However, user processes do not have time constraints.
In a RTOS,all process are Kernel process & hence time constraints should be strictly followed. All process/task (can be used interchangeably) are based on priority and time constraints are important for the system to run correctly.
So, if your code void task_fun(void) { while(1) } runs forever, other higher priority tasks will be starving. Hence, watch dog will crash the system to specify the developer that time constraints of other tasks are not met.
For example, GSM Scheduler needs to run every 4.6ms, if your task runs for more time, time constraints of GSM Scheduler task cannot be satisfied. So the system has to reboot as its purpose is defeated.
Hope this helps :)