Subject: Re: [netatalk-admins] AS IP speeds

From: Paul Krohn <[email-masked]>
Date: Wed, 6 Jan 1999 23:12:17 -0800

On 1/6/99 4:28 PM, Yann Bizeul wrote:

>Here are my comparative stats for transfert rates :
>
>An Appleshare IP 6 G3/300 server 100BaseT full duplex :
>4,7 M/s upload
>3.4 M/s dowload
>
>My linux box Pentium II 333, 100 BaseT full duplex :
>3 M/s upload
>900 K/s download

I can think of a few things that might sway the results in favor of the 
AppleShare IP 6 server.

1) identical file system - needn't do any fancy cr/lf stuff and so forth
2) powerpc/g3 at 300 MHz is most likely substantially faster that a 
PII-333 - are both fast enough to saturate a 100 Mbit wire? i dunno - i 
have no PII's and no 100 Mbit wire.
3) Apple has a whole project team working on optimized ethernet and scsi 
drivers for _just_ that hardware. they claim something like a 30% speed 
boost from the optimized drivers (in their bundle ...) compared to buying 
all the parts separately. we have adrian - bless his heart. thinking of 
adopting the pizzaware philosophy, adrian?
4) i've always noticed a huge drop in file copy performance on mac when 
copying a large number of small files (documented below). it makes a big 
difference what you copy.  ever accidentally copied someone's netscape 
cache directory over the network?  yikes. and fonts seem to especially 
take forever.

while we're at it, anyone else want to compare results?

file size: 42,022,212 bytes (Myth II demo installer)

copy from linux to mac
52s 808,119 bytes/sec
52s

copy from mac to linux
39s 1,037,585 bytes/sec
42s

2,849,963 bytes for 552 items (netatalk source code)

linux to mac
21s 139,022 bytes/sec
20s

mac to linux
17s 178,122 bytes/sec
15s

mac: umax S900/200, OS 8.5.1
linux: cyrix 200 (well 166, but they lie ...) kernel 2.0.36, 
netatalk+asun2.1.0, 3com 3c509 isa ethernet card, adaptec 2940 scsi-2 card

Paul Krohn
San Francisco Examiner - Systems Department
110 Fifth Street
San Francisco, CA 94103
415-777-7884 [email-masked]

---

From: Mark Donnelly <[email-masked]>
Date: Thu, 7 Jan 1999 12:20:56 -0600

> 1) identical file system - needn't do any fancy cr/lf stuff and so forth

Most likely the case - more on this in a moment.

> have no PII's and no 100 Mbit wire.

Neither do I, but I know that a FreeBSD box (wcarchive.cdrom.com)
completely saturates a 100MB wire, and it's a PentiumPro (probably a
slower MHz than the G3).  I don't think it's the processor speed,
especially if that's a 333 processor on a 100 MHz bus.

I'd say that more likely than the processor speed is the drive speed.
What type of drive is it?  What's its average access time?  Do you run
disk utilities (defrag especially) on it?  My guess is that your Lintel
box has an IDE disk, whereas the ASIP6 box is probably more of a server
and has faster SCSI disks.

Adrian:  Have you looked into the mechanisms used by FreeBSD to achieve
this?  I hear that the guy at wcarchive implemented a SendFile() call to
grab files directly out of VM and send them on the wire.  I also hear that
this either already exists or is in the works for Linux as well. Would
these be of any use to ASIP?  I don't know the file sharing protocol at
all really, but if you ever need to send entire files at a time, this
could be really useful.

> adopting the pizzaware philosophy, adrian?

Huzzah!  The Windoze connectivity people (SAMBA) do it - why not the Mac
connectivity people?  Adrian & Wes: name a place!  I'll be happy to send a
bit of a donation.

> cache directory over the network?  yikes. and fonts seem to especially 

Ah, here's where the real culprit shows its face, I suspect.  The
difference is that UNIX filesystems don't really support Macintosh files.
They have no concept of 'forks' or 'resources.' So, an artificial
structure had to be put in place to simulate the resource fork.  So,
there's more done automagically by MacOS than UNIX.  From what I
understand, this might be what the corresponding processing would look
like for MacOS and netatalk servers (and please forgive me, I've only
lightly touched Mac programming, and that was 3 years ago):

MacOS                            netatalk
=-=-=                            =-=-=-=-=
1) Get a directory listing.      1) Get a directory listing
                                 2) Check for .AppleDouble directory
                                 3) Check for the corresponding 
                                    .AppleDouble file
                                 4) Open it
                                 5) Parse it out for file type/creator
                                 5.5) Close .AppleDouble file (*)
2) Open Data Fork for file 1     6) Open file 1
3) Read Data Fork for file 1     7) Read file 1
4) Send the file                 8) Send the file
5) Open Res. Fork for file 1     8.5.1) Check for .AppleDouble dir (*)
                                 8.5.2) Check for .AppleDouble file (*)
                                 8.5.3) Open .AppleDouble file (*)
                                 8.5.4) Parse out all the resources (*)
6) Send each resource            9) Send each resource
7) Close Data/Resource fork      10) Close file/.AppleDouble file

[ Note: Items marked with an (*) might or might not happen, depending on
        how intelligent Wes/Adrian made their code.  If they generalized
        it, then a directory read will always close the .AppleDouble file
        when it's through; if they made cases for copying files, then it 
        won't.]
[ Note2: This also assumes that the network has already been taken care
         of, and that the IP stacks are of about the same caliber, which
         they're not - things like FreeBSD are almost certainly better.]

So, each file copy out of a netatalk volume likely results in twice as
many disk accesses as on a MacOS volume, and that doesn't even take into
account any optimizations Apple might have thrown into HFS (like having
type/creator inherent in the directory structure, or perhaps having
data/resource forks contiguous so that one disk read gets both of them,
etc, etc).  Yes, things like parsing the resources do have to happen in
both cases, but since Apple controls the OS, that's likely highly
optimized.

That doesn't even take into account things like directory ID's and unique
file ID's.

The end result is that the UNIX filesystems can't handle Macintosh files
without some juggling, which is always going to result in loss of speed.
That said, netatalk seems to handle things a lot better than WinNT server
does!  Let's hope that Adrian's DID improvements help in speed some as
well.

Thanks Wes & Adrian!
--Mark Donnelly

---

From: "Robert B. Bell" <[email-masked]>
Date: Thu, 07 Jan 1999 17:21:54 -0800

At 12:20 PM 1/7/99 -0600, Mark Donnelly wrote:
[snip]
>there's more done automagically by MacOS than UNIX.  
[snip]
>without some juggling, which is always going to result in loss of speed.
[snip]

For a Linux box, 
is there a better filesystem to used for netatalk
than the standard linux ext2?

Thanks,
  Robert Bell.

---

From: Mark Donnelly <[email-masked]>
Date: Thu, 7 Jan 1999 21:59:14 -0600

> than the standard linux ext2?

Not really.  If you peruse the (hidden) directories on your Linux/UNIX
netatalk server, then you'll notice that there are a set of files in a
directory named '.AppleDouble' with identical names as the directory
(~/test.txt has a corresponding file ~/.AppleDouble/test.txt).  That is
the inherent slowdown - UNIX has to emulate it with two separate files,
whereas MacOS sees it only as one file.  You're not going to find a UNIX
that handles the resource forks natively as the 'same file' as the data -
it's completely contrary to the UNIX filesystem.  Even if such a
filesystem existed, netatalk would have to be rewritten to take advantage
of it.

--Mark

---

From: "Thomas Dorr" <[email-masked]>
Date: Thu, 7 Jan 1999 23:21:20 -0500

> than the standard linux ext2?

	Well in theory couldn't you just format a partition to hfs and use the HFS
driver, and use the fork=netatalk feature?  This would of course be rather
silly, you'd loose the ability to control it very well, no quota, no
permission control... hrm...  I don't know, just a thought.

	Off this topic, what is the problem with MacOS 8.5 that is occuring, or was
occuring?  I seem to remember something about sherlock, but what in the
world could it be doing?

	Further off topic, I'm wondering if it's possible to boot something like an
Imac using Netatalk, and bootp. (into macos)

Thomas Dorr

---

From: [email-masked]
Date: Fri, 08 Jan 1999 08:58:06 -0500

>without some juggling, which is always going to result in loss of speed.

Has anyone done any profiling to know that this is the problem?  All of
the libraries build for profiling, so it's pretty easy to run it and
see.

:wes

---

From: [email-masked]
Date: Fri, 08 Jan 1999 09:43:06 -0500

> From:    "Thomas Dorr" <[email-masked]>
> To:      <[email-masked]>

> Imac using Netatalk, and bootp. (into macos)

It's actually DHCP, not bootp.  If you can boot an iMac to your ASIP
server, just take a look at the DHCP transactions.  Fairly trivial,
only three or four Apple-specific requests.  You'd need to emulate
that, which should be no problem, and you'd need to get copies of iMac
system software, which may be different for netbooting.

:wes

---

From: Chris Irvine <[email-masked]>
Date: Fri, 8 Jan 1999 08:58:51 -0800

> system software, which may be different for netbooting.

I don't think this will work.  I have been drilling Apple about the file 
services in OS X server.  A quick look shows that net booted imacs are not 
booting from an AFP volume.  It defiantly has something to do with NetInfo, 
a technology NEXT.  This could be a combination of meta information in the 
DHCP reply that point a client to a NFS server, but that is just a first 
guess.  There is a NFSd in the OS X server.  I hope to learn more about 
this today.
Chris Irvine                       mail: [email-masked]
Information Systems Technician     web: http://www.dhorse.com/
Dark Horse Comics, Inc.            phone: 503-652-8815 x367
PGP Fingerprint:
2D99 60B9 9868 3CF6 2E04  82C2 57E0 8B44 E322 090C

---

From: [email-masked]
Date: Fri, 08 Jan 1999 12:26:10 -0500

> From:    Chris Irvine <[email-masked]>
> To:      [email-masked]

> booting from an AFP volume.

I have sniffs from a netbooting iMac.  It could be that things have
changed since I took it, as it was fairly early.  It looked to me to be
a DHCP transaction followed by an ASIP filesystem mount.  I understand
that it doesn't work with AS over AppleTalk (ASAT?).

:wes

---

From: Chris Irvine <[email-masked]>
Date: Fri, 8 Jan 1999 09:46:10 -0800

> that it doesn't work with AS over AppleTalk (ASAT?).

I say this because the the iMac had two volumes mounted on startup after a 
netboot.  A boot volume and an applications volume.  Get info said both 
were local, locked, HFS+ partitions.  My first guess was hard NFS style 
mount.  One of the MacWorld conference sessions demonstrated how to 
configure the net boot operation in DR2.x.  When I asked, they didn't know 
how it worked.  In fact a good portion of Apple's people don't seem to even 
be sure what or "if" ASIP style services are include OS X server.  I do 
know they are in there.  But it could be anything at this point: NetAtalk, 
Xinet, ASIP6, or Helios.  The members of the ASIP6 team that I asked about 
it said they didn't know what it was, and were fairly sure that it wasn't a 
port of ASIP6... yet.

Chris

---

From: a sun <[email-masked]>
Date: Sat, 9 Jan 1999 00:23:27 -0800 (PST)

this is what i heard from one of the os x server folks at macworld:
     1) there's a dhcp transaction (actually, he said a bootp thing,
        but that doesn't really matter)
     2) the imac tftp's a rom image from the server.
     3) that rom image sets up the imac to query the server for an
        asip mount.

so, everything but the rom image should be fairly trivial to do. a
bunch of the linux folks initially tried to get the imac to net boot
early on before there was usb support. as it should be possible to net
boot an imac into linux, maybe somebody motivated will figure out what
the mac is expecting. to get a net booting mac os, however, we'd need
access to a net booting apple rom image. i doubt that would be easy to
obtain without actually going out and purchasing os x server. 

-a