Messages in this thread | | | Subject | Re: 2.6 vs 2.4 regression when running gnomemeeting | From | Christian Meder <> | Date | Sat, 20 Dec 2003 05:16:43 +0100 |
| |
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)
[unhandled content-type:application/x-bzip][unhandled content-type:application/x-bzip] | |