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

From: Bob Atkins <[email-masked]>
Date: Mon, 11 Jan 1999 10:31:46 -0800 (PST)

Thomas,

> > I have found through considerable experimentation that most G3/300
> > systems can't do more than 380-420KBytes/sec sustained transfer rates
> > using ftp to/from a local SPARC/Solaris server over a 10BT LAN. I can
> > assure you that SPARC to SPARC the same file can be moved at
> > 995-1000KBytes/sec over the same 10BT LAN segment essentially achieving
> > saturation of the segment. Mac ethernet speeds have never been very
> > good and I have *never* seen any MacIntosh even come close to
> > saturating a 10BT ethernet the way a SPARC can or even a decent (200MHz
> > PII) PC can (885-900KBytes/sec).
> 
> Well, I beg to differ... nothing here being greatly scientific but I've see
> a 604e 225Mhz send around 950 k/sec over ip (ftp) to a P75 on 10BT now the
> difference is that... The 604e 225 mhz was running BeOS, and the P75 was
> running linux...  The MacOS doesn't seem to allow for saturation... the
> 95Mbps the ASIP 6 tests that apple does on 100bt seem... unreal..
> 

I never said that the Mac *hardware* wasn't capable of saturating an
ethernet. Clearly a fully multitasking BeOS that has properly written
networking capabilities will be able to do much more with the G3
hardware or any other hardware for that matter. Don't get me started on
the way the MacOS wastes the underlying hardware... :(

---
Bob
> That was my 2 cents.
> Thomas Dorr

---

From: a sun <[email-masked]>
Date: Mon, 11 Jan 1999 13:33:59 -0800 (PST)

hmm, i guess the saturation on 10BaseT that i can get with my g3/266
and my g3 upgraded 6100 are all figments of my imagination. the
7-8Mbytes/s on 100BaseT with my g3/266 must also be illusory.

-a

---

From: Sak Wathanasin <[email-masked]>
Date: Tue, 12 Jan 1999 00:25:10 +0000

In reply to Bob Atkins's message of the 11/01/99 at 10:31 -0800,

> networking capabilities will be able to do much more with the G3

This doesn't make much sense to me: logically, a pre-emptive multi-tasking
system, since it has to share the CPU, should be slower than a non-MT system
which has the CPU 100% dedicated to a particular job (for that job only, of
course, nothing else runs). I think the speed of BeOS comes not so much from
the MT, but from being PPC-native from the ground up (in fact, it's the speed
of BeOS that allows it to do pre-emptive MT and still be responsive, not the
other way around).

Back to the topic: is there anyone besides Mr Atkins who is NOT getting at
least 700K BYTES/sec with ASIP over 10-BT? I find it hard to believe that I'm
the only one...

I use the following AppleScript for my tests:

tell application "Finder"
	activate
	with timeout of 5000 seconds
		if (exists file "testfile.dat" of folder "sw:temp:") then
			delete file "testfile.dat" of folder "sw:temp:"
			empty trash
		end if
		set startTime to current date
		copy file "Etc:Stuff:xfer tests:testfile.dat" to folder
"sw:temp:"
		set endTime to current date
	end timeout
	writetext file "Etc:Stuff:results" data ("Copy started " & startTime &
return & "Copy ended " & endTime & return)
	beep
end tell

("writetext" is an OSAX that came with Anarchie); and a similar script in the
other direction. The time measured includes all the Finder pre-flights before
it starts to copy as well as its clean-up operations at the end of the xfer, so
if anything it makes the Mac xfer speed look worse than it is. The numbers I
get are:

netatalk 1.4b2+asun 2.1.2, AppleShare 3.8.1, MacOS 8.5.1

	Test file size		22949839
				start	finish	diff	K bytes/sec

	copy from netatalk		14:40:59	14:41:21	22.00
	1018.73
	copy to netatalk		14:46:27	14:46:58	31.00
	722.97

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690

---

From: PayPC System Mail Subscriber <[email-masked]>
Date: Tue, 12 Jan 1999 18:18:43 +1000

> least 700K BYTES/sec with ASIP over 10-BT? I find it hard to believe that I'm

I use only "wallclock" measurements of large copy operations that take at 
least 2 minutes to complete... I copy to an empty /u2 drive, and trash the 
cache between tests by running a global grep on a massive directory structure.

On OS8.5.1/ASIP 3.8.1 or whatever, PowerMac 8500/120 (slow 604 machine), 
connecting to a AMD-K6-200 (socket 7) with 64MB RM, SCSI, Linux 2.0.33+ etc.  
I routinely get 700-800k/sec average throughput. I think write speeds from 
the Macintosh to the netatalk are a bit faster [Linux has better block/file 
buffering technology]... In informal tests, repeated file copy operations of 
a 10.5MB (canonical 1024*1024*1024 byte MB) file to a Netatalk volume 
requires only 11 seconds (max error for my reaction time is about +/- .2 
seconds, though since my reaction time would "lag" at both ends, it's more 
likely 0.1s) from mouse button release to copy progress dialog vanishing 
(Finder copy routine, obviously).  This is plain Jane 10 Base T TX wiring, 
that's not very carefully laid or made. (thru dumb-ass long suck dong brand 
hubs).

HOWEVER....  With APPLETALK connections, I see more like 500k/sec max.  
Appletalk is clearly and demonstrably slower than AS/IP protocol connections. 
 One VERY annoying thing is that no matter how I initially connect via the 
chooser to Netatalk (selecting the node address "forcing" TCP/IP connections 
to my netatalk server, the "recent servers" menu always engages Appletalk 
when I connect back using those shortcuts... WTF?  Is there a quick and easy 
way to never have The recent Server shortcuts ever make Appletalk (as opposed 
to ASIP) connections?

Of course, copy operations of many small files is a very different story.... 
but that's not a throughput test.

=Robert=

PS: To add insult to injury, the PowerMac mentioned above is connected via a 
10Base 2 (BNC) connection.  So there's nothing wrong with MaOS 8.5.x and 
lowly 120 Mhz PowerPC machines, I assure you (with respect to Netatalk 
performance).

---

From: Osma Ahvenlampi <[email-masked]>
Date: 12 Jan 1999 11:10:08 +0200

> which has the CPU 100% dedicated to a particular job (for that job only, of

You underestimate the complexities involved in high-performance
networking. When you include disk-io, network-io, frame construction,
data processing and all the other major tasks that have to be done
here, and remember that "saturating ethernet" means "io-bound", you
should realize that a well-designed multithreaded/multitasking design 
almost always significantly outperforms a singletasking design in
IO-bound operation, because the more fine-grained structure allows the 
operating system better adjust to run-time enviroment.

And this doesn't even factor in the general bloatedness of MacOS. Even 
if it was more efficient to single-task, it certainly isn't more
efficient to have to run many times as much code for the same
operation. And MacOS doesn't dedicate the CPU to a particular job
anyway - in fact, it's cooperative task switch is many times more
expensive than the pre-emptive context switch of a state-of-the-art
operating system.

-- 
I hope someday a Pope chooses the name Shorty.
Osma Ahvenlampi <[email-masked]>

---

From: Sak Wathanasin <[email-masked]>
Date: Wed, 13 Jan 1999 00:02:16 +0000

In reply to Osma Ahvenlampi's message of the 12/01/99 at 11:10 +0200,

> operating system better adjust to run-time enviroment.

Granted all that, but are you really saying that pre-emptive MT is THE deciding
factor in networking performance? That there is still 68K code in the MacOS
(esp in the file system) doesn't matter one iota? In any case, not having
pre-emp MT doesn't mean everything has to be one monolithic task. I would guess
that the guts of (say) "Fetch" would be implemented as a set of chained async
I/O calls.

>  doesn't even factor in the general bloatedness of MacOS

No one here is disputing this...

> anyway - in fact, it's cooperative task switch is many times more

Only if the appl gives up the CPU; I'm not seriously suggesting that anyone do
this, but it is entirely possible to have an FTP client that just hogs the CPU.

Sak Wathanasin
Network Analysis Limited

Internet: [email-masked]