[rescue] AUI duplex [was Re: New SPARCStation 10 owner, needs help with some issues though.]
Carl R. Friend
crfriend at rcn.com
Sat Feb 6 11:22:11 CST 2016
On 02/06/2016 09:21 AM, Mouse wrote:
>> Lance interfaces work just fine. Sometimes, depending on what sort
>> of comms gear you're plugging into, it may require pinning the switch
>> at 10Mb/s half-duplex, but from my experience, that's it.
> Yeah, but a lot of low-end switches are sufficiently unmanaged that
> that's not possible on them. It's one reason I keep 10Mbit hubs
> around; I have some machines that have trouble with autoneg but are
> fine when connected to a dumb 10-only hub.
That's as good a reason as any to try and avoid low-end kit. Keeping
some "elder" comms gear around certainly cannot hurt, though, and gives
one the maximum benefit of "doing it the old way".
>> AUI -- contemplate that for a moment and then realise why "duplex" is
> I _think_ AUI uses separate pins for transmit and receive, so the only
> reason it couldn't do full-duplex is that the usual driving electronics
> isn't designed for it (not surprising, since, as you say, it comes from
> the days of shared broadcast medium).
Yes, different twisted-pairs in the transceiver-cable. I suppose
AUI *could* be convinced to do full-duplex, but since the original
design called for a single length of coax it would have been rather
>> Nobody is going to get anywhere close to 10 Mbps through any sort of
>> a half-duplex Ethernet connection. It's just not going to happen.
> My experience disagrees. I'm typing this on a SS20, and I just
> transferred ten megabytes to it from another machine on my house LAN
> and it took ten seconds according to "date", meaning it was somewhere
> between nine-plus-epsilon and eleven-minus-epsilon seconds; watching my
> on-screen clock ticks makes me think it was very close to ten seconds.
Once some of the snow melts, I'll see if I can scavenge up enough
bits to commission a test length of 10-Base-5 (good old-fashioned
"Etherhose") and see what various machines can do with it. Using a
switch in the middle stretches the validity of the test a little bit.
Recall that before transmitting, a machine had to first listen to see
if it was safe to "talk". That takes time; and if one adds collisions
into the mix things can stretch out quite quickly with the result
being less bandwidth that actually gets used.
>> "Ethernet" of today looks nothing like its genesis, save for the
>> pitifully small MTU given the speeds now attainable
> If you're talking about the physical layer, yes.
Yes, I was speaking of the physical layer -- and the physical
layer still has resonances in the modern realm which tends to
confuse people. Broadcast NIS and NFS-over-UDP are examples of
this which led me to bring in one of my old-school vampire-tap
transceivers and a length of Etherhose as a prop for use in trying
to convince "those who knew better than I" that UDP wasn't a
problem (the switches were dropping it at rate-change points in
the multi-speed network resulting in massive retransmissions) when,
in fact, it was.
NFS-over-UDP can get so unreliable that a number of years ago
in my previous job I wrote a (not-so) tongue-in-cheek piece on it
when I accidentally duplicated the scenario at home. It was called
"A Tale of Two Protocols -- or, The Day the Music Died". I probably
have it lying about someplace if anybody's interested.
And, yes, my previous job sucked. I spent ten out of twelve years
> But at slightly
> higher layers, there are respects in which it is rather similar,
> notably the address space (48-bit MACs), the frame format (destination
> MAC, source MAC, two bytes of type, payload, checksum), and support for
Don't let a vague similarity at the user layer fool you. It's
not about coax any longer, and hasn't been for decades. It's all
crossbar-switches and connection-oriented, much in the same manner
that telephony used to work -- when it worked before VOIP and
| Carl Richard Friend (UNIX Sysadmin) | Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:crfriend at rcn.com +---------------------+
| http://users.rcn.com/crfriend/museum | ICBM: 42:20N 71:43W |
More information about the rescue