Re: [9fans] slow performance

[erik quanstrom <quanstro@coraid.com>]

On Sat Mar 31 15:27:49 EDT 2007, wbh@conducive.org wrote:
> 
> But dated. Been a while since a 100 MHz Irix was top dog, if ever was.

you belie your youth.  ;-) 1990 was a long time ago.  i'm not sure what
"overtaken by events means".  one easier to answer question is, does
plan 9 scale with today's processors and networks.  

here's some observations.

as slow as 100Mhz seems today, that's 1/30th of the speed of 
modern processors.  improvements in networking have been even 
more dramatic.  from the table at the end of /sys/doc/net/net.ps:

test	throughput	latency
	MB/s		ms
pipes	8.15		0.255
IL/ether	1.02		1.42
URP/dk	0.22		1.75
cyclone	3.2		0.375

in 1990 there was only 10Mbit ethernet.  so ~ 1MB/s was the speed limit
on the wire.  today we have 10Gbit/s ethernet a wire speed of 1250MB/s.
10mbit ethernet is 1/1000th as fast.

without setting up a test harness, it's hard to get comparable numbers.
but for "cat bigfile > /dev/null" from our fileserver to the main cpu server
over il/1Gbit ether (i82563) i get

IL/gbe	 	45.8		0.054		(standard frames)

i ran AoE on the same hardware while it was in testing and got
basically wire-speed.

AoE/gbe		112		0.054		(9000byte frames)
AoE/2xgbe	220		0.054		"

the cyclone is the dual-fiber connection between the fileserver and the
main cpu server.  it seems quite slow (a modern SATA drive can
easily do 65MB/s in the outer zones) until you realize that on a 
contemperanious pc, you could get ~0.5 MB/s from the hard drive.

> "Although it is possible to write parallel programs in C, Alef is the parallel 
> language of choice."
> 
> Which raises the question (in my own mind at least) as to how much and how well 
> this has been preserved and extended in 'C' with Alef having left the building 
> with Elvis.

the thread library provides the same csp primitives that alef did.

> And what penalty comes with the benefit of communication by text stream vs 
> binary?

not every interface is text-based.  /dev/bintime is an example of a binary
interface.  the decision to use mostly text-based communcations is a real
benefit to plan 9.  if you've ever been a couple of rounds with netlink
sockets, ioctl or other unix interfaces, you know what i mean.

the other great thing is that out-of-band information is generally handled
by a seperate control file.  the plan 9 uart interface has seperate ctl, status amd data
files.

> And via a fs call (whether in cache/RAM or not), vs 
> closer-to-the-CPU-core. Registers, even.

not sure what you're getting at here.

> 'Universality and 'portability' are perhaps not such a big deal when very few 
> processor families are supported.

it's a huge deal as soon as two architectures are supported.

> And I *have* seen some impressive figures mentioned for time to boot a large 
> grid from a cold start vs other OS'en.
> 
> But where can I/we find 'evidence'  - current evidence - that all this is more 
> than a theoretical exercise?
> 
> A place where Plan9 holds the high ground in real-world use, so to speak.

if you're looking for an "os for supercomputers", plan 9 might not be your thing.
if you're looking for an "os for programmers", plan 9 might just be your thing.

- erik