[comp.protocols.appletalk] acintosh Peer-to-Peer Communications

amanda@mermaid.intercon.com (Amanda Walker) (02/15/90)

In article <5374@okstate.UUCP>, minich@a.cs.okstate.edu (MINICH ROBERT JOHN)
writes:
> (If I remember correctly, average Ethernet
> speeds are in the 1-10Mbps range [where LocalTalk is at .23 Mbps].)

"raw" throughput for Ethernet is 10mpbs, but unless the software can take
advantage of it, most of that usually goes unused.  To take the canonical
example, copying files via TOPS is optimized for LocalTalk, which means it
doesn't try very hard to push data across any faster.  Public Folder does
a better job of pushing the bits across the wire--it's quite a pleasure to
use over EtherTalk.

Even better is using, say, FTP, which can use the congestion-control features
of TCP/IP to maximize the usage of whatever media it's running over.  Just
to throw real live measurements in (gasp! :-)), the last time I benchmarked
the FTP code in our product I got the following set of numbers (all measured
it bytes per second):

Mac II, Ethernet, going to SCSI disk:	55-60K
Mac II, Ethernet, going to RAMdisk:	75-76K
Mac II, LocalTalk, going to SCSI disk:	17K
Mac II, LocalTalk, going to RAMdisk:	17K

You can probably get another few K per second out of LocalTalk, but
this gives an idea of the difference the media can make if the code can
take advantage of it.  It also shows that there comes a point where the
network isn't all of the bottleneck any more...

Caveat: our code is not really optimized for Ethernet, it just does a pretty
good job.  With some work and careful tuning, you can squeeze a lot more
out.  MacTCP has been clocked at up to 375K bytes/second over Ethernet,
according to Apple (no disk access).  This could probably be as much as
doubled (on an idle Ethernet) before running into media limitations.
On the other hand, the EtherTalk software architecture isn't designed
for truly high performance, since the MacOS doesn't really have real-time
response capabilities.  The doubling mentioned above might have to involve
bypassing the .ENET driver and handling board interrupts directly, but
that's seldom worth (a) the effort and (b) the loss of device independence.

--
Amanda Walker
InterCon Systems Corporation

"Many of the truths we cling to depend greatly upon our own point of view."
	--Obi-Wan Kenobi in "Return of the Jedi"