henry@utzoo.UUCP (Henry Spencer) (12/15/86)
For those who have forgotten, my original inquiry was whether anyone had
put an Excelan VMEbus Ethernet board on a Sun, with special reference to
using TCP/IP downloaded into the board. It would appear that nobody has.
I got a number of more general comments, which I will now summarize...
My original speculation that Sun's current add-on board was the old 3Com
board was incorrect; it is an 82586 plus some dual-port memory, similar
enough to the on-CPU-board Ethernet that the same driver can run both.
It is "smart" only in the sense that the 82586 is, meaning that it sends
and receives packets but won't help with protocols.
People generally think the Excelan hardware works pretty well. Their
boards are a bit fussy about timing, you must not get sloppy with bus
specs. Throughput is reported as all right, realtime bandwidth for the
on-board TCP/IP circa 630 Kbit/s. (Others are not so pleased, although
they didn't supply numbers; this may reflect different versions of the
Excelan firmware.) Their technical support is also said to be good.
The Excelan boards are definitely more expensive than the dumber ones.
If performance is a serious issue, there may be something to be said for
buying a dumber Ethernet board and a faster CPU to run it (e.g., upgrade
our Sun 3/180 to a 200-series) instead. This isn't an option for us, for
various reasons, but it bears watching in general: the processor on the
Excelan boards isn't that fast, and a CPU upgrade might well deliver more
bang for the buck. In the same vein, it is not clear that moving TCP/IP
out onto the board is a big throughput win, since the CPU on a Sun is a
good bit faster than the Excelan processor, and the number of interrupts
to the CPU and the volume of data moved aren't that dissimilar.
Reports were mixed on the subject of on-board TCP/IP software. In
general, people in simple environments said it was all right and people
in complex environments weren't pleased. Big problem #1 is that on-
board TCP/IP implementations, like more orthodox ones, have bugs, and
in the absence of sources you can't fix them. (Even having sources is
not a panacea, since you also need a cross-compilation environment --
in Excelan's case, a cross-compilation environment for that vile Intel
processor.) Big problem #2 is that many such implementations are fairly
old, and lack features now considered important. And again, there's
nothing you can do without sources. Big problem #3, a fairly fundamental
one, is that getting multiple networks to talk to each other is hard since
the on-board TCP/IPs seldom consider the possibility.
A couple of more specific complaints about the Excelan stuff were also
heard. It is reported that the Excelan board with on-board TCP/IP allots
very limited buffering for UDP, which is significant if you are bypassing
TCP to write your own high-level protocols. Some folks also think the way
the Excelan on-board TCP/IP interfaces to the kernel is clumsy and less
than ideal.
At least one major workstation supplier who has been using Excelan boards
and the on-board TCP/IP is moving away from this approach, in favor of
more orthodox kernel-based TCP/IP.
Overall, I am less sold on the idea than I was. I do note, with interest,
the existence of a similar board (from DY-4 Systems) using a 68010 as its
on-board processor, which would fix some of the cross-support issues.
We probably won't be buying anything right away, though.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry