Re: 2.6 vs 2.4 regression when running gnomemeeting

[Christian Meder <chris@onestepahead.de>]

[-- Attachment #1: Type: text/plain, Size: 5544 bytes --]

On Sat, 2003-12-20 at 04:50, Nick Piggin wrote:
> Christian Meder wrote:
> 
> >On Sat, 2003-12-20 at 03:55, Con Kolivas wrote:
> >
> >>On Sat, 20 Dec 2003 13:38, Nick Piggin wrote:
> >>
> >>>Christian Meder wrote:
> >>>
> >>>>On Sat, 2003-12-20 at 02:26, Nick Piggin wrote:
> >>>>
> >>>>>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.
> >>>>>>
> >>Since so many things have actually changed it's going to be hard to extract 
> >>what role the cpu scheduler has in this setting, but lets do our best.
> >>
> >>Is there a reason you're running gnomemeeting niced -10? It is hardly using 
> >>any cpu and the problem is actually audio in your case, not the cpu 
> >>gnomemeeting is getting. Running dependant things (gnomemeeting, audio 
> >>server, gnome etc) at different nice levels is not a great idea as it can 
> >>lead to priority inversion scenarios if those apps aren't coded carefully. 
> >>
> >>What happens if you run gnomemeeting at nice 0?
> >>
> >
> >Exactly the same. It was only reniced to -10 because I tried it and
> >forgot to set it back. With your scheduler renicing doesn't make a
> >difference. No matter if I renice the compile to 19 or gnomemeeting to
> >-10. With Nick's scheduler renicing gnomemeeting to -10 improves the
> >situation.
> >
> 
> (although not much Con)

right. Ok I'm running now 2.6.0 with Nick's v28p1: The results without
load and with kernel compile load are attached. On nice level 0 I get
now the stuttering sound which I described in the previous mail. When I
renice gnomemeeting to -10 it's actually usable but not as good as in
2.4.2x. It's still sensitive to window movement and X activity. Two
subjective observations are that the nice levels haven't got such a big
impact in Nick's scheduler they used to have and that the default
behaviour gnomemeetingwise is better than in earlier Nick schedulers.

> >
> >>How is your dma working on your disks?
> >>
> >
> >/dev/hda:
> > multcount    =  0 (off)
> > IO_support   =  0 (default 16-bit)
> > unmaskirq    =  0 (off)
> > using_dma    =  1 (on)
> > keepsettings =  0 (off)
> > readonly     =  0 (off)
> > readahead    = 256 (on)
> > geometry     = 65535/16/63, sectors = 117210240, start = 0
> >
> 
> This might be a problem - try turning unmaskirq on, and possibly
> 32-bit IO support on (hdparm -u1 -c1 /dev/hda). I think there is
> a remote possibility that doing this will corrupt your data just
> to let you know.

Tried it and doesn't make a difference.

> >
> >>What happens if you don't use an audio server (I'm not sure what the audio 
> >>server is in gnome); or if you're not using one what happens when you do?
> >>
> >
> >esd was running but I'm not sure gnomemeeting with ALSA support was
> >using it. After killing esd and retrying there was no difference.
> >
> 
> So the 1 gnomemeeting process is doing everything? (except display of 
> course)

AFAIK yes.


				Christian

> >
> >>Renice the audio server instead?
> >>
> >
> >gnomemeeting without audio server is showing the same phenomenon like
> >gnomemeeting with esd.
> >
> >
> >>You've already tried different audio drivers right?
> >>
> >
> >Yes, the phenomenon occurs for the OSS and the ALSA driver.
> >
> >
> >>Nice the compile instead of -nicing the other stuff.
> >>
> >
> >Tried it with same result (see above).
> >
> >
> >>Try the minor interactivity fix I posted only yesterday for different nice 
> >>level latencies:
> >>http://ck.kolivas.org/patches/2.6/2.6.0/patch-2.6.0-O21int
> >>
> >
> >Actually all the posted results were on a 2.6.0-test11-mm1 with your
> >patch added on top. So the patch didn't change anything for me.
> >
> >
> >>Is your network responsible and the audio unrelated? Some have reported 
> >>strange problems with ppp or certain network card drivers?
> >>
> >
> >The problem occurs whether I use my WLAN PCMCIA card or my PCMCIA
> >Ethernet card.
> >
> >
> >>As you see it's not a straight forward problem but there's some things for you 
> >>to get your teeth stuck into. As it stands the cpu scheduler from your top 
> >>output appears to be giving appropriate priorities to the different factors 
> >>in your equation.
> >>
> >
> >I know that the problem isn't straight forward that's why I refrained a
> >long time before posting to linux-kernel trying to rule out different
> >scenarios. As it stands I tried different gnomemeeting versions,
> >different audio drivers, different nice levels, different schedulers,
> >preemption on and off, ACPI on and off, -mm kernels and pristine Linus
> >kernels with no luck. If I put CPU load on my box the gnomemeeting
> >audiostream gets badly mutilated (unusable). There's not much left I can
> >think of that's why I'm finally posting to linux-kernel.
> >
> 
> Thanks for your effort.
> 
-- 
Christian Meder, email: chris@onestepahead.de
 
What's the railroad to me ?
I never go to see
Where it ends.
It fills a few hollows,
And makes banks for the swallows, 
It sets the sand a-blowing,
And the blackberries a-growing.
                      (Henry David Thoreau)
 




[-- Attachment #2: nickload.tar.bz2 --]
[-- Type: application/x-bzip, Size: 8166 bytes --]

[-- Attachment #3: nicknoload.tar.bz2 --]
[-- Type: application/x-bzip, Size: 7283 bytes --]