![]() | |||||||||||||
Messages in this thread |
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) > >>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. > >>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) > >>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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:59 [from the cache] ©2003-2008 | |||||||||||||