IBM 3174 C 6.4 Microcode Disks?

[Grant Taylor]

On 2/22/19 6:15 PM, Paul Koning via cctalk wrote:
> SNAP as a way of encoding bridged Ethernet II frames applies only to 
> non-Ethernet LANs, all of which have larger MTU.

Nope.  I'm quite sure that NetBIOS used SNAP on Ethernet.

I'm betting that 3174's Ethernet interfaces also used DLC / LLC2 via SNAP.

IPX could run over SNAP on Ethernet if you wanted to.

> SNAP covers more than encoding bridged Ethernet II.  It was intended 
> as a way to carry protocols in 802 format for which you couldn't get 
> a SSAP/DSAP code point (such as private protocols).  DEC did this in 
> various places, it's perfectly straightforward.

*nod*

> Perhaps some implementations make it hard to support both simultaneously, 
> but there is no technical reason to make such a mistake.

I feel like putting TCP/IP in SNAP on Ethernet is a mistake in that most 
OSs will not know how to work with TCP in a SNAP frame as they will be 
expecting Ethernet II frames.

I don't know that there's a technical reason per say.  I do think that 
there is a market reason.

> The pretense that broadcast is different from multicast is just a 
> confusion.  The description says that it is used for traffic that every 
> station wants to get.  If you take that literally, no protocol should 
> use broadcast, because there isn't any protocol that every station on 
> every LAN wants to see.  For example, ARP should have used multicast 
> for the same reason DECnet does: it is traffic that is interesting to 
> stations which speak that protocol, and only to those stations.

Flip things on their head.  I think it's that the sender wants every 
receiving station to see.

> I think that's right.  For 802.5, that is.

ACK

> In FDDI the frames are "stripped" by the sending station, which allows 
> things like network monitors in promiscuous mode to work just like 
> on Ethernet

Intriguing.

> The claim of collapse under load -- meaning throughput goes down beyond 
> a certain load level -- is valid for ALOHA and similar networks, but 
> not on Ethernet because it uses carrier sense and collision detect. 
> Under overload it runs at close to full utilization.

Okay.  So you weren't saying that Token Ring had problems as much as you 
were saying that Ethernet can work at close to capacity.

I remember seeing references to Ethernet would start to have problems 
with increasing backouts as the number of stations wanting to transmit 
at the same time would grow.

Though that may be that the average throughput of a given station may go 
down while the network segment itself is closer to saturation.

> I'm trying to reconstruct what exactly the difference is, but I never 
> knew 802.5 well and my FDDI brain cells are all from around 1986...

Fair.



-- 
Grant. . . .
unix || die