Re: Refs or no refs

Brian Godette (
Mon, 27 Oct 1997 13:25:46 -0700

At 12:37 PM 10/27/97 -0600, you wrote:
>On Mon, 27 Oct 1997, Rolf Hemmerling wrote:
>> Yes, I often wonder if I have just one or two windows open why I don=B4t
>> get my full 28.8 transmission speed for these two !!! Is there
>> *anything* I can do by myself ? Probably not !
>Not that I know of..Actually, if you have a 28.8kbps modem and are sending
>around 15kbps, you can't receive the full rate that the others are sending
>at (assuming they are sending at 15kbps as well)
>Total sending for you =3D 15kbps
>Total receive for you =3D 15kbps X 2 vids =3D 30kbps.
> 45kbps total required...neglecting the overhead of
>the reflector (The overhead of Cornell reflectors is much more than that
>of WP or Enhanced Reflectors).

You almost make it sound like modems aren't bi-directional or symetric
(assuming you're not using a 56k modem which are asymetric) in thier
bandwidth. A 28.8 has 28.8Kbps of bandwidth on both send and receive, one
does not impact the other.

>From Brian Godette's bugs page at
> v2.* does not turn off the received video stream from vid-windows that
> you close by closing the window directly or by using the participants
> list. The only way to turn off the video stream is to use the
> "close-all-windows" command/button (closed eye on the button bar).
> This is a bug that causes the majority of complaints about bad/broken
> vid, this is also why it's strongly suggested to turn off auto-open of
> remote video. This bug also seems to be an extention of the old
> Cornell "null-assertion" problem with the participants list.
Well... there is one more way, but I don't trust it as much. You can close
a window, open it again, and close it again, seems to work for the most
part, like I said I don't trust it :)

>> Jason Williams wrote:
>> > A lot of the problems can be attributed to=20
>> > the "close all" bug of the White Pine 2.X clients on the PC. Try
>> > hitting the close all button a few times and only opening up a few=20
>> > vids at a time.
>> I will have a try !
>> > This seems to be fixed in the 3.X versions from what I can tell.
>> But not with the new 2.1.2 version, as I assume !?!
>No, 2.1.2 still has the problem. Too bad White Pine won't go back and fix
>a few of the bugs in the 2.X versions.
Yup it still has the no-close bug, however they did fix the chat recovery
bug as far as I've seen from doing packet captures.

>> Well.. lurkers. You said:
>> > In part, they use the same bandwidth that any participant uses with
>> > respect to OpenContinue packets. On larger, more populated reflectors
>> > this has a more severe effect on modem users than the limitation of
>> > bandwidth of the reflector. I've seen modem users timeout of a
>> > Cornell reflector with only 25-28 participants on the reflector. The
>> > reflector itself had 45Mbps bandwidth available and was only using=20
>> > 1.8Mbps of it.
>> And what does this mean, if we can=B4t change it ? What can the next
>> generation of CU refs change ? If I understand You, the CU clients can=B4=
>> be modified to improve the situation at all !
>It's really a moot point at the moment since the clients can't handle more
>than 23/24 participants very well due to limitations of the participants
>list. It just means you subdivide the reflector into more conferences.
>White Pine has introduced things like "observer" and "observer-broadcast"
>to deal with the scaling problems. It allows someone to show to everyone
>and prevent interaction between the other participants.
>The CU clients just need to be able to support more participants in the
>participants list...Underlying all of this is the overhead in OpenContinue
>packets..the Cornell reflector isn't designed for modem participants. The
>White Pine reflectors strip a lot of the OC packets before sending to the
>client...I've heard Brian Godette's Enhanced Reflector strips the OC
>packets even more. I'm not sure... Maybe Brian can elaborate on this..I'm
>no expert :)

I don't strip out any more data than WP does, which is removing packet-loss
and state info that doesn't apply to the client the packet is being sent
to. However there is room for improvement as a client only needs to receive
one OC packet from another client once every 60 seconds and OC packets are
transmitted every 10 seconds. The ref could drop every other OC packet from
a client (unless there was some important state change) and reduce that
traffic by half and still have the client maintain a valid participants
list. It's possible the new WP refs do this, but I haven't checked, and is
on my to-do list along with reworking flow-control again (the current
solution has some minor problems).