Re: [GnomeMeeting-devel-list] GnomeMeeting on 2.6



Damien Sandras wrote:
I have the same conclusion as you here. I can reproduce the problem with
a very violent "make -j 2". GnomeMeeting really becomes unusable in
that case.

I wonder if it is related to the preemptive patch or not. I'm trying
without.

I will mail Robert Love about this.


Hi

I don't think it is the preemptive patch. I used that one before,
in 2.4 without problems. In fact it improves things in 2.4 when running GM, there is something else I would say but I guess Robert Love knows
this better than we do :)



Cheers Johnny




Le 30/1/2004, "Johnny Strom" <jonny strom netikka fi> a écrit:


Damien Sandras wrote:

Hi Johnny,

I'm interested in results with Seti home not running. Nothing indicates
if Seti home has a good behavior or not.

Well everyting is fine when seti home is not running or when I am not
compiling somethig. So the sound and the video is fine at the other and
that is true for bouth settings of P_HAS_SEMAPHORES (1 and 0).


What triggers this problem is when something tries to get 100% cpu all
the time, so for example if something just tries to get 30% cpu then it
is not a problem like when I am playing two avi movies at the same time,
that is ok. But when moving some windows around all the time then that
tries to get 100% cpu and one gets a choppy sound in the other end.

So conclusion this problem is connected to programs that tries to get
100% cpu it is then when the problem starts to show up.

Cheers Johnny


What are your communications and responsiveness results on 2.6.1 without
SETI and with various settings of P_HAS_SEMAPHORES?

Try moving windows and do usual things and see if it has impact over the
sound quality. Is the GUI slow only when Seti is eating the CPU ?

Le 30/1/2004, "Johnny Strom" <jonny strom netikka fi> a écrit:



Hi

Now I did a test with P_HAS_SEMAPHORES = 1 it is the same as with 0,
so the sound is bad with seti running but it seems to be a littla better
than when P_HAS_SEMAPHORES was 0. If I run seti with nice level 19 then
it is ok. So now with 2.6.1 kernel and P_HAS_SEMAPHORES = 1 it the best
so far.

But still it is not like it was in the 2.4 kernel.

It seems like that GM is punished bye the schedular or something,
the gui becomes reel slow, note that if I try to start other
applications so are the gui fast on the other applications.

And with seti and GM running so is the load getting high:
load average: 6,75, 3,61, 3,99


Could it be becous that GM dose a lot of I/O all the time?
I think there are stuff in the kernel now that looks at that.


Cheers Johnny



Johnny Strom wrote:


Hi

Now I am testing this with David Quental, so if I am compiling
at the samt time as GM is running then I get a lot of cuts in the sound
with P_HAS_SEMAPHORES = 0. This is with 2.6.1 kernel.


!Note that without any cpu intensive processes like seti or
compilation so is the sound fine.


I will send an other mail in some minutes where I put
P_HAS_SEMAPHORES = 1 and repport what happens.

brb

Cheers Johnny


Damien Sandras wrote:



Who is using the 2.6 kernel and is ready to test the latest changes with
it?

Craig, given the fact that many packagers will compile on 2.4, what is
your suggestion?

I tried on the 2.4 kernel to force the P_HAS_SEMAPHORES to 0 and I have a
bad sound quality when compiling, which I had not with P_HAS_SEMAPHORES
set to 1.

The problem becomes complex. Having a bad sound quality is not
problematic. What was problematic on 2.6 was to have people having bad
sound quality as soon as they were moving a window.

What are your comments?

Thank you,


Damien
_______________________________________________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list



_______________________________________________
Gnomemeeting-devel-list mailing list
Gnomemeeting-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list









[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]