Negatives of running processes with real-time priority?
Are there any downsides of running processes with real-time priority (chrt -f 99)?
My hypothesis is that this combined with an affinity will ensure that any pre-emption of my process is minimal and therefore any jitter (specifically network latency) will be minimised - this will not help with overall latency, but at this moment I'm more concerned with jitter.
(Kernel: 2.6.16/3.0)
linux process real-time
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
asked Sep 18 '12 at 14:12
Nim
4531411
add a comment |
Are there any downsides of running processes with real-time priority (chrt -f 99)?
My hypothesis is that this combined with an affinity will ensure that any pre-emption of my process is minimal and therefore any jitter (specifically network latency) will be minimised - this will not help with overall latency, but at this moment I'm more concerned with jitter.
(Kernel: 2.6.16/3.0)
linux process real-time
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
asked Sep 18 '12 at 14:12
Nim
4531411
2
This looks helpful for you: How to reduce jitter for Java?
– ire_and_curses
Sep 18 '12 at 14:15
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before.
– Nim
Sep 18 '12 at 14:20
add a comment |
Are there any downsides of running processes with real-time priority (chrt -f 99)?
My hypothesis is that this combined with an affinity will ensure that any pre-emption of my process is minimal and therefore any jitter (specifically network latency) will be minimised - this will not help with overall latency, but at this moment I'm more concerned with jitter.
(Kernel: 2.6.16/3.0)
linux process real-time
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
asked Sep 18 '12 at 14:12
Nim
4531411
Are there any downsides of running processes with real-time priority (chrt -f 99)?
My hypothesis is that this combined with an affinity will ensure that any pre-emption of my process is minimal and therefore any jitter (specifically network latency) will be minimised - this will not help with overall latency, but at this moment I'm more concerned with jitter.
(Kernel: 2.6.16/3.0)
linux process real-time
linux process real-time
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
asked Sep 18 '12 at 14:12
Nim
4531411
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
asked Sep 18 '12 at 14:12
Nim
4531411
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
edited Dec 20 '18 at 0:21
Rui F Ribeiro
39k1479130
39k1479130
asked Sep 18 '12 at 14:12
Nim
4531411
asked Sep 18 '12 at 14:12
Nim
4531411
asked Sep 18 '12 at 14:12
Nim
4531411
4531411
2
This looks helpful for you: How to reduce jitter for Java?
– ire_and_curses
Sep 18 '12 at 14:15
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before.
– Nim
Sep 18 '12 at 14:20
add a comment |
2
This looks helpful for you: How to reduce jitter for Java?
– ire_and_curses
Sep 18 '12 at 14:15
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before.
– Nim
Sep 18 '12 at 14:20
2
2
This looks helpful for you: How to reduce jitter for Java?
– ire_and_curses
Sep 18 '12 at 14:15
This looks helpful for you: How to reduce jitter for Java?
– ire_and_curses
Sep 18 '12 at 14:15
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before.
– Nim
Sep 18 '12 at 14:20
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before.
– Nim
Sep 18 '12 at 14:20
add a comment |
1 Answer
1
active
oldest
votes
The most immediate downside of running a realtime process is that the process can easily starve out every other process on the system. The result from your point of view will be that the computer is completely unresponsive to keyboard, mouse, and probably network, for as long as the realtime process is using the CPU. This can happen if something goes wrong and the process goes into an infinite loop, or even temporarily if the process starts a long-running calculation without waiting for input periodically. (So, for example, don't run SETI@home with realtime priority.)
A lone single-threaded process on a multi-core CPU is less likely to cause this problem since there are other cores that the lower-priority process can use. But if that process creates any child processes, they will inherit the same realtime priority, so things can get out of control if you aren't careful.
The sched_setscheduler(2) man page has good advice:
Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).
That should be a shell on the console -- not under an Xterm, unless you want to give all of X realtime priority as well.
answered Oct 14 '12 at 1:05
Jander
11.5k43256
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f48519%2fnegatives-of-running-processes-with-real-time-priority%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The most immediate downside of running a realtime process is that the process can easily starve out every other process on the system. The result from your point of view will be that the computer is completely unresponsive to keyboard, mouse, and probably network, for as long as the realtime process is using the CPU. This can happen if something goes wrong and the process goes into an infinite loop, or even temporarily if the process starts a long-running calculation without waiting for input periodically. (So, for example, don't run SETI@home with realtime priority.)
A lone single-threaded process on a multi-core CPU is less likely to cause this problem since there are other cores that the lower-priority process can use. But if that process creates any child processes, they will inherit the same realtime priority, so things can get out of control if you aren't careful.
The sched_setscheduler(2) man page has good advice:
Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).
That should be a shell on the console -- not under an Xterm, unless you want to give all of X realtime priority as well.
answered Oct 14 '12 at 1:05
Jander
11.5k43256
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
add a comment |
The most immediate downside of running a realtime process is that the process can easily starve out every other process on the system. The result from your point of view will be that the computer is completely unresponsive to keyboard, mouse, and probably network, for as long as the realtime process is using the CPU. This can happen if something goes wrong and the process goes into an infinite loop, or even temporarily if the process starts a long-running calculation without waiting for input periodically. (So, for example, don't run SETI@home with realtime priority.)
A lone single-threaded process on a multi-core CPU is less likely to cause this problem since there are other cores that the lower-priority process can use. But if that process creates any child processes, they will inherit the same realtime priority, so things can get out of control if you aren't careful.
The sched_setscheduler(2) man page has good advice:
Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).
That should be a shell on the console -- not under an Xterm, unless you want to give all of X realtime priority as well.
answered Oct 14 '12 at 1:05
Jander
11.5k43256
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
add a comment |
The most immediate downside of running a realtime process is that the process can easily starve out every other process on the system. The result from your point of view will be that the computer is completely unresponsive to keyboard, mouse, and probably network, for as long as the realtime process is using the CPU. This can happen if something goes wrong and the process goes into an infinite loop, or even temporarily if the process starts a long-running calculation without waiting for input periodically. (So, for example, don't run SETI@home with realtime priority.)
A lone single-threaded process on a multi-core CPU is less likely to cause this problem since there are other cores that the lower-priority process can use. But if that process creates any child processes, they will inherit the same realtime priority, so things can get out of control if you aren't careful.
The sched_setscheduler(2) man page has good advice:
Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).
That should be a shell on the console -- not under an Xterm, unless you want to give all of X realtime priority as well.
answered Oct 14 '12 at 1:05
Jander
11.5k43256
The most immediate downside of running a realtime process is that the process can easily starve out every other process on the system. The result from your point of view will be that the computer is completely unresponsive to keyboard, mouse, and probably network, for as long as the realtime process is using the CPU. This can happen if something goes wrong and the process goes into an infinite loop, or even temporarily if the process starts a long-running calculation without waiting for input periodically. (So, for example, don't run SETI@home with realtime priority.)
A lone single-threaded process on a multi-core CPU is less likely to cause this problem since there are other cores that the lower-priority process can use. But if that process creates any child processes, they will inherit the same realtime priority, so things can get out of control if you aren't careful.
The sched_setscheduler(2) man page has good advice:
Since a nonblocking infinite loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application. This will allow an emergency kill of tested real-time applications that do not block or terminate as expected. See also the description of the RLIMIT_RTTIME resource limit in getrlimit(2).
That should be a shell on the console -- not under an Xterm, unless you want to give all of X realtime priority as well.
answered Oct 14 '12 at 1:05
Jander
11.5k43256
answered Oct 14 '12 at 1:05
Jander
11.5k43256
answered Oct 14 '12 at 1:05
Jander
11.5k43256
answered Oct 14 '12 at 1:05
Jander
11.5k43256
11.5k43256
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
add a comment |
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
Yes - this is the main problem that I appear to encounter. Short of reading through the kernel code to determine all the processes that need to have a higher priority, the only option is to starve all others aside from my process and then move anything that requires any form of io to other cores... hmmm...
– Nim
Oct 18 '12 at 10:28
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f48519%2fnegatives-of-running-processes-with-real-time-priority%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
This looks helpful for you: How to reduce jitter for Java?
– ire_and_curses
Sep 18 '12 at 14:15
@ire_and_curses, currently the process runs on it's own isolated core (at least the main processing thread), however the interrupts aren't scheduled on that same core (can't do this as there are several similar processes relying on the same network interface), this is more of a last effort.The APIC frequency is interesting, I've not encountered this before.
– Nim
Sep 18 '12 at 14:20