throttling back CPU use.

[Peter Jason]

Win7 64bit SP1 i760CPU

My video transcoders usually have an option to
prevent full CPU utilization, but this latest one
(Xilisoft Blu-ray ripper) doesn't.

Can this be done from the operating system,
because normally I run them at 80% CPU usage?

Peter

 

[Andy Burns]

My video transcoders usually have an option to
prevent full CPU utilization, but this latest one
(Xilisoft Blu-ray ripper) doesn't.

Can this be done from the operating system,
because normally I run them at 80% CPU usage?

Presumably you're wanting to keep the machine responsive for other tasks
while ripping? From task manager you can lower the priority, or set the
affinity of the ripper to a subset of your cpu/cores ...

 

[Paul]

Presumably you're wanting to keep the machine responsive for other tasks
while ripping? From task manager you can lower the priority, or set the
affinity of the ripper to a subset of your cpu/cores ...

The Task Manager controls are pretty crude.

If you right-click a process, and select Affinity, there is a tick box
per CPU core. If you have a 4 core processor, you could untick one of the
boxes in Affinity, so the program is free to roam in 3 cores. It could then
only tie up those cores, leaving the fourth core unused. If you really
want to slow it down, you could leave just one box ticked, using 25% of
the CPU.

If you right-click and select "Priority", that arranges a process to be
placed ahead or behind other things. If you use "lower than normal",
then that should improve the responsiveness of the machine. Using the
Priority control, many times, is not worth the effort. And if you're not
careful, and select something like "Real Time" or other super-high
priorities, you can actually deadlock something. Usually, one level above
or below Normal, is a safe adjustment range. If dialing one level above
or below Normal doesn't fit it, try something else.

One thing you can't fix (and this has been true on computers for
eons), is when programs fight over a disk drive, you can't really
tame them. If I start pulling uncompressed video at 100MB/sec off
my C: drive, then try and open Firefox, it might take a minute or
two for Firefox to open (even if my CPU cores are not full). There
will be fighting over the disk, and things can slow down a lot. Even
if I reduce my video tool down to one core (with Affinity), it might
still pull video at 100MB/sec (it actually does!), and I would still
be waiting and waiting for Firefox. An SSD drive may help a bit with
this, as there is no "head" to move around, and multiple programs
will be able to share better. But if you're working
with video, chances are all you can afford, are 4TB hard drives.
A 4TB SSD would cost a small fortune. Not many people work with
uncompressed video, but that's what comes out of my BT878
capture card. I work uncompressed, until the cropping and scaling
is complete, and it's ready to render to a compressed format.

Paul

 

[Char Jackson]

One thing you can't fix (and this has been true on computers for
eons), is when programs fight over a disk drive, you can't really
tame them. If I start pulling uncompressed video at 100MB/sec off
my C: drive, then try and open Firefox, it might take a minute or
two for Firefox to open (even if my CPU cores are not full). There
will be fighting over the disk, and things can slow down a lot.

I'm surprised to learn that you work with uncompressed video on your system
drive. The common answer (for eons) to your slowdown issue is to spread your
data I/O across multiple drive spindles, (read from one, write to another),
with neither of those being your system drive for the reason you mentioned.

 

[Paul]

I'm surprised to learn that you work with uncompressed video on your system
drive. The common answer (for eons) to your slowdown issue is to spread your
data I/O across multiple drive spindles, (read from one, write to another),
with neither of those being your system drive for the reason you mentioned.

Actually, that was to illustrate a point, of contention for a slow
resource.

Right now, I have three drives. One with the system on it (500GB),
one for the source video (2TB), one for the destination video (3TB).
Using VirtualDub and Huffyuv lossless, I can go from the
most wasteful format (the format that comes from the video card),
to one that occupies about half the space, with no quality loss. So
I'm reading from one disk, at 100MB/sec or so, and writing
to the other at 50MB/sec. If I was actually rendering to a
heavily compressed format (ready for DVD), the speeds wouldn't
even be close to that. The 100MB/sec is for simple stuff like
crop or resize, or attempts to sharpen.

I occasionally put the video output on the system drive by
accident, but I can detect that pretty readily if Firefox
takes too long to open That's because some of the tools
I was testing, default to "My Videos" on C:.

I was testing a few free video programs, things like avisynth,
avidemux, and virtualdub, and trying to get some sharpening,
and finally got an acceptable result from virtualdub. Took long
enough. That's the fun part of free software I guess. All
the testing. One of the filters I tested, did lots of FFTs,
and took about 10 times the execution time of some of the
other methods, and did... absolutely nothing to the picture

Paul

 

[Gene E. Bloch]

One of the filters I tested did lots of FFTs,
and took about 10 times the execution time of some of the
other methods, and did... absolutely nothing to the picture

Given what some software does, that *has* to be a feature

 

[Paul]

Given what some software does, that *has* to be a feature

I'll just relabel it "Copy function" and problem is solved.

Paul