On Sat Mar 31 15:27:49 EDT 2007, [EMAIL PROTECTED] 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
