This is more of a general Linux issue I guess.
I run povray at nice -19. It doesn't behave as expected. That is, it 
doesn't really yield to other processes.
When I run povray at low priority on Windows, he basically stops for 
anything else. Like here, povray should be stopped, and ffmpeg given 
800% of CPU.

   PID USER      PR  NI    VIRT   SHR S  %CPU %MEM     TIME+ COMMAND 

  8976 dick      39  19 1301940  4512 S 539.4  2.6  32:43.18 povray
11804 dick      20   0 3873964 31452 S 194.4  1.1   5:25.79 ffmpeg

This can't be just the way things are?

--
dik

Post a reply to this message

Am 30.12.2017 um 23:06 schrieb dick balaska:
> This is more of a general Linux issue I guess.
> I run povray at nice -19. It doesn't behave as expected. That is, it
> doesn't really yield to other processes.
> When I run povray at low priority on Windows, he basically stops for
> anything else. Like here, povray should be stopped, and ffmpeg given
> 800% of CPU.

Technically, no, that's not what should happen.

What should happen is that ffmpeg should be given (virtially) as much
CPU time _as it can use_. Which may be significantly less than 800% if...

- it spends a lot of time waiting for file I/O to complete (which I
guess may be quite significant when creating a movie);

- it spends a lot of time synchronizing its threads.

- it uses a limited number of threads as there are (virtual) cores;

- it lets the GPU do most of the work, rather than the CPU;

CPU power ffmpeg makes no use of for any of the above reasons is free
for the taking.

(Also, with a niceness of 19 rather than the maximum of 20, the
scheduler would still give POV-Ray a bit of CPU time even if ffmpeg
would be able to use it all up.)

>   PID USER      PR  NI    VIRT   SHR S  %CPU %MEM     TIME+ COMMAND
>  8976 dick      39  19 1301940  4512 S 539.4  2.6  32:43.18 povray
> 11804 dick      20   0 3873964 31452 S 194.4  1.1   5:25.79 ffmpeg
> 
> This can't be just the way things are?

Judging from the numbers, my guess would be that ffmpeg only uses 2
worker threads (giving it a theoretical maximum of 200%), each of which
occasionally blocks due to file I/O or synchronization (dropping the
actual value to 194%).

The internerds make various contradicting claims about the number of
threads used by ffmpeg, some of which coincide with the value you get.
(See
https://superuser.com/questions/155305/how-many-threads-does-ffmpeg-use-by-default)

The internerds also claim that using ffmpeg's `-threads N` option should
help.

Post a reply to this message

On 12/30/2017 10:04 PM, clipka wrote:

 > CPU power ffmpeg makes no use of for any of the above reasons is free
 > for the taking.

Remove ffmpeg from the equation. If povray isn't running, ffmpeg uses 
800%. It was an example.
The place I really see this is: povrayws, which runs at user priority 
under qtpov, gets slightly *less* horsepower than povray, which is 
running at nice -19 under the renderfarm. povrayws should be using close 
to 800%, not 350ish%, while povray should drop to near 0%.


 > (Also, with a niceness of 19 rather than the maximum of 20, the
 > scheduler would still give POV-Ray a bit of CPU time even if ffmpeg
 > would be able to use it all up.)

Sorry. idiomatic.  "nice -19" is the shell command to send a process to 
the floor.  This sets nice to +19, which is the minimum (or the maximum).
"Niceness values range from -20 (most  favorable  to the process) to 19 
(least favorable to the process)."


-- 
dik
Rendered 344576 of 345600 pixels (99%)

Post a reply to this message

Am 31.12.2017 um 06:39 schrieb dick balaska:
> On 12/30/2017 10:04 PM, clipka wrote:
> 
>> CPU power ffmpeg makes no use of for any of the above reasons is free
>> for the taking.
> 
> Remove ffmpeg from the equation. If povray isn't running, ffmpeg uses
> 800%. It was an example.
> The place I really see this is: povrayws, which runs at user priority
> under qtpov, gets slightly *less* horsepower than povray, which is
> running at nice -19 under the renderfarm. povrayws should be using close
> to 800%, not 350ish%, while povray should drop to near 0%.

Try pitting one instance of genuine POV-Ray at niceness -19 against
another one at niceness 0. That's the litmus test.

If that runs as expected, there's something else in the equation that's
not working properly. Maybe povrayws has a lot of I/O overhead?

Post a reply to this message

Am 31.12.2017 um 14:00 schrieb clipka:
> Am 31.12.2017 um 06:39 schrieb dick balaska:
>> On 12/30/2017 10:04 PM, clipka wrote:
>>
>>> CPU power ffmpeg makes no use of for any of the above reasons is free
>>> for the taking.
>>
>> Remove ffmpeg from the equation. If povray isn't running, ffmpeg uses
>> 800%. It was an example.
>> The place I really see this is: povrayws, which runs at user priority
>> under qtpov, gets slightly *less* horsepower than povray, which is
>> running at nice -19 under the renderfarm. povrayws should be using close
>> to 800%, not 350ish%, while povray should drop to near 0%.
> 
> Try pitting one instance of genuine POV-Ray at niceness -19 against
> another one at niceness 0. That's the litmus test.
> 
> If that runs as expected, there's something else in the equation that's
> not working properly. Maybe povrayws has a lot of I/O overhead?

Also, in the linux standard scheduler (CFS) there's group scheduling,
which might be relevant in your case: If group scheduling is enabled
together with autogrouping, the nice value "has an effect only for
scheduling relative to other processes executed in the same session
(typically: the same terminal window)." [man sched(7)]

Post a reply to this message