changing scheduling slice time

[Patrick Wagstrom]

> Just because you have a lot of context switching does not mean that
> the 
> kernel is preempting tasks after a short time slice.  It may simply
> be 
> the processes you are running tend to wake up and process a small
> amount 
> of data before going back to sleep.

Errors in the output of the MPEG file inidicate this is the case.
Testing the system with the older v4l driver, which had a different
buffering system, didn't show the problem.  I'm not saying it's
exclusively Ubuntu's fault, I think it's partially the DVB subsystem
too, but changing the time slice seems to fix it.

> What makes you think it doesn't empty the buffer before it goes back
> to 
> sleep?  It may just be waking up and consuming all of the data in the 
> buffer in small chunks, so there are a lot of context switches.

Under load I get lots of errors telling me that it was unable to empty
the buffer.  Examination of the file indicates that I've got truncated
and some missing frames, another solid indicator that the buffers
weren't fully emptied.  Also, other folks in the local linux users group
have the same problem with Ubuntu, but not with Fedora Core, SuSE, or
Gentoo.

> Again, what do you base this conclusion on?  When you are doing this 
> what is your cpu load?  It may simply be that your cpu can't manage
> to 
> capture and encode the video while decoding and playing it all in
> real 
> time.  This may have to do with the codec you are using ( one that is 
> rather cpu intensive? ).

My CPU can manage this just fine.  Capturing data takes approximately 2%
of the load on my Athlon 64 3200+.  I can OC the system up to 2.4GHz
(from 2.0GHz) and still have no problems, this drops all these numbers
further.  Playing back the data takes approximately 50% of the CPU on
the same system when using XvMC for video acceleration.  Disk IO is NOT
the limiting factor as I can pump a pretty constant 20MB read and write
stream simultaneously to the disks.  Watching and recording HDTV takes
about 2MB/s read/write.  Watching and recording puts my system at a
little over 50% load, at least until it starts to hit the damaged parts
of the MPEG file and needs to figure out how to fix them.

Even a marginal load from another task seems to cause it to crap out.
Such as running a process at maximum nice, which means it should nearly
always be pre-empted.  For reference, the card worked just fine on an
old Athlon 700 MHz running RHEL 3.  I couldn't watch and record at the
same time, but I could record and run other tasks at the same time
(compile, games, etc) with no problem.  On ubuntu I can't even fire up
Tux Racer, which barely taxes the CPU without it causing errors.

> > As a reference, I performed a similar test under fedora core 4,
> which
> > averages to about 300 interrupts/s while idle and around 35 context
> > switches.  Even under heavy heavy load (copying lots of files,
> rendering
> > with pov-ray in the background, etc), it was able to keep up with no
> > problem.
> 
> Was this with the same video capture/encoder program using the same 
> settings?

Yes.  I used azap and test_dvr from linuxtv.org to tune and capture the
data to disk and mplayer to play it back in the test.  Repeated the same
test as above, 50%ish load, works just fine.  Heck, I could even play
Quake 4 while getting the HDTV under Fedora with no problems.

You're right, it could be something other than the time slicing issue.
I'd just like to know how to change it so I can test this hypothesis of
mine.  If I lower it and the problem persists, then my hypothesis is
wrong.  I go look at bit more at the internals of the system and DVB
drivers and proceed from there.

So, anyone know how to change the time slice?

--Patrick