The ol' Linux-on-Linux

[Dan Potter]

> Imho, the network side is quite fast enough.. (perhaps due to having
> 512kbps ADSL, your performance does not sound that bad.. ;P)

Heh, yeah, for web serving it's quite sufficient. Which was one of the
applications I was looking for, so in that way it's already been a success
for my goals.

I'm only picky about it because my original goal was to take two separate
servers (both running x86 Linux) plus a desired new third one (OSX, for AFP
support) and run them on one machine. One of the Linux machines is an
internal network file server, and the other is a web/mail server. So the
internal bandwidth would need to be pretty good.

I started reevaluating that goal though since I did some simple benchmarks
on OSX. The MOL OSX drivers are quite good, and I get nearly native
performance with them on network transfers and such. OSX-on-MOL has
incredible performance actually... IMO it runs much snappier than it did
natively on the same hardware (minus the 3D accel of course). Unfortunately
OSX's AFP bandwidth seems to be pretty slow. Using NFS I was able to get
the speeds I mentioned before (~60Mbit/sec on a 100Mbit link) but using AFP
both under MOL and natively, I could still only get about 16 or so.

Maybe I'm taking the long road around for what I want though. :) What I'd
really like is to be able to serve NFS to OSX clients and not have the file
system littered with ._foo files. It seems like on a modern FS like reiser
you ought to be able to stuff those forks into the file itself and not
cause maintenance issues on the Linux side. Apparently there still aren't
any good solutions for that though, besides just running AFP on OSX as a
server.

Of course for internal serving I have a grand install base of ... 2 users.
:D So maybe I'm just trying to over-engineer the problem. Bad habit of mine.


On Jun 09, Samuel Rydh wrote:

> I would guess this is due to the linux sider drivers. For instance,
> the block device driver is completely synchronous (the interface
> intended for boot loaders is used) and any operation will
> completely block interrupts.

Interesting.. yeah, this wouldn't have shown up in the small bit of testing
I did, I think. I haven't gotten something like dbench to work yet. What I
did was copy over a linux 2.6.8 kernel source tarball, "tar xjvf" on it,
stdout piped to /dev/null, and "time" on the whole thing. It took about
1 minute and 15 seconds on MOL-Linux and about 1 minute 11 seconds on
the host machine. Both cases were actual HD partitions with reiserfs.

I don't know a whole lot about the Linux driver model right now, but it
might be a fun learning experience to try to optimize these drivers too.
Anyone have any good links on general kernel programming info like that, to
sort of get one's bearings?

And actually I just realized that my network bandwidth testing might have
been flawed. I was comparing with scp vs my previous tests with NFS, so
there could've been other things influencing the test. I'll give that another
try tonight with all NFS.

> > Samuel, even though this stuff still isn't 100% "primetime", do you  
> > have any problems with me posting it up for others to try out as well?
> 
> No, not at all.

Cool, I've asked SourceForge for some space to post it at. I'll let you
guys know when it's up.