<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> Paul Davis wrote:<br>> what are those arguments? <br><br>The argument is that rendering images, a part of the GUI, also requires chewing<br>up a lot of CPU. These processes aren't involved in lots of disk IO, they can be<br>manipulating images with either 2D or 3D transforms - as I said, it is pretty <br>similar processes to DSP, it is intensive. <br><br>The time slicing scheduler gives preference to runnable processes that are not <br>using all of the CPU that is given to them and since the image manipulation code<br>is doing exactly that when elements of the image are being moved then its priority <br>pushes it down the list of runnable process - it may have to wait longer to carry on <br>the rendering code.<br><br>There are many aspects to a responsive system: you seem to be arguing that the<br>only relevant one is the audio processing (which includes the disk subsystem). All<br>I am saying is that when you use the mouse to pick up an element in the GUI and<br>you move it that you then also want to see it move. RT scheduling and big buffers<br>are the tools you use to maintain the audible components and renice is almost the <br>only sad little thing available for all else. <br><br>> which is why ardour's default disk i/o buffers are *FIVE SECONDS* long (we <br>> really have seen delays of this length when reading from disk!).<br><br>Ardours disk thread is sched_other. When you wait seconds for IO which finally<br>arrives then your process is pretty much guaranteed, by the scheduler, to be the<br>next process to take the free CPU as your priority improves as your waiting time<br>goes up. A number crunching GUI does not have this benefit since it has not sat<br>around waiting for the system to do something. Applying a renice will move it<br>up the queue (although even at renice -20 it would not pre-empt the typical <br>priority of this disk process).<br><br>> SCHED_OTHER are targetting console-driven applications that do varying<br>> balances of disk i/o, computation and user input/output. they really<br>> don't address the situation of an app that needs to redraw with a<br>> relatively fixed interval on screen, nor do they provide any actual<br>> scheduling guarantees, <br><br>I was not even considering the effects of time scheduled actions in a GUI, simply <br>tracking the interactions of the user with their interface when the system is under<br>stress.<br><br>I think we may have mixed the conversation. Ralf asked if this option should even<br>be in the limits configuration. My answer, offlist, was that there were some potential<br>uses and that since you can already hose an otherwise perfect system by giving a user <br>permission to access to RT limits that there is no adverse effect of keeping this one.<br><br>If there are good arguments not to have this as a limit for the audio group then have<br>the distributions remove it, by all means. I don't see the negative side it being provided,<br>it remains a tuning tool.<br><br>> Robin Gareus wrote:<br>> How many audio apps support 'rtprio' directly (without JACK)? <br><br>I would have expected most of them to implement but that is just an opinion, I am not <br>big on having to rely on other libraries for features that I consider crucial. As stated above, <br>user experience is defined by system response, that includes the audio and the video. <br>Bristol has these as separated processes and this is one of very few ways to control the <br>its GUI CPU profile. <br><br>> ..and how many pro-audio users do use this software [...]<br>> I bet the number is zero.<br><br>I would not contest that. I am not sure how rtprio and having renice in the limits config<br>is really related to jack though.<br><br>Regards, nick<br> </body>
</html>