On Mon, Mar 06, 2000 at 03:28:04PM -0000, fsg.student4_at_bt.com wrote:
> Hello,
> 
> for some video streaming testing I'd like to limit
> the speed between my Coda servers and clients. I think
> "filcon slow ..." is the right tool for that. According to 
> the documentation, I have to use port 1363 for the client
> and 1361 for the server. 
> 
> These ports seem not to work, I always get a 
> "Can't bind: RPC2_NOBINDING". 
> 
> I can however bind to port 2430 for the client and 2432 
> for the servers. Are these the right ones for that purpose?

Yes, the 1363/1361 ports are from before we got officially assigned
portnumbers.

> And if I use these ports I don't really see change in Coda
> speed down to about 600,000 bits per second. With 500,000
> bits per second, data transfer from server to client is
> suddenly very much slower (perhaps by a factor 50).
> Can you explain this or is it connected to the port problem?

Filcon is mostly useful for simulating 128kbits per second or slower
connections. It probably has to do with the granularity at which we slow
the connection. We simply delay the transmission of a packet based on
it's size and the simulated connection speed.

The delay is calculated in milliseconds, and if it is less than 16
milliseconds it is not delayed. Looking at the code, I can see that it
actually does things wrong for small packets as they are immediately
sent even when some big packets are still waiting in the queue.

Let's see, 600kbps, 16msec... packets smaller than 1200 bytes are not
delayed at all. And the sftp packets are actually 1024 bytes and only a
few rpc2 packets are bigger. Yup, it wouldn't do a thing there, at
64kbps the 16msec treshhold only applies for packets smaller than 128
bytes which is just about anything we send out.

If someone want to improve the stuff, give it a shot, the code is in
fail/delay.c. Getting rid of the 16msec MINDELAY is probably already a
big step in the right direction. Improving the resolution to usec, and
sending off multiple packets if we have `overslept' would probably get
us closer to the simulated bandwidth.

Jan