Re: [9fans] Private Namespaces for Linux

[presotto@closedmind.org]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

server = PentiumII/Xeon 400
client = PentiumPro 199
network = 100 mbs ether

test =
	import {tcp|il}!olive / /tmp
	cd /tmp/386/bin; cat * > /dev/null

the remote fs protocol is 9P2000

I did a few runs to warm up the cache on the
server and 7 runs each for IL and TCP interleaved.
The timings came out just about the same for
Il and TCP, 29.17 and 29.38 secs respectively.
The difference was well within the error bars.


[-- Attachment #2: Type: message/rfc822, Size: 2394 bytes --]

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Cc: 
Subject: Re: [9fans] Private Namespaces for Linux
Date: Tue, 20 Nov 2001 18:40:47 -0500 (EST)
Message-ID: <200111202340.SAA18771@augusta.math.psu.edu>

In article <20011120220809.8D66B199E4@mail.cse.psu.edu> you write:
>OK, OK, here's why IL is deprecated:
>
>1.  It doesn't cope well with long networks (it hasn't
>had the chance to be tuned to the same degree as TCP).
>
>2.  It's a headache to maintain.
>
>3.  The new protocol (9P2000) doesn't depend on record
>boundaries being preserved; there is basically no dependence
>on IL in the new system other than the current fileserver
>implementation, which is about to be overhauled (RSN!).

Yes, but isn't il a lot more efficient on the wire than TCP,
particularly over mostly reliable local area networks?  TCP has a lot
of baggage to deal with high loss, high latency, networks with moderate
bandwidth at the expense of higher bandwidth, lower latency, low loss
networks; in other words, it doesn't cope well with short networks.  :-)

	- Dan C.