RE: Retro networking / WAN communities
Texas Instruments was the first second source to create a Token Ring chipset, the TMS380. When we pointed out to them some the IBM’ism features we’d prefer to be fixed for 802.x compatibility they claimed they couldn’t because of legal agreements with IBM. The TI chipset had other issues and was not register compatible with IBM’s implementation. Later IBM worked with National Semiconductor to release the TROPIC chipset that was used by Madge and others. Some info I found here: https://www.ardent-tool.com/NIC/TROPIC.html Dave. Date: Wed, 13 Apr 2022 20:25:25 + From: Wayne S Subject: Re: Retro networking / WAN communities There is some mention of Token Ring vs Ethernet here. IIRC, One issue that was pointed out was that IBM was the only single source for TR chips so the price of token ring could be kept artificially high. Was there ever a second or third source for token ring chips? Sent from my iPhone > On Apr 12, 2022, at 14:11, Grant Taylor via cctalk > wrote: > > ?On 4/12/22 3:03 PM, Chuck Guzis via cctalk wrote: >> I'll bow to the experts and refer to the things as a "boxes with > the blank>n capabilities". > > I'm definitely not an expert. Just some random > on the Internet who has things to say. ;-) > >> That should pretty much cover the terrain. > > As some random on the Internet who has things to > say I actually value "boxes with n capabilities" as it > lets me know if I should treat the as a specific thing or > a generic class description. E.g. Hoover brand vs Eureka hoover device. ;-) > > > > -- > Grant. . . . > unix || die Sent from Mail for Windows
Re: Retro networking / WAN communities
On 4/12/22 3:03 PM, Chuck Guzis via cctalk wrote: I'll bow to the experts and refer to the things as a "boxes with in the blank>n capabilities". I'm definitely not an expert. Just some random term> on the Internet who has things to say. ;-) That should pretty much cover the terrain. As some random on the Internet who has things to say I actually value "boxes with n capabilities" as it lets me know if I should treat the blank> as a specific thing or a generic class description. E.g. Hoover brand vs Eureka hoover device. ;-) -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/12/22 12:24, Grant Taylor via cctalk wrote: > Details matter. I'll bow to the experts and refer to the things as a "boxes with n capabilities". That should pretty much cover the terrain. --Chuck
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 3:45 PM, John-Paul Stewart via cctalk > wrote: > > > On 2022-04-12 09:49, Paul Koning via cctalk wrote: >> >> Does anyone still remember the other 100 Mb Ethernet-like proposal, I >> think from HP, which added various types of complexity instead of simply >> being a faster Ethernet? > > HP's proposal was called 100BaseVG, aka 100VG-AnyLAN, and could carry > Token Ring frames in addition to Ethernet. Ah, that would certainly be one part of the explanation why it didn't go anywhere. Supporting Token Ring would add a vast amount of complexity for no real benefit. I noticed the Wikipedia article has a wrong and misleading description of the supposed "deterministic" behavior of token rings. It speaks of "consistent performance no matter how large the network became". That, of course, is nonsense. What is true is that, in the absence of errors, token rings have a hard upper bound on the time required to transmit the first frame in the NIC transmit queue. What is always unstated in the marketing documents making that claim is how large that upper bound is. I remember an IBM document that spent 30 or so pages saying "token ring good, ethernet bad". DEC, with some help from 3Com, wrote a detailed paragraph by paragraph refutation of that; I participated in creating that and have a copy somewhere. One of the points IBM made was that determinism claim. So we calculated the worst case transmit latency for a max size 802.5 ring. I don't remember the answer exactly; I'm pretty sure it was over a minute. FDDI is an entirely different protocol, with dramatically better latency at high load than 802.5. (Its ancestor is 802.4, not 802.5.) But even there, the max latency is surprisingly long. Ethernet, on the other hand, is nondeterministic (in the half duplex shared bus topology) but except at insanely high loads is much lower than the latency of any token ring. paul
Re: Retro networking / WAN communities
On 4/11/22 19:27, Paul Koning via cctalk wrote: On Apr 11, 2022, at 1:02 PM, Grant Taylor via cctalk wrote: Hi, Does anyone know of any communities / mailing lists / newsgroups / et al. for retro networking / WAN technologies? I find myself interested in (at least) the following and would like to find others with similar (dis)interests to chat about things. - 10Base5 / 10Base2 / 10BaseT - ISDN - DSL / ADSL / SDSL / HDSL - T1 / E1 - ATM - Frame Relay - ARCnet - PSTN / PBX / PABX I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. I should still have 2 ARCnet ISA cards somewhere
Re: Retro networking / WAN communities
On 2022-04-12 09:49, Paul Koning via cctalk wrote: > > Does anyone still remember the other 100 Mb Ethernet-like proposal, I > think from HP, which added various types of complexity instead of simply > being a faster Ethernet? HP's proposal was called 100BaseVG, aka 100VG-AnyLAN, and could carry Token Ring frames in addition to Ethernet. https://en.wikipedia.org/wiki/100BaseVG
Re: Retro networking / WAN communities
On 4/12/22 12:08 PM, Chuck Guzis via cctalk wrote: Hub is a nebulous term. Yes and no. Hub can be a generic "connects things" a la. hub of wires. Or it can be a technical thing, e.g. layer 1 device. For example, I've got a couple of NS "Datamover" 10Base boxes that take the WAN connection via 10base2 and distribute it via 10BaseT; absolutely dumb boxes without any intelligence at all. I believe there has to be some amount of intelligence, thus not absolutely dumb, in that it's connecting a WAN (quintessentially not Ethernet) with a disparate networking technology, Ethernet. The differences between the two require /some/ amount of intelligence. I also have some Farallon 100baseT boxes that appear to provide filtering and logon for WAN connections. That screams something more complex than a switch, much less hub, to me. In my opinion, it strongly shouts "router". Of course, many hubs include NAT, port moderation, etc. Nope. Network Address Translation operates on the 3rd OSI layer, specifically Network Addresses. L2 switches (operating on source / destination MAC addresses) and L1 hubs don't understand, much less, alter the L3 network address. There are many people that use "hub" in an extremely generic sense of the word as something that connects things together. But is is absolutely not a technical term for what is being done. Personally, I don't care, so long as the things work. Details matter. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/12/22 11:44 AM, Todd Goodman via cctalk wrote: To me a hub is a layer 1 device (physical layer) that doesn't look at the traffic at all while the bridge does look at the traffic and generally implements 802.1d Spanning Tree Protocol and processes BPDUs. I think that you touch on a very germane point. Hubs operate at L1. Switches operate at L2 (and L1). Routers operate at L3 (and L2 and L1). I've seen MANY L2 switches that didn't implement STP. The quintessential Linksys / Netgear / Dlink 4~8 port switch comes to mind. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/12/22 1:05 PM, Paul Koning via cctalk wrote: But that's a marketing document. Eh ... Maybe. Cisco has plenty of purely technical documentation on the same subject with effectively similar technical information. That was just the first link that I found that wasn't a "hub" in the social sense where people / community / etc gather to communicate; a la this mailing list is a hub of technical minds & discussion. That doesn't match how I see the history. From the DEC point of view, non-learning packet switches did not exist. We sold either real bridges, or routers, or (early on) repeaters. I never heard of a DEC customer using non-learning devices; if anyone had and ran into trouble I'm certain our answer would have been "please use a real bridge". That may be the case inside the DEC ecosystem / community. I don't know. I do think "please use a real bridge" is definitely a sensible response. I know I've said "please use a switch instead of a hub" multiple times. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 3:11 PM, Grant Taylor via cctalk > wrote: > > On 4/12/22 11:41 AM, Paul Koning via cctalk wrote: >> ... >> Spanning tree is indeed another algorithm / protocol, but it's a control >> plane algorithm with relatively easy time constraints, so it's just SMOP. > > I guess I always assumed that spanning tree came along /after/ and / or > /independently/ of bridging / switching. > > After all, the BPDU in spanning tree is "Bridge ..." so that name tends to > imply to me that it came about /after/ bridges were a thing on at least some > level. No, definitely not. The DECbridge-100 included two critical elements: learning / selective forwarding, and spanning tree. Both were day-one features. paul
Re: Retro networking / WAN communities
On 4/12/22 11:41 AM, Paul Koning via cctalk wrote: I don't know anything about the 3 Mb/s prototype other than that it existed. When I speak of Ethernet and its "day 1" I mean 10 Mb/s Ethernet as defined by the DEC/Intel/Xerox spec. Okay. Fair enough. I surmise that we're talking about Ethernet II a.k.a. the Digital / Intel / Xerox that was commercialized. Repeaters are a core part of that spec, and they were among the first wave of products delivered by DEC. I can see how the need for repeaters was learned during Ethernet research at Xerox PARC and incorporated into Ethernet II / DIX from the start. I no longer remember. That's possible, or perhaps they were a number of small segments each with a handful of stations on them. That would make /some/ sense. E.g. have a 10Base2 segment for a set of cubicles and then link the multiple segments together with a multi-port bridge. That's true but only part of the story. For one thing, as I said, both mechanisms were part of bridges from the start (at least from the start of DEC's bridges, which may not be quite the very earliest ever but certainly are the earliest significant ones). Fair enough. The learning part of bridging is actually the hard part. ... I feel like the conceptual algorithm / logic is simple. I concede that implementing it within timing requirements could be non-trivial ~> difficult. Spanning tree is indeed another algorithm / protocol, but it's a control plane algorithm with relatively easy time constraints, so it's just SMOP. I guess I always assumed that spanning tree came along /after/ and / or /independently/ of bridging / switching. After all, the BPDU in spanning tree is "Bridge ..." so that name tends to imply to me that it came about /after/ bridges were a thing on at least some level. That rings a bell. Someone reminded me of 100Base-T4. T4 rings a bell for me. -- It reminds me of some references to T2 and T8. It seems as if there was great conflation between the number being reference to wires; 4 vs 8, and pairs; 2 vs 4, respectively. In any case, there were two proposed, one that made it. The other might have gone as far as one or two shipping products, but no further than that. Yep. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 2:51 PM, Grant Taylor via cctalk > wrote: > > On 4/12/22 11:44 AM, Paul Koning wrote: >> In my experience, "hub" is a vague marketing term. ... >> Non-learning layer 2 packet switching devices to me are hypothetical beast, >> I never met one and I'm glad I didn't. > > Nope. Hubs are definitely not a marketing term, nor a hypothetical beast. > > See the quote from the following Cisco page. But that's a marketing document. > ... >> Building such a thing would be a silly thing to do in my view. > > Well, it may be silly, but a non-learning device, or "hub", was ~> is very > much a thing that was mass marketed and sold all over the place. > > Switches supplanted hubs for obvious reasons in the mid-to-late '90s. That doesn't match how I see the history. From the DEC point of view, non-learning packet switches did not exist. We sold either real bridges, or routers, or (early on) repeaters. I never heard of a DEC customer using non-learning devices; if anyone had and ran into trouble I'm certain our answer would have been "please use a real bridge". paul
Re: Retro networking / WAN communities
> On 04/12/2022 12:42 PM Wayne S via cctech wrote: > > > Thanks for the info about IMP. > But now i’d have to question IMP routers being around in 1970 since the > internet wasn’t around yet. > > The first response of "Interface" Message Processor is more correct. There was a LOT of networking before what we call the "Internet" now. It derived from the Arpanet in the 60s, which is where the IMPs were used. https://en.wikipedia.org/wiki/ARPANET#:~:text=The%20Advanced%20Research%20Projects%20Agency,technical%20foundation%20of%20the%20Internet. Will
Re: Retro networking / WAN communities
On 4/12/22 11:44 AM, Paul Koning wrote: In my experience, "hub" is a vague marketing term. ... Non-learning layer 2 packet switching devices to me are hypothetical beast, I never met one and I'm glad I didn't. Nope. Hubs are definitely not a marketing term, nor a hypothetical beast. See the quote from the following Cisco page. --8<-- Are an Ethernet switch and hub the same? No. While they are both examples of data network hardware, a hub is a Layer 1 device, which is part of the physical transport layer and acts as a broadcast/aggregator but does not manage any of the traffic. An Ethernet switch manages the flow of data, directing data it receives in one port to another port based on information in a data packet's header, namely the sending and receiving MAC addresses. The switching process significantly improves the efficiency of the network as opposed to a hub. -->8-- Link - What Is an Ethernet Switch? - https://www.cisco.com/c/en/us/products/switches/what-is-an-ethernet-switch.html#~q-a Building such a thing would be a silly thing to do in my view. Well, it may be silly, but a non-learning device, or "hub", was ~> is very much a thing that was mass marketed and sold all over the place. Switches supplanted hubs for obvious reasons in the mid-to-late '90s. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On Mon, 11 Apr 2022, Grant Taylor via cctalk wrote: > > I think "hub" is another word for "repeater" (just like "switch" is another > > word for "bridge"). > > Interesting. > > Do you know of any documentation, preferably not marketing materials, that > used "repeater" in lieu of "hub"? As I recall back in mid 1990s nobody around at the university used to call plain 10BASE2 repeaters hubs. We'd only call multiport 10BASE-T devices hubs (aka concentrators), where each port only serves one device in a point-to-point topology (i.e. no shared medium such as with 10BASE5 or 10BASE2). We had a bunch (4 or 5) of IIRC 5-port 10BASE2 repeaters for our network at our hall of residence. Each 10BASE2 port served ~20 hosts so as not to exceed 10BASE2's maximum segment length. I'm not sure anymore if the repeaters had an AUI port; I think they did, but if so, it wasn't used. They were connected into one network via a bridge, which was an 80286 PC equipped with a corresponding number of NE2000 clones and running a piece of DOS software called Kbridge. It was to reduce network congestion, which often happened anyway when multiple groups of people played networked (IPX) Doom all at a time. Also nobody would call a device a switch if it didn't do cut-through. We'd call devices doing store-and-forward only bridges; after all there's no actual circuit switching in store-and-forward. I guess these terms became fuzzier with time as non-techies started confusing them. FWIW, Maciej
Re: Retro networking / WAN communities
On 4/12/22 10:44, Todd Goodman via cctalk wrote: > To me a hub is a layer 1 device (physical layer) that doesn't look at > the traffic at all while the bridge does look at the traffic and > generally implements 802.1d Spanning Tree Protocol and processes BPDUs. Hub is a nebulous term. For example, I've got a couple of NS "Datamover" 10Base boxes that take the WAN connection via 10base2 and distribute it via 10BaseT; absolutely dumb boxes without any intelligence at all. I also have some Farallon 100baseT boxes that appear to provide filtering and logon for WAN connections. Of course, many hubs include NAT, port moderation, etc. Personally, I don't care, so long as the things work. --Chuck
Re: Retro networking / WAN communities
Yes, that's the way the term was used by DEC. There have long been many things in our business that were called by multiple names. Gateway is one (router, protocol translator). Dataset (modem or file), file (file as we know it, disk drive) are other examples. paul > On Apr 12, 2022, at 2:01 PM, Wayne S wrote: > > Good clarification. > In my day, gateway was some unique device or software that provided access to > a service or another non-standard device. > Think a device that dials out to batch send information to a specific > service. > Router meant networking within the company. > Different times. > > Sent from my iPhone > >> On Apr 12, 2022, at 10:49, Paul Koning via cctalk >> wrote: >> >> >> >>> On Apr 12, 2022, at 1:20 PM, Grant Taylor via cctalk >>> wrote: >>> On 4/12/22 10:11 AM, Wayne S wrote: Wiki says ethernet became commercially available in 1980 and invented in 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? >>> >>> I feel like IMPs were "routing" and could be considered "routers" long >>> before Ethernet was a thing. >> >> Exactly. For that matter, DECnet included routing before Ethernet came out >> (in Phase III, with DDCMP links). And Typeset-11 did routing before DECnet >> did, starting around 1977. >> >> I think the term used in the IMP days was "gateway" but by today's >> terminology they are routers. >> >> paul >>
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 1:20 PM, Grant Taylor via cctalk > wrote: > > On 4/12/22 10:11 AM, Wayne S wrote: >> Wiki says ethernet became commercially available in 1980 and invented in >> 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? > > I feel like IMPs were "routing" and could be considered "routers" long before > Ethernet was a thing. Exactly. For that matter, DECnet included routing before Ethernet came out (in Phase III, with DDCMP links). And Typeset-11 did routing before DECnet did, starting around 1977. I think the term used in the IMP days was "gateway" but by today's terminology they are routers. paul
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 1:44 PM, Todd Goodman via cctalk > wrote: > > On 4/12/2022 1:28 PM, Grant Taylor via cctalk wrote: >> On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: >>> The big difference in my mind between bridge and switch is: >>> >>> * Switches learn what port given MACs are on and only sends unicast >>> traffic destined for that MAC address on that port and not all >>> * Bridges send unicast traffic to all ports >> >> So what would differentiate the bridge (using your understanding) from a hub? > To me a hub is a layer 1 device (physical layer) that doesn't look at the > traffic at all while the bridge does look at the traffic and generally > implements 802.1d Spanning Tree Protocol and processes BPDUs. For 802.3, a physical layer relay is called a repeater. Other LAN types, if they have such things, may use other names; for example FDDI calls it a concentrator. paul
Re: Retro networking / WAN communities
On 4/12/2022 1:28 PM, Grant Taylor via cctalk wrote: On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: The big difference in my mind between bridge and switch is: * Switches learn what port given MACs are on and only sends unicast traffic destined for that MAC address on that port and not all * Bridges send unicast traffic to all ports So what would differentiate the bridge (using your understanding) from a hub? To me a hub is a layer 1 device (physical layer) that doesn't look at the traffic at all while the bridge does look at the traffic and generally implements 802.1d Spanning Tree Protocol and processes BPDUs. Todd
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 1:25 PM, Grant Taylor via cctalk > wrote: > > On 4/12/22 8:50 AM, Paul Koning via cctalk wrote: >> A device that doesn't do address learning and floods unicast frames is not a >> bridge but rather a non-standard piece hardware. > > I feel like a "hub" qualifies as "a device that doesn't do address learning > and floods unicast frames". > > To me, the fundamental difference between a hub and a switch / bridge is > address learning. > > I can't tell if your (quoted) statement is specific to /just/ bridges / > switches or could include hubs. Your first comment addresses bridges > directly, thus meaning that your second non-targeted comment might target > more. In my experience, "hub" is a vague marketing term. It might mean a backplane into which networking modules are plugged -- the DEChub-90 and DEChub-900 are examples. It might mean a chassis accepting networking cards that offer repeater, bridging, or other services -- I think Chipcom and Cabletron used the term in that fashion. Non-learning layer 2 packet switching devices to me are hypothetical beast, I never met one and I'm glad I didn't. Building such a thing would be a silly thing to do in my view. So no, I don't think I would call that a "hub" because all the "hubs" I ever ran into were something different entirely. paul
RE: Retro networking / WAN communities
I could be wrong, but I always thought the distinction between hub and bridge was, all traffic is broadcast to all ports on a hub. A bridge allows traffic to be segregated (albeit still on the same subnet). 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos -Original Message- From: cctalk On Behalf Of Grant Taylor via cctalk Sent: Tuesday, April 12, 2022 1:29 PM To: cctalk Subject: Re: Retro networking / WAN communities On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: > The big difference in my mind between bridge and switch is: > > * Switches learn what port given MACs are on and only sends unicast > traffic destined for that MAC address on that port and not all > * Bridges send unicast traffic to all ports So what would differentiate the bridge (using your understanding) from a hub? -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 12:45 PM, Grant Taylor via cctalk > wrote: > > On 4/12/22 7:49 AM, Paul Koning via cctalk wrote: >> ... >> The concept of a repeater goes back to day 1 of Ethernet; you'll find them >> in the D/I/X Ethernet spec. And they were part of the first batch of >> Ethernet products from DEC. > > Repeaters existing from day 1 of Ethernet sort of surprises me. > > I wonder if there is some difference in the original 3 Mbps Ethernet at Xerox > PARC vs the 10 Mbps Ethernet (II?) that was commercialized. I don't know anything about the 3 Mb/s prototype other than that it existed. When I speak of Ethernet and its "day 1" I mean 10 Mb/s Ethernet as defined by the DEC/Intel/Xerox spec. Repeaters are a core part of that spec, and they were among the first wave of products delivered by DEC. > ... >> I first saw "structured wiring" -- the star wiring with a hierarchy of >> wiring closets and devices -- around 1986, in the new Littleton King Street >> DEC building. It had distribution cabinets at the end of each row of >> cubicles. These looked just like standard office supplies storage cabinets, >> with shelves; inside you'd find a bridge and a couple of DEMPR repeaters, >> connected to 10Base2 coax drops to each cubicle. > > Interesting use case. -- Now I'm wondering if each station run was standard > 10Base2 with it's T connector and terminator. I no longer remember. That's possible, or perhaps they were a number of small segments each with a handful of stations on them. >> ... > > I now feel the need to call out what I think are two very distinct things > that need to be differentiated: > > 1) Learning of which port a source MAC address is on for the purposes of not > sending a frame out to a destination segment when the location of the > destination is known. > 2) Spanning Tree / 802.1D learning the path to the root of the tree. > > The former is a fairly easy algorithm that doesn't require anything other > than passive listening for data collection. The latter requires introduction > of a new type of active traffic, namely BPDUs. That's true but only part of the story. For one thing, as I said, both mechanisms were part of bridges from the start (at least from the start of DEC's bridges, which may not be quite the very earliest ever but certainly are the earliest significant ones). The learning part of bridging is actually the hard part. It involves (a) extracting the SA of each received address, (b) looking it up, in very short time, in a large address table (8k entries in the original DECbridge-100), (c) timing out each one of those addresses. And then also (d) looking up the DA of a received packet in that table and (e) if found, forwarding the packet only to the port for that address, or dropping it if output port == input port. (a) is easy, (b) through (d) are not. And (d)/(e) are the purpose of the exercise, it is why bridged networks have better scaling properties than repeater based networks. If you consider a two port 10 Mb Ethernet bridge, steps (b) and (d) amount to two table lookups every 30 microseconds (minimum packet interval across two ports), and step (b) includes restarting the aging timer for that address. With early 1980s technology this is a seriously hard problem; as I recall, in the DECbridge-100 it involved a hardware assist device to do the table lookup. And (c) is not easy either, it required the invention of the "timer wheel" algorithm which has the properties that starting, stopping, and keeping N timers is O(1) i.e., independent of N. (Expirationn of n timers is O(n), but most timers do not expire in this application.) Later on it became possible, with great care, to do these things in software. The DECbridge-900 (FDDI to 6 x 10M Ethernet) has its fast path in a 25 MHz 68040, very carefully handcrafted assembly code, with a bit of help from a 64-entry CAM acting as address cache. It can handle around 60 k packets/second, which means it needs some additional specialized rules to ensure it won't miss BPDUs under overload since it can't do worst case packet arrival at all ports concurrently in the normal forwarding path. We patented that. Spanning tree is indeed another algorithm / protocol, but it's a control plane algorithm with relatively easy time constraints, so it's just SMOP. >> ... >> Does anyone still remember the other 100 Mb Ethernet-like proposal, I think >> from HP, which added various types of complexity instead of simply being a >> faster Ethernet? I forgot what it was called, or what other things it >> added. Something about isochronous mode, perhaps? Or maybe I'm confused >> with FDDI 2 -- another concept that never got anywhere, being much more >> complicated even than regular FDDI. > > I vaguely remember there being multiple 100 Mbps Ethernet specifications. I > think one of them had "Any" in it's name. That rings a bell. Someone reminded me of 100Base
RE: Retro networking / WAN communities
Internet message processor (BBN I think) 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/c/w2hx-channel/videos -Original Message- From: cctech On Behalf Of Wayne S via cctech Sent: Tuesday, April 12, 2022 1:24 PM To: Grant Taylor Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Retro networking / WAN communities What’s an IMP? Don’t know that acronym. Sent from my iPhone > On Apr 12, 2022, at 10:20, Grant Taylor > wrote: > > On 4/12/22 10:11 AM, Wayne S wrote: >> Wiki says ethernet became commercially available in 1980 and invented in >> 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? > > I feel like IMPs were "routing" and could be considered "routers" long before > Ethernet was a thing. > > > > -- > Grant. . . . > unix || die
Re: Retro networking / WAN communities
On 4/12/22 11:23 AM, Wayne S wrote: What’s an IMP? Don’t know that acronym. Interface Message Processor. #ARPANET -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/12/22 7:56 AM, Todd Goodman via cctalk wrote: The big difference in my mind between bridge and switch is: * Switches learn what port given MACs are on and only sends unicast traffic destined for that MAC address on that port and not all * Bridges send unicast traffic to all ports So what would differentiate the bridge (using your understanding) from a hub? -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/12/22 8:50 AM, Paul Koning via cctalk wrote: A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. I feel like a "hub" qualifies as "a device that doesn't do address learning and floods unicast frames". To me, the fundamental difference between a hub and a switch / bridge is address learning. I can't tell if your (quoted) statement is specific to /just/ bridges / switches or could include hubs. Your first comment addresses bridges directly, thus meaning that your second non-targeted comment might target more. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> I'm running into issues with switches not supporting 10 / 100 Mbps management > interfaces for other equipment. Half duplex was apparently deprecated a few years back, and recent switches from Cisco (and probably other vendors) no longer support half duplex. We ran into this at work for long lifetime medical devices.
Re: Retro networking / WAN communities
On 4/12/22 10:11 AM, Wayne S wrote: Wiki says ethernet became commercially available in 1980 and invented in 1973. So if enet was 1980 what were routers routing 10 years earlier in 1970? I feel like IMPs were "routing" and could be considered "routers" long before Ethernet was a thing. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/12/22 7:49 AM, Paul Koning via cctalk wrote: DEC documentation. Thank you. The concept of a repeater goes back to day 1 of Ethernet; you'll find them in the D/I/X Ethernet spec. And they were part of the first batch of Ethernet products from DEC. Repeaters existing from day 1 of Ethernet sort of surprises me. I wonder if there is some difference in the original 3 Mbps Ethernet at Xerox PARC vs the 10 Mbps Ethernet (II?) that was commercialized. Yes, AUI based devices, two port. ACK But the next thing out the door was the DEMPR, "Digital Multi-Port Repeater", an 8 port repeater. I think that's 10Base2. $ResearchList++ I first saw "structured wiring" -- the star wiring with a hierarchy of wiring closets and devices -- around 1986, in the new Littleton King Street DEC building. It had distribution cabinets at the end of each row of cubicles. These looked just like standard office supplies storage cabinets, with shelves; inside you'd find a bridge and a couple of DEMPR repeaters, connected to 10Base2 coax drops to each cubicle. Interesting use case. -- Now I'm wondering if each station run was standard 10Base2 with it's T connector and terminator. That's not where the term "switch" was introduced. And devices like that were called "bridge" by market leaders like DEC -- the two generations of FDDI to Ethernet bridges I mentioned were both called "bridge". I first saw "switch" used as a way to differentiate a (dumb) hub from an intelligent hub type of functionality. Also, the general operation of the device is the same whether it does MAC frame tweaking or not, 802.1d applies unchanged. Ethernet to non-Ethernet bridges have to do some tinkering with Ethernet protocol type frames (which is where SNAP comes in, all nicely standardized in the FDDI days). For 802.5 they also have to deal with the misnamed "functional" addresses, but that's not hard. I now feel the need to call out what I think are two very distinct things that need to be differentiated: 1) Learning of which port a source MAC address is on for the purposes of not sending a frame out to a destination segment when the location of the destination is known. 2) Spanning Tree / 802.1D learning the path to the root of the tree. The former is a fairly easy algorithm that doesn't require anything other than passive listening for data collection. The latter requires introduction of a new type of active traffic, namely BPDUs. There also was such a thing as a "source routing bridge", an 802.5 only bad idea invented by IBM and sold for a while until the whole idea faded away. We are actually seeing "source routing" make a resurgence in IPv6 via Segment Routing. I think "hub" is what DEC called the chassis that these boxes could plug in to. I understand now. Yes, that's annoying indeed. Yes, quite annoying. I could actually see the use for a card that could go into non-fixed configuration switches that provided a few 10/100 ports specifically for this purpose. So yes, it's theoretically part of the spec. As you said, it doesn't seem to be in actual use. ACK Curious. Clearly such things are possible. But FDDI came out well before HSTR, and it was crushed by 100 Mb Ethernet. All the reasons for that to happen would apply much more so for HSTR. Yep. Lab vs actual commercialized products are quite different. Then there's what the market purchases and uses. Does anyone still remember the other 100 Mb Ethernet-like proposal, I think from HP, which added various types of complexity instead of simply being a faster Ethernet? I forgot what it was called, or what other things it added. Something about isochronous mode, perhaps? Or maybe I'm confused with FDDI 2 -- another concept that never got anywhere, being much more complicated even than regular FDDI. I vaguely remember there being multiple 100 Mbps Ethernet specifications. I think one of them had "Any" in it's name. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 11:40 AM, Todd Goodman wrote: > > > On 4/12/2022 10:50 AM, Paul Koning wrote: >> >>> ... >> >> Learning has always been part of what bridges do. It's a core part of the >> DEC bridge spec, and a core part of the DECbridge-100 functionality. It is >> the reason why Tony Lauck and George Varghese invented the "timer wheels" >> scheme for keeping 8000 timers in constant time. >> >> A device that doesn't do address learning and floods unicast frames is not a >> bridge but rather a non-standard piece hardware. I don't actually know if >> anyone ever implemented such a device. Certainly I've never seen one or >> built one myself, even though what I built was called "bridge". >> >> paul > > > I'm not talking about pre-standard DEC devices. > > I can show you a standard commodity bridge from multiple vendors right now > that will allow you to monitor unicast traffic destined for other ports just > by plugging in to one of the other ports on the bridge. > > I don't have my 802.1d spec I implemented a bridge from in the 90s I do have 802.1d, but it's a box. I know for a fact that learning is part of it, just as it was in the DEC spec, for the obvious reason that they are basically the same architecture. So any compliant bridge forwards unicast traffic to the port on which that address is known to be, flooding only to unknown addresses. paul
Re: Retro networking / WAN communities
Grant Taylor wrote: > My understanding is that 4.3BSD that ran on VAXes had support for NCP. 4.3BSD released in 1986 was long after ARPANET switched from NCP to TCP/IP. Apparently early TCP/IP support was added to 4.1a in 1981. I'm going out on a limb to claim BSD never had NCP support.
Re: Retro networking / WAN communities
On 4/12/2022 10:50 AM, Paul Koning wrote: On Apr 12, 2022, at 10:44 AM, Todd Goodman wrote: On 4/12/2022 10:12 AM, Paul Koning wrote: On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk wrote: ... The big difference in my mind between bridge and switch is: * Switches learn what port given MACs are on and only sends unicast traffic destined for that MAC address on that port and not all * Bridges send unicast traffic to all ports Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. paul You snipped the part where I said except for ports that should not receive the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d and that if that fails you end up with a broadcast storm. Well, I didn't mention STP in 802.1d specifically because I thought it was obvious. Bridges were useful even after switches arrived to allow monitoring of traffic on any port of the bridge. It was useful before switches got port mirroring and even after as it didn't require any configuration. Yes, I snipped part of what you said, but that doesn't affect my point. Learning has always been part of what bridges do. It's a core part of the DEC bridge spec, and a core part of the DECbridge-100 functionality. It is the reason why Tony Lauck and George Varghese invented the "timer wheels" scheme for keeping 8000 timers in constant time. A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. I don't actually know if anyone ever implemented such a device. Certainly I've never seen one or built one myself, even though what I built was called "bridge". paul I'm not talking about pre-standard DEC devices. I can show you a standard commodity bridge from multiple vendors right now that will allow you to monitor unicast traffic destined for other ports just by plugging in to one of the other ports on the bridge. I don't have my 802.1d spec I implemented a bridge from in the 90s But whatever, I've used that capability a lot over the years on a lot of different bridges so have nothing more on the topic Todd
Re: Retro networking / WAN communities
On Tue, Apr 12, 2022 at 5:55 AM Grant Taylor via cctalk wrote: > > On 4/11/22 9:55 PM, Tony Duell via cctalk wrote: > > I am not sure what the actual distinction is, but a 'managed bridge' > > turned up at the local antique market (!) some weeks back. It has a > > pair of AUI ports and from the amount of logic/processor power inside > > it does a lot more than just pass packets from one port to the other, > > Would you be willing to share pictures? I can do a little better than that, I think. How about reverse-engineered schematics. :-) It'll take a little time to dig them out (schematics and photos) but I am certainly happy to share them. > > > The main board contains a pair of ethernet interfaces (AM7990 based), > > a 68020 processor, ROM, RAM, etc. A board on top of of it called the > > 'FLUT' (Frame Look Up Table?) contains a CY7C901 (16 bit slice ALU -- > > think of it as 4 off 2901 + carry loglc), a 29C10 seqencer, etc > > Hum > > > After removing the leaking NiCd from the mainboard and repairing the > > corroded tracks it powers up and passes the self-tests. No idea what > > I'll use it for, but... > > That seems like it would be an interesting piece of networking history > to own. If you're into that sort of thing. ;-) It cost \pounds 5.00 (so <$10). At that price I bought it. If only for the 2U case, the SMPSU, the LCD module, etc. But since it powers up and passes the self tests I am keeping it whole. It is an odd bit of history, too many people preserve processors and not the other hardware that went with them. -tony
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 10:44 AM, Todd Goodman wrote: > > > On 4/12/2022 10:12 AM, Paul Koning wrote: >> >>> On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk >>> wrote: >>> ... >>> The big difference in my mind between bridge and switch is: >>> >>> * Switches learn what port given MACs are on and only sends unicast >>> traffic destined for that MAC address on that port and not all >>> * Bridges send unicast traffic to all ports >> Absolutely not. The only standard device that forwards unicast to all ports >> is the repeater. I don't know of any packet forwarding device that sends >> unicast traffic to all ports; certainly no such thing can be found in any >> standard. >> >> Learning was introduced by DEC in the DECbridge 100 (along with spanning >> tree); IEEE later standardized this, with some small mods, in 802.1d. >> >> paul > > You snipped the part where I said except for ports that should not receive > the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d > and that if that fails you end up with a broadcast storm. > > Well, I didn't mention STP in 802.1d specifically because I thought it was > obvious. > > Bridges were useful even after switches arrived to allow monitoring of > traffic on any port of the bridge. It was useful before switches got port > mirroring and even after as it didn't require any configuration. Yes, I snipped part of what you said, but that doesn't affect my point. Learning has always been part of what bridges do. It's a core part of the DEC bridge spec, and a core part of the DECbridge-100 functionality. It is the reason why Tony Lauck and George Varghese invented the "timer wheels" scheme for keeping 8000 timers in constant time. A device that doesn't do address learning and floods unicast frames is not a bridge but rather a non-standard piece hardware. I don't actually know if anyone ever implemented such a device. Certainly I've never seen one or built one myself, even though what I built was called "bridge". paul
Re: Retro networking / WAN communities
On 4/12/2022 10:12 AM, Paul Koning wrote: On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk wrote: ... The big difference in my mind between bridge and switch is: * Switches learn what port given MACs are on and only sends unicast traffic destined for that MAC address on that port and not all * Bridges send unicast traffic to all ports Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. paul You snipped the part where I said except for ports that should not receive the traffic due to blocked ports from the Spanning Tree Protocol in 802.1d and that if that fails you end up with a broadcast storm. Well, I didn't mention STP in 802.1d specifically because I thought it was obvious. Bridges were useful even after switches arrived to allow monitoring of traffic on any port of the bridge. It was useful before switches got port mirroring and even after as it didn't require any configuration. Todd
Re: Retro networking / WAN communities
On 4/12/22 12:21 AM, Lars Brinkhoff via cctalk wrote: Are you saying there's a BSD Unix with Arpanet NCP? If so, where? My understanding is that 4.3BSD that ran on VAXes had support for NCP. My naive assumption is that there is enough of it still around that it may be possible to bring up an NCP connection between multiple systems. Perhaps that's a /mis/understanding on my part. I'd love to learn supporting information either way. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 12:52 AM, Grant Taylor > wrote: > > ... > I vaguely remember that there were three main forms of switching: store and > forward, cut-through, and a hybrid of the two. My understanding is that S&F > had the ability to sanity check (checksum?) frames and only re-send out valid > / non-corrupted frames. Conversely C.T. could not do this sanity checking > and thus could re-send corrupted frames. The 3rd form did a sanity check on > the first part of the frame. -- I think. The normal type of bridge / switch is the store and forward type, which discards bad packets and forwards only good ones. Cut through means starting to forward a packet before the end of it has been received. That necessarily means forwarding it without knowing if it's a good frame (good CRC, length, alignment if applicable). The remaining question is what happens with the cut-through frame when the end of packet arrives and is seen to be bad. One possibility is to propagate the received packet exactly, in which case (barring an unfortunate additional data error) it will be seen as bad by the eventual recipient. The other possibility is to force an explicit abort of some sort to make sure the packet is seen as bad. For a mixed LAN type bridge, only the second option is valid (because you aren't doing CRC forwarding in that case). Of course, a lot of mixed type bridges are also mixed speed, where cut through isn't really an option. Theoretically you could have, say, 100 Mb/s Ethernet to FDDI, but in practice I don't know if those existed and doubt that, if so, they used cut through. You can't do sanity checking on the frame beginning; there isn't anything that gives you a clue whether the start is valid or not. At least not apart from trivial checks like "source address can't be a multicast address". The only data link protocol I can think of that lets you check the frame beginning is DDCMP. paul
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 9:56 AM, Todd Goodman via cctalk > wrote: > ... > The big difference in my mind between bridge and switch is: > > * Switches learn what port given MACs are on and only sends unicast > traffic destined for that MAC address on that port and not all > * Bridges send unicast traffic to all ports Absolutely not. The only standard device that forwards unicast to all ports is the repeater. I don't know of any packet forwarding device that sends unicast traffic to all ports; certainly no such thing can be found in any standard. Learning was introduced by DEC in the DECbridge 100 (along with spanning tree); IEEE later standardized this, with some small mods, in 802.1d. paul
Re: Retro networking / WAN communities
> Begin forwarded message: > > From: Grant Taylor via cctalk > Subject: Re: Retro networking / WAN communities > Date: April 12, 2022 at 2:08:22 AM EDT > To: Wayne S , "General Discussion: On-Topic and > Off-Topic Posts" > Reply-To: Grant Taylor , "General > Discussion: On-Topic and Off-Topic Posts" > > On 4/11/22 11:38 PM, Wayne S wrote: >> In the beginning there was thick ethernet limited to 100 m. > > Um > > I *REALLY* thought the 5 & 2 in 10Base5 and 10Base2 was the number of > hundreds of meters that the cable segment could exist on it's own. > > My understanding is that the 100 meter limit came about with 10Base-T. Yes, that is correct. 10Base5 is 500 meter segment limit, 10Base2 is 200 meters max. There are some other small differences: 10Base5 wants you to put the transceiver attachments on the marks on the cable (to avoid having impedance bumps aligned with the wave length); 10Base2 omits that requirement. See the 802.3 spec for all the gory details. >> People wanted computers that were on different floors connected together >> between floors and buildings. That exceeded the 100 meter spec so the >> repeater was born to connect two 100 m thick ethernet seqments. > > I feel like even only 100 meters / 300(+) feet gives quite a bit of > flexibility to connect multiple floors. Especially if you consider the AUI > drop cable. > > Aside: I'm not sure how long an AUI drop cable could be. I'm anticipating > between single and low double digit feet. The spec says 50 meters. And given the 500 meter segment limit, 10Base5 would handle quite a large building. Repeaters serve several purposes. One is to allow a larger station count than is permitted on a single segment. Another is to allow multiple segments either for still greater distances or for convenience. For example, it would make a lot of sense to run a segment per floor, a backbone segment up the elevator shaft, and repeaters to connect floor to backbone, even if in principle you can zig-zag a single segment across several floors within the distance limits. >> A repeater was basically a signal booster between two ethernet segments. As >> you added segments interference and collisions became a problem as traffic >> on one segment was passed to all the other connected segments. > > Yep, the 3, 4, 5, rule. Up to five segments of cable with four repeaters and > stations on no more than three of the segments. > >> Hence the bridge was born. It had some intelligence And didn’t pass packets >> intended for computers on its own segment to the other segments thereby >> reducing congestion and collisions. > > Didn't repeaters operate in the analog domain? Meaning that they would also > repeat ~> amplify any noise / distortion too? No, they are digital devices (except that collision sense of course is an analog function, but that lives in the transceiver). They do clock recovery and regeneration. So you'd get some added jitter but not noise or distortion. > Conversely bridges operated in the digital domain. Meaning that they > received an Ethernet frame and then re-generated and transmitted a new > pristine Ethernet frame? Yes, except that bridges were encouraged to repeat the CRC rather than recalculate it, if possible. You can't do that on mixed LANs (like Ethernet to FDDI) but for the Ethernet to Ethernet case you can, and it's a very good thing to do so. >> Then the router was born to connect multiple segments together at one point. >> And it had intelligence to determine what segment a packet should go to and >> route it there. It also prevented packets from going onto segments that >> didn’t have the packet’s intended target thereby reducing congestion. Yes, except that historically speaking this is not accurate; routers predate Ethernet by 10 years or so. >> Hubs were born approximately the same time to get over the ethernet tap >> distance because by this time there were more computers in the single area >> that needed to be connected together to the Ethernet. > > Hum > > I can see problems with having enough actual taps on a network segment to > connect all the machines in a given area with AUI drop cable length issues. > > But I know that multi-port taps were a thing. I've read about them and seen > pictures of them for sale. I think I've read about a singular tap that had > eight AUI ports on it. I've seen pictures of four AUI ports on a single tap. Yes, DEC came out with that very early on, the DELNI. > ... >> The switch came about. It was a smart hub that had intelligence. It could >> filter out packets that were not int
Re: Retro networking / WAN communities
On 4/12/2022 9:49 AM, Paul Koning via cctalk wrote: On Apr 12, 2022, at 12:42 AM, Grant Taylor wrote: On 4/11/22 6:16 PM, Paul Koning wrote: [..SNIP..] I think there is a large, > 80%, overlap between switch and bridge, but they aren't perfect. Bridging some traffic between otherwise incompatible networks comes to mind; e.g. SNAP between Token Ring and Ethernet or Ethernet to xDSL (RFC 1483). That's not where the term "switch" was introduced. And devices like that were called "bridge" by market leaders like DEC -- the two generations of FDDI to Ethernet bridges I mentioned were both called "bridge". Also, the general operation of the device is the same whether it does MAC frame tweaking or not, 802.1d applies unchanged. Ethernet to non-Ethernet bridges have to do some tinkering with Ethernet protocol type frames (which is where SNAP comes in, all nicely standardized in the FDDI days). For 802.5 they also have to deal with the misnamed "functional" addresses, but that's not hard. There also was such a thing as a "source routing bridge", an 802.5 only bad idea invented by IBM and sold for a while until the whole idea faded away. The big difference in my mind between bridge and switch is: * Switches learn what port given MACs are on and only sends unicast traffic destined for that MAC address on that port and not all * Bridges send unicast traffic to all ports Of course it's important for bridges to follow the standard and switches to make sure they don't cause packet storms by forwarding on ports they shouldn't [..SNIP..] My $.02 Todd
Re: Retro networking / WAN communities
> On Apr 12, 2022, at 12:42 AM, Grant Taylor
> wrote:
>
> On 4/11/22 6:16 PM, Paul Koning wrote:
>> I think "hub" is another word for "repeater" (just like "switch" is another
>> word for "bridge").
>
> Interesting.
>
> Do you know of any documentation, preferably not marketing materials, that
> used "repeater" in lieu of "hub"?
DEC documentation.
> From my naive point of view, hubs came about when multiple stations connected
> to a central location, the center, or hub, of the start if you will.
> Conversely, I remember reading (after the fact) about repeaters as something
> that existed in pure 10Base5 / 10Base2 networks, predating hubs.
>
> I'm questioning form a place of ignorance. Like a child asking why fire is
> hot.
The concept of a repeater goes back to day 1 of Ethernet; you'll find them in
the D/I/X Ethernet spec. And they were part of the first batch of Ethernet
products from DEC. Yes, AUI based devices, two port.
But the next thing out the door was the DEMPR, "Digital Multi-Port Repeater",
an 8 port repeater. I think that's 10Base2.
I first saw "structured wiring" -- the star wiring with a hierarchy of wiring
closets and devices -- around 1986, in the new Littleton King Street DEC
building. It had distribution cabinets at the end of each row of cubicles.
These looked just like standard office supplies storage cabinets, with shelves;
inside you'd find a bridge and a couple of DEMPR repeaters, connected to
10Base2 coax drops to each cubicle.
> I think there is a large, > 80%, overlap between switch and bridge, but they
> aren't perfect. Bridging some traffic between otherwise incompatible
> networks comes to mind; e.g. SNAP between Token Ring and Ethernet or Ethernet
> to xDSL (RFC 1483).
That's not where the term "switch" was introduced. And devices like that were
called "bridge" by market leaders like DEC -- the two generations of FDDI to
Ethernet bridges I mentioned were both called "bridge".
Also, the general operation of the device is the same whether it does MAC frame
tweaking or not, 802.1d applies unchanged. Ethernet to non-Ethernet bridges
have to do some tinkering with Ethernet protocol type frames (which is where
SNAP comes in, all nicely standardized in the FDDI days). For 802.5 they also
have to deal with the misnamed "functional" addresses, but that's not hard.
There also was such a thing as a "source routing bridge", an 802.5 only bad
idea invented by IBM and sold for a while until the whole idea faded away.
>> The device I have is a small standalone box, about the size of today's small
>> 4-6 port switches you buy at Staples for $100. But it's actually a
>> repeater, not a switch, and one of its ports is a 10Base2 connector (BNC
>> jack).
>
> I would firmly consider what you describe as a "hub".
I think "hub" is what DEC called the chassis that these boxes could plug in to.
>> ...
>> That's rather odd because even if someone doesn't obey the letter of the law
>> you'd think they would at least support 100BaseT. Or was the problem lack of
>> half duplex? Do those management interfaces want to run half duplex?
>
> No. It's more nefarious than that. You mentioned supporting n - 1
> generation. I'm talking about switches that support 1 Gbps / 10 Gbps / 25
> Gbps / 40 Gbps / 50 Gbps / 100 Gbps. They quite simply don't scale down to
> 100 Mbps much less 10 Mbps. -- Why would someone want to support those slow
> speed connections on such a high speed switch? Devices like intelligent power
> strips or serial consoles or the likes in a cabinet that uses said switch as
> a Top of Rack device. -- Our reluctant solution has been to put in a lower
> end / un-manged 10 Mbps / 100 Mbps / 1 Gbps that can link at 1 Gbps to the
> main ToR.
I understand now. Yes, that's annoying indeed.
>> I think I saw in the standard that Gigabit Ethernet in theory includes a
>> half duplex mode, but I have never seen anyone use it and I wonder if it
>> would work if tried. Perhaps I misread things.
>
> My understanding is that Gigabit Ethernet (and beyond) only supports full
> duplex. Maybe I'm mis-remembering or thinking about what is actually
> produced vs theoretical / lab experiments.
I took a quick look in the 802.3 spec. In the 2002 edition, Part 3 describes
gigabit Ethernet. The intro ("clause 34") has this to say:
"In full duplex mode, the mini- mum packet transmission time has been reduced
by a factor of ten. Achievable topologies for 1000 Mb/s full duplex operation
are comparable to those found in 100BASE-T full duplex mode. In half duplex
mode, the minimum packet transmission time has been reduced, but not by a
factor of ten."
So yes, it's theoretically part of the spec. As you said, it doesn't seem to
be in actual use.
> Similarly, I know someone that has 100 Mbps Token Ring, a.k.a. High Speed
> Token Ring (HSTR) equipment for their mainframe. And 1 Gigabit Token Ring
> was designed in the la
Re: Retro networking / WAN communities
Grant Taylor wrote: > I think of Tymnet as a service and not as much as a protocol. Though > maybe it implies a protocol and I'm unaware of it. Tymshare was a service, but the computers talked to each over over a vast network. The network was spun off as a separate business. There is code available for the SDS 940, Tymeshare's TYMCOM-X, and TENEX. > Isn't Chaosnet mostly used in LISP machines? Yes, but also all over the MIT campus really. There is Chaosnet for 4.1BSD, if that's your thing. Also various PDP-10 systems: ITS, TOPS-20, TENEX.
Re: Retro networking / WAN communities
Cameron Kaiser wrote: > If we're going to do Tymnet, we should definitely do Telenet. Telenet is BBN's commercial network based on their IMP technology, right? How would you go about making a Telenet network?
Re: Retro networking / WAN communities
Warner Losh wrote: > NCP was the forerunner of TCP/IP. Net Unix had it as its supported > protocol and that was old enough that BSD had at least one > implementation. Are you saying there's a BSD Unix with Arpanet NCP? If so, where?
Re: Retro networking / WAN communities
On 4/11/22 11:38 PM, Wayne S wrote: In the beginning there was thick ethernet limited to 100 m. Um I *REALLY* thought the 5 & 2 in 10Base5 and 10Base2 was the number of hundreds of meters that the cable segment could exist on it's own. My understanding is that the 100 meter limit came about with 10Base-T. People wanted computers that were on different floors connected together between floors and buildings. That exceeded the 100 meter spec so the repeater was born to connect two 100 m thick ethernet seqments. I feel like even only 100 meters / 300(+) feet gives quite a bit of flexibility to connect multiple floors. Especially if you consider the AUI drop cable. Aside: I'm not sure how long an AUI drop cable could be. I'm anticipating between single and low double digit feet. A repeater was basically a signal booster between two ethernet segments. As you added segments interference and collisions became a problem as traffic on one segment was passed to all the other connected segments. Yep, the 3, 4, 5, rule. Up to five segments of cable with four repeaters and stations on no more than three of the segments. Hence the bridge was born. It had some intelligence And didn’t pass packets intended for computers on its own segment to the other segments thereby reducing congestion and collisions. Didn't repeaters operate in the analog domain? Meaning that they would also repeat ~> amplify any noise / distortion too? Conversely bridges operated in the digital domain. Meaning that they received an Ethernet frame and then re-generated and transmitted a new pristine Ethernet frame? Then the router was born to connect multiple segments together at one point. And it had intelligence to determine what segment a packet should go to and route it there. It also prevented packets from going onto segments that didn’t have the packet’s intended target thereby reducing congestion. I would say "network" as opposed to "segment" because a network could consist of multiple segments. But otherwise I agree. Hubs were born approximately the same time to get over the ethernet tap distance because by this time there were more computers in the single area that needed to be connected together to the Ethernet. Hum I can see problems with having enough actual taps on a network segment to connect all the machines in a given area with AUI drop cable length issues. But I know that multi-port taps were a thing. I've read about them and seen pictures of them for sale. I think I've read about a singular tap that had eight AUI ports on it. I've seen pictures of four AUI ports on a single tap. So ... the idea of having too many multi-port taps to be able to connect machines in proximity seems ... questionable to me. Single port taps, maybe. Hubs were dumb so every packet that hit them was forwarded to every other computer connected to the hub into the segment the hub was connected to, so, for a segment that had a lot of computers, there was congestion and collisions. I feel like a hub is the 10Base-T evolution of a multi-AUI port tap. The switch came about. It was a smart hub that had intelligence. It could filter out packets that were not intended for other computers connected to it thereby reducing congestion. I feel like the switch and the bridge are doing the same thing from a learning / forwarding / blocking perspective. I don't know which came first, but I suspect it was bridges. So each device was really an evolution to solve a problem of congestion and ethernet length. Sure. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 9:55 PM, Tony Duell via cctalk wrote: I am not sure what the actual distinction is, but a 'managed bridge' turned up at the local antique market (!) some weeks back. It has a pair of AUI ports and from the amount of logic/processor power inside it does a lot more than just pass packets from one port to the other, Would you be willing to share pictures? The main board contains a pair of ethernet interfaces (AM7990 based), a 68020 processor, ROM, RAM, etc. A board on top of of it called the 'FLUT' (Frame Look Up Table?) contains a CY7C901 (16 bit slice ALU -- think of it as 4 off 2901 + carry loglc), a 29C10 seqencer, etc Hum After removing the leaking NiCd from the mainboard and repairing the corroded tracks it powers up and passes the self-tests. No idea what I'll use it for, but... That seems like it would be an interesting piece of networking history to own. If you're into that sort of thing. ;-) -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 6:33 PM, Paul Koning wrote: DECbridge-90: AUI or 10Base2 to 10Base2. Interesting. That's not accurate. "Switch" is a marketing term invented by certain companies that wanted to pretend their products were different from (and better than) other people's bridges. It never was true that bridges are specifically two port devices. Yes, the very first few models (DEC's DECbridge-100 for example) were two port devices, as was one whose manufacturer I no longer remember that bridged Ethernet over a satellite link (InterLAN?). But the standard never assumed that, neither the original DEC one nor its later 802.1d derivative. To pick one example, the DECbridge-500 is a four port bridge: FDDI to 3 Ethernets. The DECbridge-900 is a 7 port bridge: FDDI to 6 Ethernets. Neither, at the time when DEC introduced them, were called or described as anything other than bridges. Today I learned. The marketeers who flogged the other term also tried to use it to claim it referred to other supposed improvement, like cut-through operation. That was an oddball notion that never made much sense but some people seemed to like doing it in the 10 Mb and 100 Mb era. Of course it doesn't work for any mixed media, and at higher speeds the difficulty goes up while the benefits, if they ever were meaningful in the first place, shrink to microscopic values. For sure it hasn't been heard of in quite a while. I forgot the name of the company, mid 1980s I think, that made a big fuss over "cut through" and I think may also have been the inventer of the term "switch". Cisco bought them at some point. I vaguely remember that there were three main forms of switching: store and forward, cut-through, and a hybrid of the two. My understanding is that S&F had the ability to sanity check (checksum?) frames and only re-send out valid / non-corrupted frames. Conversely C.T. could not do this sanity checking and thus could re-send corrupted frames. The 3rd form did a sanity check on the first part of the frame. -- I think. I vaguely remember this as a past tense discussion topic at the turn of the century. I've heard exceedingly little about it since. Also: neither "bridge" nor "switch" by itself implies either managed or unmanaged. I think that /just/ "switch" without any other qualification implies an unmanaged layer 2 device. Anything operating above layer 2 will inherently /require/ some configuration thus management. Yes, layer 3 switches are a thing. Yes, routers, nominally layer 3 devices, can be configured to perform unmanaged layer 2 switching. I think DEC bridges were generally unmanaged, though that was mostly because no management standards existed yet. I wasn't around when SNMP became a big deal so I don't know if DEC adopted it when that happened. I'm not even going as far as what management protocol is used. I'm including even something that has lowly stand alone serial interface for console / dumb terminal (emulator) based configuration through some interface. No remote management / protocol required. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 6:16 PM, Paul Koning wrote: I think "hub" is another word for "repeater" (just like "switch" is another word for "bridge"). Interesting. Do you know of any documentation, preferably not marketing materials, that used "repeater" in lieu of "hub"? From my naive point of view, hubs came about when multiple stations connected to a central location, the center, or hub, of the start if you will. Conversely, I remember reading (after the fact) about repeaters as something that existed in pure 10Base5 / 10Base2 networks, predating hubs. I'm questioning form a place of ignorance. Like a child asking why fire is hot. I think there is a large, > 80%, overlap between switch and bridge, but they aren't perfect. Bridging some traffic between otherwise incompatible networks comes to mind; e.g. SNAP between Token Ring and Ethernet or Ethernet to xDSL (RFC 1483). The device I have is a small standalone box, about the size of today's small 4-6 port switches you buy at Staples for $100. But it's actually a repeater, not a switch, and one of its ports is a 10Base2 connector (BNC jack). I would firmly consider what you describe as a "hub". AUI connector, yes. Two are little boxes about the size of the connector body but maybe 2-3 inches long, with the coax or RJ45 connector at the other end. The 10BaseT is a DEC product, the 10Base2 I don't remember. I also have an ancient 10BaseT transceiver that's about twice as big, with a jack for an external power source, forgot the maker of that one. *nod*nod* I have had many such things various times in the past. I recently unboxed one that's (from memory) < 2" x < 3" x < 1", with AUI on one side and 10Base-T on the other side. You won't get an argument from me on that one... :-) :-D That's rather odd because even if someone doesn't obey the letter of the law you'd think they would at least support 100BaseT. Or was the problem lack of half duplex? Do those management interfaces want to run half duplex? No. It's more nefarious than that. You mentioned supporting n - 1 generation. I'm talking about switches that support 1 Gbps / 10 Gbps / 25 Gbps / 40 Gbps / 50 Gbps / 100 Gbps. They quite simply don't scale down to 100 Mbps much less 10 Mbps. -- Why would someone want to support those slow speed connections on such a high speed switch? Devices like intelligent power strips or serial consoles or the likes in a cabinet that uses said switch as a Top of Rack device. -- Our reluctant solution has been to put in a lower end / un-manged 10 Mbps / 100 Mbps / 1 Gbps that can link at 1 Gbps to the main ToR. I think I saw in the standard that Gigabit Ethernet in theory includes a half duplex mode, but I have never seen anyone use it and I wonder if it would work if tried. Perhaps I misread things. My understanding is that Gigabit Ethernet (and beyond) only supports full duplex. Maybe I'm mis-remembering or thinking about what is actually produced vs theoretical / lab experiments. Similarly, I know someone that has 100 Mbps Token Ring, a.k.a. High Speed Token Ring (HSTR) equipment for their mainframe. And 1 Gigabit Token Ring was designed in the lab but never actualized. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On Mon, Apr 11, 2022 at 11:18 PM Cameron Kaiser via cctalk wrote: > > > I don't have a 10Base2 switch, > Were there ever actual true 10b2 switches? I've only ever seen them as hubs, > and I haven't seen a 10bT switch that had a 10b2 port (all the 10bT devices I > have with 10b2 ports are hubs). > I am not sure what the actual distinction is, but a 'managed bridge' turned up at the local antique market (!) some weeks back. It has a pair of AUI ports and from the amount of logic/processor power inside it does a lot more than just pass packets from one port to the other, The main board contains a pair of ethernet interfaces (AM7990 based), a 68020 processor, ROM, RAM, etc. A board on top of of it called the 'FLUT' (Frame Look Up Table?) contains a CY7C901 (16 bit slice ALU -- think of it as 4 off 2901 + carry loglc), a 29C10 seqencer, etc After removing the leaking NiCd from the mainboard and repairing the corroded tracks it powers up and passes the self-tests. No idea what I'll use it for, but... -tony
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 8:16 PM, Cameron Kaiser via cctalk > wrote: > I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). >>> Please expand "my Pro". There's not much to go on. >>> #LivingRetroVicariouslyThoughOthers >> DEC Professional 380 (and a caseless 350) -- PDP-11s with a screwball bus >> and their own set of peripherals. I have an Ethernet card for one of them. >> Working on the driver. > > I'd love Ethernet to work in Venix/PRO but I think my 380 is just going to > have > to do some user-level SLIP driver. I suppose that's something I could write up > for gits and shiggles. Perhaps you could adapt the Linux or NetBSD driver for the 82586. I'm not sure the NetBSD one is complete but the Linux one (sun3-82586.c) looks plausible. You'll also need to study the CNA chapter of the Pro technical manual (on Bitsavers) since the board includes some additional control logic as well as the packet memory that the chip talks to. And of course, you'll get to discover all over again that Intel never could design Ethernet chips for beans; the 586 is an especially ugly example of architural absurdity, with its linked list of descriptors that introduce lots of bad race conditions between the CPU and I/O device. (The depressing thing is that Dijkstra figured out and documented how to do this right 20 years earlier.) paul
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 6:35 PM, Grant Taylor via cctalk > wrote: > > On 4/11/22 4:18 PM, Cameron Kaiser via cctalk wrote: >> Were there ever actual true 10b2 switches? DECbridge-90: AUI or 10Base2 to 10Base2. > ... > IMHO an unmanaged switch is an evolution of a bridge. Or in the past, I used > to say (a very long time ago) a switch was was three or more ports and a > bridge was exactly two ports. -- Probably inaccurate in some way. But it > worked for the conversation at the time. That's not accurate. "Switch" is a marketing term invented by certain companies that wanted to pretend their products were different from (and better than) other people's bridges. It never was true that bridges are specifically two port devices. Yes, the very first few models (DEC's DECbridge-100 for example) were two port devices, as was one whose manufacturer I no longer remember that bridged Ethernet over a satellite link (InterLAN?). But the standard never assumed that, neither the original DEC one nor its later 802.1d derivative. To pick one example, the DECbridge-500 is a four port bridge: FDDI to 3 Ethernets. The DECbridge-900 is a 7 port bridge: FDDI to 6 Ethernets. Neither, at the time when DEC introduced them, were called or described as anything other than bridges. The marketeers who flogged the other term also tried to use it to claim it referred to other supposed improvement, like cut-through operation. That was an oddball notion that never made much sense but some people seemed to like doing it in the 10 Mb and 100 Mb era. Of course it doesn't work for any mixed media, and at higher speeds the difficulty goes up while the benefits, if they ever were meaningful in the first place, shrink to microscopic values. For sure it hasn't been heard of in quite a while. I forgot the name of the company, mid 1980s I think, that made a big fuss over "cut through" and I think may also have been the inventer of the term "switch". Cisco bought them at some point. Also: neither "bridge" nor "switch" by itself implies either managed or unmanaged. I think DEC bridges were generally unmanaged, though that was mostly because no management standards existed yet. I wasn't around when SNMP became a big deal so I don't know if DEC adopted it when that happened. paul
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 6:07 PM, Grant Taylor via cctalk > wrote: > > On 4/11/22 2:58 PM, Paul Koning via cctalk wrote: >> I don't have a 10Base2 switch, but I have an old repeater with 4-5 10BaseT >> ports and a 10Base2 port. And I have a 10Base2 transceiver (as well as 2 or >> 3 10BaseT transceiver). Good thing because the Pro has an AUI connector. > > I have to ask ... > > Q1 Would you be referring a "hub"? I think "hub" is another word for "repeater" (just like "switch" is another word for "bridge"). The device I have is a small standalone box, about the size of today's small 4-6 port switches you buy at Staples for $100. But it's actually a repeater, not a switch, and one of its ports is a 10Base2 connector (BNC jack). > Q2 Are your transceivers from AUI to 10Base2 / 10BaseT? Or are they > something else more mid-span? AUI connector, yes. Two are little boxes about the size of the connector body but maybe 2-3 inches long, with the coax or RJ45 connector at the other end. The 10BaseT is a DEC product, the 10Base2 I don't remember. I also have an ancient 10BaseT transceiver that's about twice as big, with a jack for an external power source, forgot the maker of that one. > Sorry if this is too pedantic. But I do feel like the pedantry is somewhat > warranted for this list. You won't get an argument from me on that one... :-) >> Same here, except unmanaged. I didn't realize until years into the 1G era >> that 1G is backwards compatible TWO generations, not the usual one. And the >> switch seems to be happy to speak 10 Mb half duplex, nice. > > I'm running into issues with switches not supporting 10 / 100 Mbps management > interfaces for other equipment. That's rather odd because even if someone doesn't obey the letter of the law you'd think they would at least support 100BaseT. Or was the problem lack of half duplex? Do those management interfaces want to run half duplex? I think I saw in the standard that Gigabit Ethernet in theory includes a half duplex mode, but I have never seen anyone use it and I wonder if it would work if tried. Perhaps I misread things. paul
Re: Retro networking / WAN communities
>>> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I >>> have a few 10Base2 bits). >> Please expand "my Pro". There's not much to go on. >> #LivingRetroVicariouslyThoughOthers > DEC Professional 380 (and a caseless 350) -- PDP-11s with a screwball bus and > their own set of peripherals. I have an Ethernet card for one of them. > Working on the driver. I'd love Ethernet to work in Venix/PRO but I think my 380 is just going to have to do some user-level SLIP driver. I suppose that's something I could write up for gits and shiggles. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Maybe this world is another planet's hell. -- Aldous Huxley
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 5:57 PM, Grant Taylor via cctalk > wrote: > > On 4/11/22 11:27 AM, Paul Koning via cctalk wrote: >> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I >> have a few 10Base2 bits). > > Please expand "my Pro". There's not much to go on. > #LivingRetroVicariouslyThoughOthers DEC Professional 380 (and a caseless 350) -- PDP-11s with a screwball bus and their own set of peripherals. I have an Ethernet card for one of them. Working on the driver. paul
Re: Retro networking / WAN communities
On Apr 11, 2022, at 12:36 PM, Zane Healy via cctalk wrote: > > You’re one of the people I’d expect to be running 10Base-2 at home. I only > have one 10Mbit switch still online, it’s for my DECserver 90TL, the only > 10Base-2 device that I keep online (I have a couple others). A correction here, I’m talking about a 10Base-T hub with a 10Base-2 connector, not a 10Mbit switch. I’m too used to using switches. I do have a 10Base-T to 10Base-2 media converter that I spent a of a lot money on, before I realized I simply needed a cheap 10Base-T switch with a 10Base-2 connector. The media converter is my backup plan if the hub dies. If the DECserver dies, I’m in trouble. Zane
Re: Retro networking / WAN communities
On 4/11/22 11:12 AM, Ethan O'Toole via cctalk wrote: There is a Central Office Groups.io list (which migrated from Yahoo Groups) located at https://groups.io/g/centraloffice . It is low traffic. I've sent a subscribe request. There is a Discord server related to PBX and Telephone stuff, but will have to dig up that info later. It's pretty low traffic as well. I'd be curious to see the info at your convenience. Thank you for the pointers Ethan. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 4:39 PM, Cameron Kaiser via cctalk wrote: I'll also throw in SLIP, since I imagine most remote access nowadays is all PPP, If you're adding SLIP, I'm going to add PLIP. and maybe even old school EtherTalk or LocalTalk. Oh wow. Ya. That's more easily done / emulated on many systems. I had a T1 locally up until a couple months ago. I still have the smartjack and the wiring, but DSLX wouldn't support it anymore. They just left the T1 routers, too. They're embedded PowerPC systems I should figure out something fun to do with. If you're looking to move them. Send me an email. I've recently acquired things to do T1 / DSX-1 between multiple machines at home. I'd /like/ to do the TelCo side of that too, for at least one loop. But it seems as if the equipment to do that is even more specialized. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 4:47 PM, Warner Losh via cctalk wrote: NCP was the forerunner of TCP/IP. Net Unix had it as its supported protocol and that was old enough that BSD had at least one implementation. Thank you for confirmation of what I thought might be the case Warner. I've thought about messing with NCP on emulated VAXen in the past. I'm sure I'll consider such in the future. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On Mon, Apr 11, 2022, 4:39 PM Grant Taylor via cctalk wrote: > On 4/11/22 1:59 PM, Lars Brinkhoff via cctalk wrote: > > For your consideration: > > > > - Arpanet (NCP) > > Is that "NCP" the same NCP that's in ancient BSDs? Or is it a term > collision? > NCP was the forerunner of TCP/IP. Net Unix had it as its supported protocol and that was old enough that BSD had at least one implementation. Warner > - Tymnet > > I think of Tymnet as a service and not as much as a protocol. Though > maybe it implies a protocol and I'm unaware of it. > > > - Chaosnet > > Ya. Isn't Chaosnet mostly used in LISP machines? -- This seems fairly > far afield for my interest. > > > - PUP > > Maybe. It also seems fairly afar afield for what I can get my hands on > and / or emulate. > > > - UUCP > > There. Ding that. > > I'm even pontificating a custom UUCP configuration that is specific to > my user. As in /not/ a system wide version. > > > > -- > Grant. . . . > unix || die >
Re: Retro networking / WAN communities
>> I find myself interested in (at least) the following and would like to >> find others with similar (dis)interests to chat about things. >> >> - 10Base5 / 10Base2 / 10BaseT >> - ISDN >> - DSL / ADSL / SDSL / HDSL >> - T1 / E1 >> - ATM >> - Frame Relay >> - ARCnet >> - PSTN / PBX / PABX > > For your consideration: > > - Arpanet (NCP) > - Tymnet > - Chaosnet > - PUP > - UUCP If we're going to do Tymnet, we should definitely do Telenet. I'll also throw in SLIP, since I imagine most remote access nowadays is all PPP, and maybe even old school EtherTalk or LocalTalk. I had a T1 locally up until a couple months ago. I still have the smartjack and the wiring, but DSLX wouldn't support it anymore. They just left the T1 routers, too. They're embedded PowerPC systems I should figure out something fun to do with. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- MOVIE IDEA: The Never-Ending E-mail Signature --
Re: Retro networking / WAN communities
On 4/11/22 1:59 PM, Lars Brinkhoff via cctalk wrote: For your consideration: - Arpanet (NCP) Is that "NCP" the same NCP that's in ancient BSDs? Or is it a term collision? - Tymnet I think of Tymnet as a service and not as much as a protocol. Though maybe it implies a protocol and I'm unaware of it. - Chaosnet Ya. Isn't Chaosnet mostly used in LISP machines? -- This seems fairly far afield for my interest. - PUP Maybe. It also seems fairly afar afield for what I can get my hands on and / or emulate. - UUCP There. Ding that. I'm even pontificating a custom UUCP configuration that is specific to my user. As in /not/ a system wide version. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 4:18 PM, Cameron Kaiser via cctalk wrote: Were there ever actual true 10b2 switches? I've seen 10Base-T versions of -- what I would call -- bridges in box for sale. I've seen /many/ different software products that could be installed on computers with supported interfaces to be bridges. You could easily have 10Base2 / 10Base5 in those. IMHO an unmanaged switch is an evolution of a bridge. Or in the past, I used to say (a very long time ago) a switch was was three or more ports and a bridge was exactly two ports. -- Probably inaccurate in some way. But it worked for the conversation at the time. I've only ever seen them as hubs, and I haven't seen a 10bT switch that had a 10b2 port (all the 10bT devices I have with 10b2 ports are hubs). I /want/ to say that I've seen a switch with AUI or BNC connectors on it. But I can't remember any off hand. Maybe something modular that has optional add-in cards. But I can't think of any fixed configuration switches with AUI / BNC. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> I don't have a 10Base2 switch, Were there ever actual true 10b2 switches? I've only ever seen them as hubs, and I haven't seen a 10bT switch that had a 10b2 port (all the 10bT devices I have with 10b2 ports are hubs). I just have one 10b2 system now, the VAXstation 3100 M76 (previously the HP 9000/350 was 10b2, but I replaced its IO board with a later one with an AUI port: http://oldvcr.blogspot.com/2021/04/refurb-weekend-hewlett-packard-9000350.html ). -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Proponents of other opinions will be merrily beaten to a bloody pulp. --
Re: Retro networking / WAN communities
On 4/11/22 2:58 PM, Paul Koning via cctalk wrote: I don't have a 10Base2 switch, but I have an old repeater with 4-5 10BaseT ports and a 10Base2 port. And I have a 10Base2 transceiver (as well as 2 or 3 10BaseT transceiver). Good thing because the Pro has an AUI connector. I have to ask ... Q1 Would you be referring a "hub"? Q2 Are your transceivers from AUI to 10Base2 / 10BaseT? Or are they something else more mid-span? Sorry if this is too pedantic. But I do feel like the pedantry is somewhat warranted for this list. Same here, except unmanaged. I didn't realize until years into the 1G era that 1G is backwards compatible TWO generations, not the usual one. And the switch seems to be happy to speak 10 Mb half duplex, nice. I'm running into issues with switches not supporting 10 / 100 Mbps management interfaces for other equipment. -- Grant. . . . unix || die
Re: Retro networking / WAN communities
On 4/11/22 11:27 AM, Paul Koning via cctalk wrote: I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). Please expand "my Pro". There's not much to go on. #LivingRetroVicariouslyThoughOthers And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. I've had some ATM equipment (FORE OC3 switch & FORE OC3 / Ethernet bridge) before the pre-move-purge. I'd like to mess with ATM again. I view ATM based DSL as a way to get back into ATM. }:-) Hey, you didn't mention FDDI. :-) I'm sorry. It slipped my mind while trying to finish the email. Rest assured that both FDDI and it's CDDI cousin are on my list of things to mess with. :-D -- Grant. . . . unix || die
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 3:36 PM, Zane Healy wrote: > > > >> On Apr 11, 2022, at 10:27 AM, Paul Koning via cctalk >> wrote: >> >> I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I >> have a few 10Base2 bits). And I did ATM for a living for about 5 years, >> back around 1995, so I can still talk a bit of that. >> >> Hey, you didn't mention FDDI. :-) >> >> Paul > > Hi Paul, > You’re one of the people I’d expect to be running 10Base-2 at home. :-) > I only have one 10Mbit switch still online, it’s for my DECserver 90TL, the > only 10Base-2 device that I keep online (I have a couple others). I don't have a 10Base2 switch, but I have an old repeater with 4-5 10BaseT ports and a 10Base2 port. And I have a 10Base2 transceiver (as well as 2 or 3 10BaseT transceiver). Good thing because the Pro has an AUI connector. > All my 10Base-T devices are plugged into 1Gbit managed switches. Same here, except unmanaged. I didn't realize until years into the 1G era that 1G is backwards compatible TWO generations, not the usual one. And the switch seems to be happy to speak 10 Mb half duplex, nice. paul
Re: Retro networking / WAN communities
Grant Taylor wrote: > I find myself interested in (at least) the following and would like to > find others with similar (dis)interests to chat about things. > > - 10Base5 / 10Base2 / 10BaseT > - ISDN > - DSL / ADSL / SDSL / HDSL > - T1 / E1 > - ATM > - Frame Relay > - ARCnet > - PSTN / PBX / PABX For your consideration: - Arpanet (NCP) - Tymnet - Chaosnet - PUP - UUCP
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 10:27 AM, Paul Koning via cctalk > wrote: > > I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I > have a few 10Base2 bits). And I did ATM for a living for about 5 years, back > around 1995, so I can still talk a bit of that. > > Hey, you didn't mention FDDI. :-) > > Paul Hi Paul, You’re one of the people I’d expect to be running 10Base-2 at home. I only have one 10Mbit switch still online, it’s for my DECserver 90TL, the only 10Base-2 device that I keep online (I have a couple others). All my 10Base-T devices are plugged into 1Gbit managed switches. Zane
Re: Retro networking / WAN communities
On 11/04/2022 18:02, Grant Taylor via cctech wrote: > Does anyone know of any communities / mailing lists / newsgroups / et > al. for retro networking / WAN technologies? > > I find myself interested in (at least) the following and would like to > find others with similar (dis)interests to chat about things. > >- 10Base5 / 10Base2 / 10BaseT >- ISDN >- DSL / ADSL / SDSL / HDSL >- T1 / E1 >- ATM >- Frame Relay >- ARCnet >- PSTN / PBX / PABX The Osmocom community have a retro networking project, with projects including TDM over IP. https://osmocom.org/projects/retronetworking/wiki/ They have also created an open hardware USB E1 interface that can be used with the aforementioned, as well as with older GSM base stations which implement Abis over E1 (which you can then operate with the Osmocom CNI software stack). https://osmocom.org/projects/e1-t1-adapter/wiki/IcE1usb There's also Osmocom-Analog, if your interests extend to retro cellular. http://osmocom-analog.eversberg.eu/ Andrew
Re: Retro networking / WAN communities
> On Apr 11, 2022, at 1:02 PM, Grant Taylor via cctalk > wrote: > > Hi, > > Does anyone know of any communities / mailing lists / newsgroups / et al. for > retro networking / WAN technologies? > > I find myself interested in (at least) the following and would like to find > others with similar (dis)interests to chat about things. > > - 10Base5 / 10Base2 / 10BaseT > - ISDN > - DSL / ADSL / SDSL / HDSL > - T1 / E1 > - ATM > - Frame Relay > - ARCnet > - PSTN / PBX / PABX I still have 10 Mb Ethernet at home (on my Pro, and while it's not in use I have a few 10Base2 bits). And I did ATM for a living for about 5 years, back around 1995, so I can still talk a bit of that. Hey, you didn't mention FDDI. :-) paul
Re: Retro networking / WAN communities
Does anyone know of any communities / mailing lists / newsgroups / et al. for retro networking / WAN technologies? - PSTN / PBX / PABX There is a Central Office Groups.io list (which migrated from Yahoo Groups) located at https://groups.io/g/centraloffice . It is low traffic. There is a Discord server related to PBX and Telephone stuff, but will have to dig up that info later. It's pretty low traffic as well. - Ethan -- : Ethan O'Toole
