Re: 2.6 vs 2.4 regression when running gnomemeeting

[Nick Piggin <piggin@cyberone.com.au>]

Christian Meder wrote:

>On Sat, 2003-12-20 at 01:48, Nick Piggin wrote:
>
>>Sounds reasonable. Maybe its large interrupt or scheduling latency
>>caused somewhere else. Does disk activity alone cause a problem?
>>find / -type f | xargs cat > /dev/null
>>how about
>>dd if=/dev/zero of=./deleteme bs=1M count=256
>>
>
>Ok. I've attached the logs from a run with a call with only an
>additional dd. The quality was almost undisturbed only very slightly
>worse than the unloaded case.
>

OK, its probably not that then. Try the find command though, it would
be closer to what make/gcc is doing.

>
>>You said it faired slightly better with my scheduler when renicing
>>gnome meeting to -10. How much better is that?
>>
>
>Worse than unloaded and worse than the disk loaded case from above. But
>all (CPU) loaded cases were producing almost complete audio dropouts
>while with your scheduler and renicing to -10 I got at least a
>stuttering audio stream (a regular pattern of very short slices of audio
>mixed with very short slices of silence).
>

So it does sound like scheduling latency then. Its difficult to find
out what is happening with top and vmstat because they don't give you
an idea of individual scheduling events, which is what is important
for things like this. I'll have a look into making up a patch to gather
what I want to know.

In the meantime, I have a newer scheduler patch against 2.6.0 you could
try: http://www.kerneltrap.org/~npiggin/v28p1.gz

Try nicing the compile to +19 if it still stutters.