Coda File System

Re: venus randomly dies...

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Tue, 6 May 2003 10:02:11 -0400
On Sun, May 04, 2003 at 04:20:02PM +0200, Lionix wrote:
> As i'm here i got a question about $>cfs strong....
> As the command returns no message, nothings apear in venus.log , and i 
> don't see any traffic to the serveur ( any adjusting stuff )....
> 
> How could I know i'm in a strong state ?

Yeah, strong is pretty much a hack, venus simply avoids state changes as
a result of observed bandwidth. Only disconnection can trigger a state
change. Strong is a bit of a misnomer, if you are write-disconnected,
venus should always be write-disconnected (or disconnected). But I
haven't really tested that theory.

> Moreover $>cfs bw 10000000
> always return :
> Bogus or missing opcode: type "cfs help" for list
> 
> Damned !!! I rtfm... and syntax seems good !!! :-P

Syntax is good, but related code is gone. It didn't really do what you
expected anyways. This is part of some code to emulate a slow network
even when the network is fast.

It assumed that the client is connected to an infinitely fast network
with zero latency. Packets are then delayed in the RPC2 layer by
(packetsize / bandwidth) seconds, both when sent and when received.
So this allowed us to simulate a slow modem, isdn or wireless link, even
though the connection to the servers was 100Base-T.

The library that handled all of this (libfail) is even more powerful
than this. It can independently add latency, random packet loss (N% of
packets lost), and all of this selectively on a per-host basis. So if
you use pings of different sizes to characterize some network, it is
possible to use libfail to emulate those conditions on a 'better'
network. At some point there was even some work on a kernel module that
could do based on a 'live trace' of a mobile user walking through an
environment (more packet loss in the elevator, or latency/bandwidth
effect from ad-hoc network routing).

The problem was that libfail is a bit too permissive for it's power.
Anyone in the world could connect to a client or server and set up some
interesting parameters (99% packet loss/1200bps/high latency), so I
removed it. It really isn't too hard to put back, but alternative
solutions like nistnet or shaperd are available for various systems.

Jan
Received on 2003-05-06 10:04:42