[lug] dvd::rip and transcode

[D. Stimits]

Ed Hill wrote:
> 
> On Tue, 2002-05-14 at 17:11, D. Stimits wrote:
> > j davis wrote:
> > >
> > > has been running for 13 hours and claming another 15 is still needed. Is
> > > this normal?
> > > dvd::rip and transcode are also deinterlacing and running "nice 10". Is it
> > > the nice 10 that is killing me? I have looked at the chapters that are
> > > already done...look good and they work!
> >
> > Can't say for sure, but you are doing cpu-intense work, and telling it
> > to offer almost no cpu time to the task. With audio/video, you would
> > actually be risking gaps if the app doesn't know how to deal with it.
> > I'd be tempted to run it at -1, and just try it out.
> 
> I don't do dvd ripping so I have no idea what typical times are...
> 
> However, I can say that if you have only *one* cpu-bound process running
> on your system then the priority will have a negligible effect on the
> cumulative time it takes the process to complete.  So ignore Dan's
> advice.  Go ahead and run your ripper with normal or even nice-ed
> priority.  If you are simultaneously using the machine for interactive
> tasks (email, web browsing, whatever), then running the process with a
> lower priority (as you did) is generally a good idea as it will tend to
> improve system responsiveness for interactive tasks.

When it comes to audio and video (realtime with lots of data bandwidth),
there can be a problem without the preemption and low latency patches
(unless you run SMP). The reason I suggest a -1 is not just in hope of
getting a bit more cpu time, but also to give it a bit higher priority
in the amount of time the cpu spends away, time during which buffers
fill or empty (which reminds me, perhaps the app has configurable buffer
size). Imagine that you get a steady number of regular context switches
that regularly deal with whatever is in a buffer, before it fills, and
always starting its new cycle with at least some data in the buffer,
versus the same total time, in which the buffer sits there filled or
empty during longer bursts of time. The guys on audio dev list would
probably think it is nuts to burn audio at a nice of 10 and no
preemption or low latency patch.

> 
> The reason why priority has essentially no effect in this case is
> because, given just only one cpu-bound process, there is no significant
> competition for the cpu cycles.

It isn't always about cpu cycles, but it isn't worth talking about. All
it takes is a test burn to see if there is any difference.

D. Stimits, stimits at idcomm.com

> 
> hth,
> Ed
> 
> --
> Edward H. Hill III, PhD    |  Email:       ed at eh3.com, ehill at mines.edu
> Post-Doctoral Researcher   |  URLs:        http://www.eh3.com
> Division of ESE            |   http://wasser.mines.edu/people/edhill.php
> Colorado School of Mines   |  Phone:       303-273-3483
> Golden, CO  80401          |  Fax:         303-273-3311
> Key fingerprint = 5BDE 4DA1 66BE 4F7B BC17  3A0C 932B 7266 1E76 F123
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug