Re: Improbable packet loss to nv, bug?

lynn@hellcat.cit.cornell.edu
Thu, 9 Feb 1995 11:15:35 -0500


> CU-SeeMe reports (seemingly) erroneous packet loss rates to an nv client
> via multicast, forcing sender rate to back off to minimum.
>
>
> Config:
> Machine 1 - Sparc10, SunOS4.1.3 w/MCAST
> running Reflector 3.0b3 w/nv and vat multicast .conf
>
> Machine 2 - SparcIPC, SunOS4.1.3 w/MCAST
> running nv v3.3 beta, vat v3.4
>
> Machine 3 - PPC8100/80AV, MacOS7.1.2
> running CU-SeeMe (0.8b1, 0.8b2)
>
> Symptoms:
>
> I have successfully configured the above to pass CU-SeeMe format video
> between machines 2 and 3 above via multicast, (I will try to htmlize the
> procedure for posting on appropriate sites). I have noticed an extreme
> performance problem that often though not always occurs. Machine 3's cap
> gets driven from its local defined value (80kbps) to 10kbps. When I look
> at machine 2's packet stats, (as viewed from machine 3), I see packet
> loss rates in the range of 10's to 100's of thousands out of a total
> transmitted on the order of thousands. There is no way this is
> correct, since not enough time has elapsed for me to send that many
> packets. Loss rates quickly jump to the high 90%'s. This of course causes
> machine 3 to back off its transmit rate. Packet loss almost always
> jumps in blocks of 28416. I have also seen negative values for packet loss
> (register overflow?), resulting in greater than 100% packet loss
> reported. I can get around this problem by forcing
> machine 3 to ignore the choke back (i.e. set min=max=80kbps), which
> results in good performance. I also notice nv on machine 2 reports high
> packet loss (~8-15%) when machine 3 is choked back to 10kbps, but reports
> better stats when machine 3 is forced to transmit at 80kbps (0-2%).
>
> I have not seen these problems when running in Mac/PC client only mode.
>
> Is this a known bug? Is it a new bug? Is it me? Please advise.
>
> Thanks for a great product.
>
> Regards,
> Dave Brown

---------------------------

Dave,

This was caused by a bug in the reflector code which can be fixed
by applying the following patch.

In the file mbone.c at line 1233 change

> msg += 4;

to
<
< *msg++ = 0;
< *msg++ = 0;
< *msg++ = 0;
< *msg++ = 0;

John Lynn
jal7@cornell.edu