CU-SeeMe over SLIP Dial-up: Observations

Bart Kindt (bart@dunedin.es.co.nz)
Tue, 10 Jan 1995 20:07:00 -0500


Subject: SLIP and PPP *Queueing* of video streams.

This may be already known, but here some observations made by me during a test.

I am running a multi-line dial-in Internet service, which uses CSLIP.
I have 4 28,800 bps dial-in modems, hanging of a LINUX server.

I am now running Reflector 2.50 on the LINUX box.
On the local Ethernet network, I run the Router to the Internet, and a
486DX/266 machine running Windows 3.11 and the latest CU-Seeme.

I connect my Windows CU-seeme to the Reflector, transmitting at 80 kbps.
(over the Ethernet)
A dial-in users connects to the LINUX server at 28,800 bps, and connects to
the Reflector. He gets the picture.
I am talking to him on the phone, on another line. After a while I discover
that he talks about things I did minutes before, so I say to him: Tell me
when you see me raise my hand... 3 minutes later, he finally sees me
raising my hand.

Now, what happens here is that during a SLIP (or PPP) connection, incoming
packets which are coming in at the UNIX Server faster then they can be send
over the SLIP line, are being *QUEUED*!
And if the transmission cap is nice and high, like 80 kbps, the UNIX Server
will run more and more behind, and will reserve more and more *memory* until
things go wrong! If the server has lots of memory, and a 80 kbps video
stream is viewed for a very long time, it is possible that *HOURS* of video
are stored in the UNIX Server's SLIP or PPP cache. In this situation, it has
proven imposible to disconnect the the CU-Seeme on the receiving side; let
me re-phrase that; You can disconnect from the Reflector, and the reflector
may stop sending video, but the many minutes (or hours) of video stream
collected in the UNIX cache will keep coming!

I our case, my poor LINUX box was using about 4 megabyte of memory after
onlt 15 minutes, and was disk-swapping heavely (something it normally never
does).

When I brought my transmission cap back to 30 kbps we managed to stay in
'real-time' with the connection; A user dialing in via 14,400 bps and I had
to go back to about 15 to 20 kbps transmission cap to stay in 'real-time'.

I heard that people are having problems with sound over dial-in lines. As
sound has some kind of real-time aspect to it, it may be possible that this
sound problem is related to above caching situation.
As a poor Windows user, I can't try the sound yet :-(

Anyway, I thought it worth posting this info in the mailing list.
I may explain some eratic behaviour, including a mail I saw some time ago,
about somebody complaining that hours after he stopped viewing still lots of
data was coming through.

Note that if the SLIP or PPP server works properly, the SLIP/PPP cache
should be dumped after the users disconnect fro the Server; however until
this is done the Server *will* keep sending the contents of the cache to the
SLIP user, and the user will have to 'sit it out' or disconnect.

Cheers, Bart.

-----------------------------------------------------
Bart Kindt (ZL4FOX), Sysop, Efficient Software NZ LTD
-----------------------------------------------------