dave@suna.CMI.COM (David Halonen) (05/02/89)
Hopefully I'm not rehashing dry material with this, but I have some questions for netland. I've just finished reading MacUser's May '89 article comparing Ethernet to LocalTalk and I'm wondering if Ethernet is worth its cost? According to the review, a move to an Ethernet network would result in only an incrimental gain in performance. The biggest gain was for large file transfers, which had an increase in performance of 43%. The average gain was about 20% (?), overall. Its my feeling that the CPU speeds must be increased in order for the advantages of Ethernet to be realized. Comments, anyone? Also, could someone please provide me a summary of thier experiences with switching from LocalTalk to Ethernet? I'll summarize to the net or to interested parties if the interest is there. Thanks -- David Halonen, Center for Machine Intelligence, Electronic Data Systems Ann Arbor, MI (313) 995-0900 AppleLink: N0548 Internet: dave@suna.cmi.com
dsill@RELAY.NSWC.NAVY.MIL (05/02/89)
>From: mailrus!caen.engin.umich.edu!suna!dave@tut.cis.ohio-state.edu (David Halonen) >Its my feeling that the CPU speeds must be increased in order for the >advantages of Ethernet to be realized. Comments, anyone? Perhaps that's true in a small all-Mac shop, but in a large hetergeneous environment Ethernet is clearly superior, at least as a backbone. Ethernet is also industry-standard and non-proprietary which gives it an edge in the government. ================================================================ "I no longer think of something as a computer unless it's connected to a network." -- Peter Weinberger
desnoyer@Apple.COM (Peter Desnoyers) (05/02/89)
[DISCLAIMER - I am not voicing Apple policy, and any comments about Apple products or deficiencies therein should not be construed as statements to the effect that Apple is, or is not, working on these deficiencies.] In article <278@suna.CMI.COM> dave@suna.cmi.com.UUCP (David Halonen) writes: > >Its my feeling that the CPU speeds must be increased in order for the >advantages of Ethernet to be realized. Comments, anyone? Van Jacobson at Lawrence Berkeley Labs has gotten ~9Mbit performance from an experimental version of TCP/IP (with full checksumming) on Sun 3/50s and 3/60s. (about MacII speed processors) With enough optimization AppleTalk should be able to do this, as well. Peter Desnoyers
medin@cincsac.arc.nasa.gov (Milo S. Medin) (05/03/89)
In article <29980@apple.Apple.COM>, desnoyer@Apple.COM (Peter Desnoyers) writes: > From: desnoyer@Apple.COM (Peter Desnoyers) > Subject: Re: Ethernet vs LocalTalk >. . . > Van Jacobson at Lawrence Berkeley Labs has gotten ~9Mbit performance > from an experimental version of TCP/IP (with full checksumming) on Sun > 3/50s and 3/60s. (about MacII speed processors) With enough > optimization AppleTalk should be able to do this, as well. > > Peter Desnoyers Wait a sec. Van got those figures running on a real OS (BSD Unix) on properly designed hardware (SUN 3 + Lance chip). There is *NO WAY* you are going to come close with the lousy ethernet controllers you get on the MAC-II, and I doubt the Nu-bus can properly deal with the transfer rate. One thing that Van has definitely shown is that CPU is not the real problem, it's braindead I/O devices! If you expect real performance, use a real computer. Thanks, Milo
desnoyer@Apple.COM (Peter Desnoyers) (05/03/89)
I just did a benchmark with 2 MacIIs, one Ethernetted and one
LocalTalked, transfering a 470k system file. I used the MPW
'duplicate' command. Results:
LocalTalk (through a bridge) - 138kbit/s
EtherTalk (same wire) - 418kbit/s
Doesn't look like 20% to me. For that matter, if the LocalTalk
transfer ran at full speed (c. 95% of 230kbit/s) it would still be
about an 80% speedup.
Based on our group's experience, I would say that the main advantage
of EtherTalk (besides fast FTPs to UNIX machines) is that you can use
a file server as conveniently as your own disk, and so can 20 other
people.
Peter Desnoyersragge@nada.kth.se (Ragnar Sundblad) (05/03/89)
In article <24837@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: >Wait a sec. Van got those figures running on a real OS (BSD Unix) >on properly designed hardware (SUN 3 + Lance chip). There is *NO >WAY* you are going to come close with the lousy ethernet controllers >you get on the MAC-II, and I doubt the Nu-bus can properly >deal with the transfer rate. One thing that Van has definitely >shown is that CPU is not the real problem, it's braindead I/O >devices! If you expect real performance, use a real computer. I have had absolutely *NO PROBLEMS* coming up into this speed - and higher of course - using my macII with apples/3coms, ok - braindead, but not at all slow, ethernet controller via the nubus. There is no DMA, thats a drawback, but on the other hand, I might not be able to wait for other dma tasks to finish before it can do mine. That's one reason wy I sometimes prefer "doing it without dma". The nubus can under certain circumstances keep up with a speed of 40Mbyte/sec, if you're using the block transfer facility which just a few devices support, but normally ~15Mbytes/sec is no problem at all. 10Mbits/sec (ethernet) is nothing. What Van really did was patching a completely I/O- and realtime-braindead os to use one of its i/o-devices at 8-9Mbits/sec. That's really tricky, and any improvement of unix's-whatsoever is really welcome. Maybe, one day, I can use it for other things than just the simplest computer applications and reading/writing news and mail with. :-) I like unix for some things, sun make resonable machines, but there is nothing special about any of them. I prefer ruling my own computer, not having an "os" in between me and the machine. Especially, I don't like an os taking a lot of cpu time from me. Then unix really isn't a hit. Apples macII often is a ok compromise, for example for the ethernet tests I made. There is absolutely *NO WAY* that your sun3 with UNIX would keep the same speed as my macII have on this task. Maybe a Sun4, but probably not. A "clean" sun3/4 of course could do the same, but I don't very much like programming the whole computer. So please, don't tell me about your sun. I get as impressed or interrested as if you would tell me about your telephone.
amanda@lts.UUCP (Amanda Walker) (05/04/89)
In article <24837@ames.arc.nasa.gov>, medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: >[regarding Van Jacobson's TCP experiments] >Wait a sec. Van got those figures running on a real OS (BSD Unix) >on properly designed hardware (SUN 3 + Lance chip). There is *NO >WAY* you are going to come close with the lousy ethernet controllers >you get on the MAC-II, and I doubt the Nu-bus can properly >deal with the transfer rate. One thing that Van has definitely >shown is that CPU is not the real problem, it's braindead I/O >devices! If you expect real performance, use a real computer. > > Thanks, > Milo Hmm. The Mac II I'm posting this from is about the same power as a Sun 3, Lance chip and all (Dove FastNet III, to be exact). The NuBus certainly isn't appreciably slower than the VMEbus in a Sun; I doubt that's a problem. One of the other things that Van has also shown is that, even with a reasonable processor and non-brain-damaged I/O device, the software that drives it is also important. After all, vanilla Sun-OS uses the same hardware as Van's version, and doesn't do nearly as well (or, rather, it didn't before Sun started whacking on their TCP code :-)). Van also keeps asking people not to quote his results out of context, since the factors he is working with are complex, and cannot be reliably summarized with "The Lance is better than an 82586" or any of the other glib versions that have come by since he first started publishing his findings. I think you'll find that a Mac II running Apple's MacTCP (which incorporates most of Van's performance improvements) over an Ethernet board that uses a Lance (such as a Dove FastNet III) gives quite respectable performance. It's certainly as "real" a computer as a Sun 3. What I'd call a "real" computer isn't a Sun 3, but a network controller with it's own Lance, 68mumble processor, a half meg or so of fast RAM, that could run up to the TCP layer in the controller, all without having to worry about trying to do UNIX at the same time. -- Amanda Walker InterCon Systems Corporation amanda@lts.UUCP / lts!amanda@uunet.uu.net
dyson@Apple.COM (Patrick Dyson) (05/05/89)
> Misc os-bashing stuff deleted
Appletalk gets about 3.4 mbit performance cpu-to-cpu over Ethernet using
generic mac software and the ATP protocol (guaranted delivery, 2k chunks).
TCP implementations that I have seen for the mac II get slightly slower
performance, but present more of a stream. UDP would be fairer.
The gating factor in file copy and application launch over ethernet is really
the fileserver and the fact that the resource manager reads in small chunks.
The mac can really keep up with the majority of network services out there.
If it was trying hard, the mouse would start to jump and things would slow
down - and this is rarely seen.
A big advantage of ethernet is what was said before - you can have a hundred
people talking to twenty services and the network is loafing most of the time.
-----------------------
The numbers and opinions expressed above are my own and do not reflect those
of my employer. Patrick Dyson.amanda@intercon.UUCP (Amanda Walker) (05/05/89)
One thing to remember about reviews in magazines about the speed of EtherTalk vs. AppleTalk is that most of them test the speed by copying files with TOPS, evidently out of some feeling that "that's what people use networks for." TOPS does not take advantage of the available speed of an Ethernet. Heck, it doesn't even take advantage of all of the available speed of an AppleTalk. Most of this is probably a design "feature" that allows the server to run in the background while still leave the Mac acting as the server able to do other things at the same time. Ethernet won't give you much if what you're using it for is TOPS. It will gain you a whole lot if you're using AppleShare, TCP/IP, or most other software. -- Amanda Walker <amanda@intercon.UUCP>
desnoyer@Apple.COM (Peter Desnoyers) (05/05/89)
In article <30125@apple.Apple.COM> dyson@Apple.COM (Patrick Dyson) writes: > > > Misc os-bashing stuff deleted > >Appletalk gets about 3.4 mbit performance cpu-to-cpu over Ethernet using >generic mac software and the ATP protocol (guaranted delivery, 2k chunks). > >TCP implementations that I have seen for the mac II get slightly slower >performance, but present more of a stream. UDP would be fairer. > A MacTCP person sent me a message yesterday mentioning, among other things, that they had gotten 3.3 mbit performance memory-to-memory. Both numbers are rather respectable - 2mbit used to be a good performance figure on a VAX. [The similarity between performance figures is no doubt more than a coincidence. The same factors limit performance in both cases.] Peter Desnoyers
alexis@ccnysci.UUCP (Alexis Rosen) (05/07/89)
I've written this several times recently so I won't go into the gory details
yet again, but instead refer you to the srchives. The summary is, "MacUser
really blew it on this one. The only thing they get exactly right is that a
faster server is a better server, so use an SE/30 or IIcx."
In fact EtherNet is a big win, especially for larger nets, and especially
when you're doing heavy file service. Scaling up CPU power also lets you see
a much bigger win from EtherTalk.
---
Alexis Rosen
alexis@ccnysci.{uucp,bitnet}
alexis@rascal.ics.utexas.edu (last resort)medin@cincsac.arc.nasa.gov (Milo S. Medin) (05/08/89)
In article <947@draken.nada.kth.se>, ragge@nada.kth.se (Ragnar Sundblad) writes: > I have had absolutely *NO PROBLEMS* coming up into this speed - and > higher of course - using my macII with apples/3coms, ok - braindead, > but not at all slow, ethernet controller via the nubus. There is no > DMA, thats a drawback, but on the other hand, I might not be able to > wait for other dma tasks to finish before it can do mine. That's one > reason wy I sometimes prefer "doing it without dma". The nubus can > under certain circumstances keep up with a speed of 40Mbyte/sec, if > you're using the block transfer facility which just a few devices > support, but normally ~15Mbytes/sec is no problem at all. 10Mbits/sec > (ethernet) is nothing. What Van really did was patching a completely > I/O- and realtime-braindead os to use one of its i/o-devices at > 8-9Mbits/sec. That's really tricky, and any improvement of > unix's-whatsoever is really welcome. ... If you have MAC-II's with 3com ethernet boards running TCP/IP between them at 8-9 Mbits/sec, I'd love to see how you did it. If you are just running some sort of blast protocol spitting out data without doing and end-to-end delivery, that's a completely different issue. I happen to have a SUN on my desk, but SUN didn't do a great job on the hardware, just a good one (at least on the the system's with the Lance on it)... Potentially, there are a lot better platforms than SUN's, but they work pretty well. Streamlining any large multi-tasking OS for networking is definitely hard work. I am not claiming UNIX is the perfect OS; it's far from it. My point is that there are lots of problems to deal with, and broken hardware is one of them. Broken software helps out a lot too. thanks, Milo
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (05/08/89)
> Excerpts from ext.in.info-appletalk: 3-May-89 Re: Re: Ethernet vs > LocalTalk Amanda Walker@uunet.uu.n (2119) > The NuBus > certainly isn't appreciably slower than the VMEbus in a Sun; I doubt > that's a problem. Keep in mind that Van's highest speeds were with busless machines (SUN 3/50). There was no VME bus to get in the way, the lance has direct access to system memory. Drew
ragge@nada.kth.se (Ragnar Sundblad) (05/08/89)
In article <25079@ames.arc.nasa.gov> medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: ... >If you have MAC-II's with 3com ethernet boards running TCP/IP between >them at 8-9 Mbits/sec, I'd love to see how you did it. If you are ... No, I haven't, but that was not what I was doing. I don't think there would be any problem, though. I do not think that the fact that one can reach TCP/IP speeds of ~9 MBit has anything to do with the sun hardware, that was my point.
desnoyer@Apple.COM (Peter Desnoyers) (05/09/89)
In article <oYNEK5y00UoJQ3rvBq@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes:
#> Excerpts from ext.in.info-appletalk: 3-May-89 Re: Re: Ethernet vs
#> LocalTalk Amanda Walker@uunet.uu.n (2119)
#
#> The NuBus
#> certainly isn't appreciably slower than the VMEbus in a Sun; I doubt
#> that's a problem.
#
#Keep in mind that Van's highest speeds were with busless machines (SUN
#3/50). There was no VME bus to get in the way, the lance has direct
#access to system memory.
#
#Drew
From my reading of Van's postings it seems that VME bus speed would
not have been a limiting factor. Besides, the VME-based Suns are
faster than the 3/50.
Peter Desnoyersmedin@cincsac.arc.nasa.gov (Milo S. Medin) (05/09/89)
Well, I can certainly blast out bits through a hyperchannel a lot faster than pumping useful data through it. Many pieces of hardware deal with more small packets much worse than few large packets. Things like setting up DMA, dealing with interrupts, or polling interfaces and such. In general, there are 2 costs involved in protocol processing. One is fixed per message unit size, and the other is variable with the size. Hardware issues can affect both. I'll give hyperchannel as a straightforward example. Thanks, Milo PS A standard performance of 2.2 Mbits/sec throughput isn't that bad, but it's far from 9 Mbits/sec, which is the point I was trying to make.
alexis@ccnysci.UUCP (Alexis Rosen) (05/09/89)
In article <29995@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >I just did a benchmark with 2 MacIIs, one Ethernetted [etc.] > > LocalTalk (through a bridge) - 138kbit/s > EtherTalk (same wire) - 418kbit/s > > [etc., EtherTalk isn't a trivial win...] OK. I've posted, here and in other groups, about just how brain-dead the MacUser article was. I don't think that needs much rehashing. What I would like to know is why the hell we can't get better performance with EtherTalk on Macs? This performance is about one twenty-fifth the nominal speed of EtherNet. Not something to make the speed junky's pulse race. The fact is that protocol overhead can't begin to account for this. Most of it has got to be in the particular implementation- drivers, bus, ET controller chip, card design, etc. On all >68000 macs, the bus bandwidth can't be a problem. NuBus can handle something like 10 MBytes/sec even if you don't do block transfers. Certainly it won't ever top out from EtherNet load. The other three factors seem to be entirely in the hands of the card designers. So why can't I get cards that work at 2-4 mbits/second?? --- Alexis Rosen alexis@ccnysci.{uucp,bitnet} alexis@rascal.ics.utexas.edu (last resort)
amanda@intercon.UUCP (Amanda Walker) (05/09/89)
In article <1941@ccnysci.UUCP>, alexis@ccnysci.UUCP (Alexis Rosen) writes: >In article <29995@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >> LocalTalk (through a bridge) - 138kbit/s >> EtherTalk (same wire) - 418kbit/s >What I would like to know is why the hell we can't get better performance >with EtherTalk on Macs? This performance is about one twenty-fifth the >nominal speed of EtherNet. Not something to make the speed junky's pulse race. Well, we've seen up to about 1.2mbit/s using vanilla EtherTalk drivers to send & receive packets, so part of the problem is in the higher level protocols. The AppleTalk protocol stack (DDP in particular) is tuned better for LocalTalk than for Ethernet. For example, even though you can send bigger packets on an Ethernet, EtherTalk can't use anything over LocalTalk size, which is 576 bytes (+ headers). That's a performance hit right there. Since AppleTalk as it stands has no notion of fragmentation and reassembly, I don't see a simple way around this. The simplest thing (which is still pretty tricky) would probably be to rewrite .ATP to be able to send ATP transactions in larger chunks, but this might well break a lot of other stuff. Sigh. It'd be nice for future versions of AppleTalk to have something along the lines of TCP/IP's "mtu" and "maxseg" parameters... -- Amanda Walker <amanda@intercon.UUCP>