[rescue] AUI duplex [was Re: New SPARCStation 10 owner, needs help with some issues though.]

[Carl R. Friend]

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
>> meaningless.
>
> 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
meaningless.
>
>> 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
abjectly miserable.

> 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
> broadcast/multicast.

    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
cellular, mind.

    Cheers!

-- 
+------------------------------------------------+---------------------+
| 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 |
+------------------------------------------------+---------------------+