Re: [GnomeMeeting-list] bandwidth dying above 90?

[Damien Sandras <dsandras seconix com>]

Le mar 05/11/2002 à 11:19, Charlie Campbell a écrit :
> I realize this gives me better quality which is why originally i set it to
> 100% but it was dropping off my connection ..flooding my network or
> something because it became hard to get to sites.. so I began to ping
> around and found that the data was somehow being corrupted .. I am not
> sure how or by what exactly .. but I know it somehow revolves around GM
> either using too much bandwidth or something also I do limit my Framerate
> It is limited to 8 FPS. and I have tried all sorts of combinations of the
> background blocks. currently those are set to 10 and seem to work ok as
> they are now.. my upstream is fairly consistant I never had a problem
> before as I have been using many different video chat tools such as
> netmeeting in windows and eyeball chat and even some korean websites such

Netmeeting is using a more performant video codec, and the image quality
is not to 100% in Netmeeting. If you had the possibility to push all
settings to the max in Netmeeting you would have the exact same problem.
100% quality means nearly no compression... If moreover you set the
background blocks to 10, you are telling to GM to send the background
too with each image, even though it should not be transmitted as it is
something static (the background doesn't change). So it is normal to
kill your connection.

Those settings can be pushed to the max for people running GM on LAN's
in professional environments. I took the decision to permit to tweak
those settings (NM doesn't permit a so fine tuning) so that it can be
usable for a wide range of users. But of course, if you are sending the
video at more than 90% quality, and asking to also transmit background
blocks, you will kill your ADSL. 

> as www.seenjoy.co.kr that have video chat rooms where 10 people at a time
> can be in the same room, so i doubt its an inconsistant upstream. the

10 people at the same time in the same room or even 100 doesn't change
your upstream, only your downstream.

> round trip delay also increases from around 70ms to over 4000ms when set
> higher than 90% and (earlier in the last email) i wasnt pinging the person
> i was connected to i was pinging a machine on a campus with multiple T1
> connections. the roundtrip delay on the server i was pinging also went
> down to 4000ms round trip. maybe its a H.261 thing I dont know but it
> didnt seem to do the same thing when I connected to another person using
> GM it seemed to only do it when I was connected with a NM user. anyway
> just some puzzling things to me.. maybe it seems more cut and try to the
> rest of you guys.
> -- 
> Charlie Campbell
> 
> Damien Sandras said:
> > Actually, setting the quality to 90% leads to a very good quality
> > picture that is why it requests more bandwidth. You can set teh
> > framerate to a lower value to spare some bandwidth.
> >
> > I'm actually using 90% and 6 FPS on a 128kbps upstream, so I guess that
> > your upstream is not always of very good quality: you can check the
> > effective upload streams in the statusbar, just make the sum of the A
> > and V values that are on the left. That corresponds to the audio and
> > video upload speeds. Also notice that the "ping" is not always a very
> > good measure, you would better watch the Round Trip Delay in the GM
> > 0.94.1 statistics part which is more accurate.
> >
> > Netmeeting is not using 90% quality but something like 80 or less, but
> > they are using H.263 which is a bit better than H.261 but its use is
> > restricted.
> >
> > Le mar 05/11/2002 à 08:44, Charlie Campbell a écrit :
> >> Interesting things happening when quality is set above 90.. i have
> >> found i get erratic errors when setting my quality setting above 90%.
> >> My video stops sending and I start seeing packet errors to other
> >> networks.. for instance if I ping a server for 40 seconds all pings
> >> are fine set GM about 90% and move around a little and then I get ping
> >> responses that look like this
> >>
> >> 64 octets from 168.18.220.67: icmp_seq=8 ttl=14 time=1504.1 ms
> >> wrong data byte #0 should be 0x35 but was 0x3434 74 c7 3d 18 28 d 0
> >>         8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e
> >> 1f 20
> >> 21 22 23 24 25 26 27
> >>         28 29 2a 2b 2c 2d 2e 2f
> >> I know this is only seq 8 on this set but I have tested this over and
> >> over and get the same results pretty much every time.. my connection
> >> is ADSL 1.5Mbit down and 256kb/s up. I assume this could mean that I
> >> am exceeding my upstream bandwidth by using the higher quality. If
> >> needed I can give more details on my settings. The person I am
> >> connected to is also using Windows Netmeeting on a Windows XP machine
> >> updated to SP1. Her bandwidth is godlike .. 400KB/sec download... and
> >> yes I have seen it myself.. and no I couldnt believe it either. heh.
> >> anyway I found this to be very interesting.
> >>
> >> --
> >> Charlie Campbell
> >> aka xghost232
> >>
> >>
> >> _______________________________________________
> >> GnomeMeeting-list mailing list
> >> GnomeMeeting-list gnome org
> >> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
> > --
> >  _	Damien Sandras
> > (o-	GnomeMeeting: http://www.gnomemeeting.org/
> > //\	FOSDEM 2003:  http://www.fosdem.org
> > v_/_
> > 	H.323 phone:  callto://ils.seconix.com/dsandras seconix com
> >
> >
> > _______________________________________________
> > GnomeMeeting-list mailing list
> > GnomeMeeting-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
> 
> 
> 
> 
> 
> _______________________________________________
> GnomeMeeting-list mailing list
> GnomeMeeting-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-list
-- 
 _	Damien Sandras
(o-	GnomeMeeting: http://www.gnomemeeting.org/
//\	FOSDEM 2003:  http://www.fosdem.org
v_/_	
	H.323 phone:  callto://ils.seconix.com/dsandras seconix com