Re: Newbie Help - and the Holy Grail of CuSeeMe

Jason Williams (
Fri, 3 Apr 1998 11:51:43 -0600 (CST)

On Fri, 3 Apr 1998, Scott Lacroix wrote:
> <nasty, biting sarcasm on>
> Uhm, things worked great for you on a T1 and thus, no-one else published
> the meanings of the setting? Did they all check with you or what?
> <nasty, biting sarcasm off>

Hehe..well..things were a bit different back then :)
When everyone ELSE is also on a T1, the default settings worked great :)

There also wasn't a lot of documentation about CU at the time (web pages
on CU were unheard of at that point since the web was just grabbing hold
about that time). It was a fun time where you had to learn on your own
what the settings did. Now people just refer others to web pages with all
that info on it :)

> Not entirely true. If you want a high quality connection and you push your
> Min Send up then it will definately affect bandwidth.

Yeah, true..I hadn't thought of that way. Most of the time, I've seen
people asking "Why shouldn't my send/receive mins be UNDER 10kbs?"
Generally speaking, reflector operators that I've dealt with haven't even
considered RAISING the min send...just lowering it. Lowering it doesn't
do much good at all. And I doubt you'd send 15kbps when you're paused and
the min is 15kbps. I believe Brian Godette did some tests with the min
rates at some point.

And setting the min send up to 20-30 is an evil trick I learned when I was
on a T1 and didn't like my rates constantly dropping so the other modem
users could see me at the expense of a few of the T1 users that wanted to
see me at a high rate.

> Well thanks! We worked really hard on that bandwidth manager... :)

MPCS certainly handles it a LOT better than the 2.1 reflector :) Congrats.

> >This has something to do with color I believe...Color needs the bandwidth
> >and doesn't like high packet loss (MJPEG at least). If you open a lot of
> >vids, the packet loss creeps up and it stops updating.

As a comment on my comment: :)
That's one reason why I like the grayscale ALWAYS updates though
sometimes pretty slowly. (Assuming the participants aren't paused.) With
MJPEG and the other codecs, they seem to work on a frame by frame basis.
The vid doesn't update till it receives the entire frame.

> I expect that most of the people on Jason's server are using optimal (or
> close to optimal) settings since he (and many others there) are well versed
> in the CU protocol & how to tune thier clients.

Yeah..a quality of 20-25% for MJPEG seems to be the norm :)

--    * Jason Williams -- Austin, Tx.  |     |       * University of Texas at Austin  | ___ |         * BS Computer Science             \_|_/
*************** **************|