(Illustration by Gaich Muramatsu)
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. JanReceived on 2003-05-06 10:04:42