Ethernet - Page 1 Welcome to the Study Guide covering an overview of Ethernet. The material to be covered in this article includes:. Ethernet media access. Ethernet topology. Ethernet addressing. Half versus full duplex communication In the Essential Network Concepts Study Guides, we took a look at two network technologies, FDDI and Token Ring. While both enjoy a small piece of the LAN marketplace, Ethernet more or less rules the LAN world for a variety of reasons.

These two pages will touch on some of those reasons. Originally developed by Xerox, it was later jointly developed by Digital, Intel, and Xerox, commonly referred to as DIX. In 1982, the IEEE, in what is known as the 802.3 standard, standardized Ethernet. Ethernet Media Access Ethernet is a contention-based network technology. From the previous article you may recall that in a contention-based system, all system share, or contend for, the right to transmit data.

Unlike Token Ring and FDDI which are deterministic, in an Ethernet environment all systems listen to the media, waiting for the opportunity to gain access to the media. Only one system can be transmitting at any given point in time, or collisions occur.

Specifically, Ethernet uses a contention system referred to as Carrier Sense Multiple Access with Collision Detection, or CSMA/CD for short. Let's break the name down, because it actually explains how the technology works: Carrier Sense - devices listen to the media for carrier signals Multiple Access - devices share the media Collision Detection - devices are capable of detecting a collision When a device wishes to transmit on an Ethernet network, it first listens to be sure that no other station is transmitting at that point in time. If the media is clear of signals, it will transmit. The problem should be clear - it is possible that two stations will detect the media as being clear concurrently, and will attempt to transmit.

If this happens, a collision occurs, which will corrupt the data that was sent. When a collision does occur, systems will need to retransmit their data. In order to have a better chance of another collision not occurring immediately, systems involved in a collision will 'back off' for a random period of time before attempting retransmission. If another collision occurs, the backoff time increases, and will keep increasing.

This is part of the reason why collisions are such a hassle, especially on large networks. In order to avoid or reduce collisions, a network should be broken down into small collision domains. Recall that when plugged into a hub, all systems are part of the same collision domain, meaning that their data is capable of colliding with one another. Collision domains can be created through the use of both bridges and switches.

When a bridge is added to a network, it can separate the network into a few collision domains. When a switch is used, many more collision domains exist - each port becomes a collision domain. In fact, if each system is plugged into its own switch port, there will be no collisions.

In short, a good reason to replace hubs with switches. We'll look at switches and bridges in more detail both later in this article and later in the series. Part of the reason why many companies originally avoided Ethernet in favor of Token Ring was because of these collisions, and the impact they had on performance. With the advent of bridging (and especially switching) Ethernet has become much more robust, and as such, much more popular. It is by and large the most popular LAN technology used today, and its share is only moving one way - up. Ethernet Topologies When originally defined, Ethernet wasn't a very friendly solution.

Implementing it involved connecting systems to a single long coaxial cable referred to as Thicknet or 10Base5. In order to connect to the Ethernet, systems were required to use a network interface card with an external transceiver that literally 'tapped' into the core of the cable. This was referred to as a vampire tap.

The transceiver then connected to the network card via an Attachment Unit Interface (AUI) cable. The connector type used was referred to as a DIX connector, as per the companies mentioned previously. Later, Ethernet moved on to use a thinner variation of cable called 10Base2 or Thinnet. This network was more flexible, in that systems were directly connected to the coaxial cable using BNC connectors, not unlike those that connect to the back of your television.

We'll look at the details of 10Base2 and 10Base5 later. For now, it's important to recognize the topology both use - what is referred to as a bus. A bus topology is one where the signals are passed across the entire length of the cable. At either end, a device referred to as a terminator was used to absorb the signal, ensuring that it wouldn't bounce back down the wire and cause a collision.

While pure bus networks may not be terrible popular today, they still form the basis on which Ethernet networks are developed. Patch cables and hubs have replaced the long single wire, but the signals still travel to all connected systems on a segment (with the exception of when switches or bridges are used). When systems do connected to hubs, the topology is usually considered to be a star. Because of this, Ethernet is often referred to as a Star-wired bus, as shown below. Note that in this case, computers connecting to the hubs create two stars, but a length of Thinnet connects the actual hubs. Not as popular as it used to be, but this setup was a common sight up until only a few years ago.

Ethernet Addressing An Ethernet address is also commonly known as a Media Access Control (MAC) or hardware address. These addresses are associated with a network card by burning it into a ROM chip at the time of manufacture. An Ethernet address not only should be unique for each card (this also acts as a serial number), but also identifies the vendor who manufactured the card, as we'll see shortly. Ethernet addresses are 48 bits in length, and are represented in hexadecimal.

Macon Inc Ether Card For Mac

The hex numbering system is referred to as being Base16, since 16 possible values exist - these range from 0-F. The table below outlines the value associated with each hexadecimal digit in both decimal and binary. Note that any value beyond F will never be valid, and that every address in hex will consist of 12 digits - each hex digit represents 4 bits. Hexadecimal 0 1 2 3 4 5 6 7 8 9 A B C D E F Decimal 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Formats that you will see hardware addresses listed in vary, but in general two formats tend to rule. An 0x is seen in front of a hexadecimal number to distinguish it from the more common decimal format. In Windows, MAC addresses are separated by a dash between each byte. For example: 0x 01-22-E4-E5-44-20 On Cisco devices, addresses are generally represented in 3 groups of 4 hex digits.

For example: 0x 0122.E4F5.4420 A MAC broadcast address is all ones: 111111 11111111 In dotted decimal format we see it as: 255.255.255.255 In hexadecimal format we see it as: 0x FFFF.FFFF Notice the leading ' 0x'. That tells us that the following number is in hexadecimal format. The format doesn't change the address since it's just a representation. Most hex numbers are represented in groups of 16 digits - but still, each hex digit represents 4 bits. However, seeing as this is a Cisco series, we should probably follow the 12 digit format. The key thing with a MAC address is what it identifies. The first 24 bits represent a vendor Organizationally Unique Identifier, or OUI.

The last 6 uniquely identify the network card. This breakdown is shown below. The IEEE allocates the OUIs to manufacturers.

Note that mistakes do happen - while each network card should have a unique address, there have been many cases of mistakes being made during a production run. Duplicate MAC addresses can cause big problems on a network, but in general, it shouldn't be a big worry.

Vendor Serial Number 0122E4 F54420 A list of the OUIs assigned to vendors can be found here if you're interested: Full Versus Half Duplex Communication Ethernet was originally designed to work as a half duplex system, meaning that a system could either send or receive data, but not both simultaneously. In reality, this isn't so much a design element - it's actually a function of contention-based media access. Since all systems share the media, and only one system can send data at any given point in time, half duplex was a requirement. When systems are plugged into a hub, or connected to an Ethernet bus, they will always communicate in half duplex, even when a network card supports full duplex.

In order to enable full duplex communication, where a system can both send and receive data simultaneously, a switch must be involved. More specifically, a system will require its own dedicated switch port to be capable of full duplex communication. For example, imagine a scenario where you plug one system into a switch port, and them plug a hub into a different switch port. Connecting a hub to a switch allows a number of computers to be part of the same collision domain.

However, the systems connected to this hub can only communicate in half duplex - they are still on a traditional shared network, after all. The only case where two systems can communicate in full duplex using the full available bandwidth is when both are plugged into their own dedicated switch ports.

This makes the systems capable of sending and receiving data at the maximum NIC speed simultaneously. When plugged into a switch or hub, most Ethernet systems are now capable of what is referred to as autonegotiation. When a system is connected, the port and the network interface card exchange what are known as Fast Link Pulses (FLPs).

These carry information about the capabilities of a card. For example, is you plug a computer with a 10/100 Ethernet card into a 10Mbps switch port, they will automatically negotiate a speed of 10 Mbps full duplex. Note that not all network cards and switches or hubs are capable of autonegotiation, especially older models.

A lot of info on this stuff is scattered about a few convoluted threads, most of it is buried under the incredible heap of crap in the thread so it's high time for a fresh start: I should be able to dig pics of the MacCon model with the removable ThickNet board up easily enough later on. Probably right in that thread, but that cionversion's a piece of cake! However someone recently asked about options for modifying a version of the Asante MacCon backplane breakout board PCB lacking that very convenient, removable PCB/ThickNet Connector daughterboard recently so I took some pics of an even earlier model's breakout board: This one hasn't even got 10baseT/RJ-45 on board, but if I ever get around to sourcing a transceiver for it, I'll definitely go with ThinNet to use with one of my old Hubs anyway. But with insanely inexpensive Pivot Cards available, there's really no other choice! The ThickNet connector is a special, high profile version of ye olde DA-15 for use with clips on a backplane plate mounted way out in the cheap seats to match the depth of the ThinNet BNC Connector's form factor, this makes things very easy. Oblique view of the High Profile DA-15 connector next to a standard DA-15 connector with solder cup termination for panel mount applications, which exactly how it will be employed! ' Here are the connectors overlapped in top view, we've got plenty of head room for the custom built cable.

Gotta love having about 12 lbs. Of air dry modeling clay stickumtogethastuffs at hand! ' Here's a view of the cable wire/solder cup interface and how easily the wire will bend to an even tighter radius than necessary to clear the PCB behind the wiring harness. I used a wire about the same gauge as the breadboard jumper wires toledogeek used for his fabulous hack. I've got these laying around in the prototyping piles as well. I'll post a current link to them on eBay when the time comes. I guess that about wraps it up for soldered high profile DA-15 - Panel Mount DA-15 conversion specific information for any ThickNet connector equipped IIsi or SE/30 NIC.

The rest of the thread will detail building the almost universally missing link, the standard RCPII/IIsi breakout cable with DA-15 connector and the version I'm really interested in building, the RCPII/IIsi breakout cable to HD-15 VGA connector with 16' Resolution conversion done in the cable. Meanwhile, take a look around for a ratty video cable or any another donor for your Ferrite Ring. Edited October 20, 2017 by Trash80toHPMini. Great thread!

Macon Inc Ether Card For Mac Pro

Unfortunately, I don't have time ATM to do anything Mac-related but that is exactly what I planned on doing. You still need to cut a piece of that Pivot card though. And do the right angle conversion to the MacCon.

But that should be doable. Didn't know the ThickNet connector was that thick compared to a normal video connector (could have probably figured that out just by looking at the name though.). But that's great. There's enough room now to fit the new connector.

Speaking of which, are the metal stand-offs part of the ThickNet connector, or can they be removed and reused on the new DA-15? Here are the IIsi Pivot pinouts, in case anyone needs them. Top of the card A-1 B-2 C-3 D-4 E-5 F-6 G-7 H- NOT CONNECTED I-9 J-10 K-11 M-12 L-13 N-14 O-15 (FPU socket side) Notes: -A thru O: IIsi pivot connector -1 thru 15: DA-15 connector - Pin #8 is not connected to anything.

FYI, here's a picture showing how the pins on the DA-15 connector are numbered Edit. Thanks so much for jumping in!

I can't find my cable ATM to check, but IIRC every SE/30, IIsi and SE video breakout panel cable in my collection has a ferrite ring shrink wrapped a couple of inches back from the DA-15. Dunno if it's necessary, but it's probably a good idea to follow that general precedent. It's beyond my ken, but any issues rectified by the ferrite ring might be especially important when venting output through a NIC's expansion cover plate.

That's the aim of this particular thread. Dropping it from the spec we're developing's no problem.

Building a simplified cable for a dedicated, single purpose cover plate is a side issue, as is my in-cable 832 x 624 16' resolution, HD-15 VGA connector conversion. Noodling out an easily built solution to the DA-15 to HD-15 punched opening in the Nic's plate is a side benefit!

But if a printed adapter would be robust enough for the application, maybe somebody will jump in with a printed 3-D model. ' One of in that insane mess of a research thread. Oh snap, I got it to work! I had to connect a real monitor to the Pivot card before I could see anything - simply putting jumpers on the sense lines and then looking in the monitors control panel didn't seem to be enough. I haven't been able to test a dual-head setup yet, since I only have one monitor, but I was able to boot and run at 832 x 624 x 256 colors @ 75 Hz with the Pivot card as the sole video card. For future reference, pin 1 on the Pivot card is the pin adjacent to the 'J2' text on the board's silkscreen.

The pins are: 1 RED GND 2 RED 3 C SYNC 4 SENSE0 5 GREEN 6 GREEN GND 7 SENSE1 8 N.C. 9 BLUE 10 SENSE2 11 C & V SYNC GND 12 V SYNC 13 BLUE GND 14 H SYNC GND 15 H SYNC If you want to build a video cable to connect to a Mac-standard DB-15 monitor, then just wire those pins straight to the DB-15, matching them up pin for pin. Pivot card pin 1 connects to DB-15 pin 1, Pivot pin 2 connects to DB-15 pin 2, etc. If you want to build a combo video cable and VGA adapter with a hard-coded 832 x 624 sense code (which seems to be the highest possible Pivot resolution that's also supported by modern LCD monitors), here's the pin mapping: PIVOT VGA 1,6,13 4,5,6,7,8 VIDEO GND 2 1 RED VIDEO 4,10 NC PINS 4 & 10 JUMPERED TOGETHER ON PIVOT END OF CABLE 5 2 GREEN VIDEO 9 3 BLUE VIDEO 11 11 C & V SYNC GND 12 14 V SYNC 14 10 H SYNC GND 15 13 H SYNC In a BMOW composed an excellent list of the tradeoffs inherent in my VGA converting cable build. Since the SE/30 has become the target system of choice for this card, I'll add a bit of tangential hacking info due to a recent development detailed below: This would be another reason I had for having looked into converting the high profile ThickNet connector into a panel mount, solder cup DA-15 for video out on this particular card: My approach for fitting the RCPII/IIsi to the SE/30 is readily apparent in that new pic: Compare the NIC breakout boards leaning on the /30, you can see the difference in width of the breakout PCBs. Either will work, but I have that older MacCon and the ThinNet Hub ready at hand. One side of the card clears the Pivot card nicely and the other is itching to have a hole drilled in it.

The older MacCon NIC/two flavor/two connector breakout panel PCB offers added flexibility for installation of the antenna/card for ants' wonderful With the wrong angle hack for that Asante NIC and same for the RCPII/IIsi, I'm hoping I can set the SE/30 up on the AppleDisplayUnit ™ as a wireless bridge to both Ethernet equipped and the PhoneNet limited machines sitting on its rainbow hued shelves. I don't have the wireless conversion goodies on hand for testing, but I'm guessing fitment issues will need to be overcome to get things arranged behind a three connector flavored NIC? I've got no wired connection available, so this appears to be coming together rather nicely, even without the 50MHz PowerCache accelerator I'd never expected to have up and running.

If the IIsi Pivot card HeaderChopHack doesn't work out, I've got the SE/30 version available to get the SE/30 up and running on the KVM setup if I do the wrong angle hack to the three connector MacCon NIC. Having it set up as a server for the menagerie would be another benefit of getting my unexpected /30 up and running there. At any rate, ants has opened up some great possibilities for all with his wireless SE/30 conversion. I've always figured on desoldering the annoying connector Radius used for the breakout cable and wiring the cable fab directly to its thru-holes.So lopping off the card's panhandle for the connector seemed the obvious approach to take for SE/30 fitment to me. Required mods to the other end of the RCPII/IIsi would be: Removing/jumper wiring/hot gluing one large cap 'box' due to interference with the chassis mounting ear.

Moving the addressing headers/jumpers to the solder side due to a bit of interference with the CRT. Filing a 'V' notch on the front of the card to interface with same on the edge of the return bend of the chassis. The notching would help in replacing the lateral support of the blocked mounting ears of the chassis. Removing the addressing jumpers/headers from the component and re-installing them on the solder side for CRT clearance. Back on topic: Maybe this tangent will get others interested in the RCPII/IIsi, this cable build, wireless SE/30 and possibly wrong angel PDS card hacks. Not a bad application at all for an unaccelerated SE/30! ' Edited October 22, 2017 by Trash80toHPMini.

So I finally managed to hack a cable together to test my card. I wired up a standard Mac video connector and plugged in an adapter to get VGA. Adapter is set to 13' 640.480.

I get an image output to my multisync flat panel that supports all the oddball Mac resolutions - nothing wrong here so far. Problem is I can not seem to move the mouse cursor now. The keyboard is responsive and mouse button clicks are recognised as well, I just can not move the pointer around.

ROM on my card is version 2.6. Happens with stock SE/30 ROM as well as with IIsi ROM.

So 24 or 32bit addressing does not matter as it seems. OS does not matter as well as I can not move the mouse even without an OS loaded.

As soon as the card is installed it defaults to having the main monitor on the external screen so I can not check if the mouse would move on the internal screen and only gets stuck when moving it over to the external one. Edited November 5, 2017 by Bolle. Very neatly done. What termination type connector did you use? I really like your right angle connector twist. ' Looks like you used the female ends of the breadboard jumper wires as your board connector? Was looking for my pic of the SuperMac(?) cable showing the dedicated RGB ground lines in twisted pair config with the RGB video lines.

That and adding the ferrite ring are the only possible improvements I can think of for your build. While I was looking, I ran across BMOW's observation that there are different pinouts for two different versions of the RCPII/IIsi. I'll have to dig 'em out and post pics to get the differentiation documented. I just noticed you appear to have two different Pivot cards, and they're different! Look at the area between that rectangular yellow capacitor C4 and the video connector. Shows a card with CR8 and R14 between the capacitor and the connector, but shows a card with only CR6 in that space.

Those aren't the same card. Mine looks like the first example, with CR8 and R14. I don't know if that's an important difference or just a minor board rev. Do both of your cards actually work? Here's his cable build info and the VGA converter schematic. Oh snap, I got it to work!

I had to connect a real monitor to the Pivot card before I could see anything - simply putting jumpers on the sense lines and then looking in the monitors control panel didn't seem to be enough. I haven't been able to test a dual-head setup yet, since I only have one monitor, but I was able to boot and run at 832 x 624 x 256 colors @ 75 Hz with the Pivot card as the sole video card. For future reference, pin 1 on the Pivot card is the pin adjacent to the 'J2' text on the board's silkscreen. The pins are: 1 RED GND 2 RED 3 C SYNC 4 SENSE0 5 GREEN 6 GREEN GND 7 SENSE1 8 N.C. 9 BLUE 10 SENSE2 11 C & V SYNC GND 12 V SYNC 13 BLUE GND 14 H SYNC GND 15 H SYNC If you want to build a video cable to connect to a Mac-standard DB-15 monitor, then just wire those pins straight to the DB-15, matching them up pin for pin. Pivot card pin 1 connects to DB-15 pin 1, Pivot pin 2 connects to DB-15 pin 2, etc.

If you want to build a combo video cable and VGA adapter with a hard-coded 832 x 624 sense code (which seems to be the highest possible Pivot resolution that's also supported by modern LCD monitors), here's the pin mapping: PIVOT VGA 1,6,13 4,5,6,7,8 VIDEO GND 2 1 RED VIDEO 4,10 NC PINS 4 & 10 JUMPERED TOGETHER ON PIVOT END OF CABLE 5 2 GREEN VIDEO 9 3 BLUE VIDEO 11 11 C & V SYNC GND 12 14 V SYNC 14 10 H SYNC GND 15 13 H SYNC I remain buried under the reorganization/project condensation/hack abatement rubble, but I'm slowly getting there. May have decided on taking a different approach to modifying the ThickNet/ThinNet breakout board in the IP.

Instead of using ThinNet, I'll likely be removing both connectors. I'll incorporate. The BNC port is perfect for the antenna and I'll use a solder cup DA-15 to make a hardwired cable for the required transceiver to the vacated ThickNet connector's thruholes.

Should be pretty slick if I ever actually get around to doing it. ' Edited November 12, 2017 by Trash80toHPMini. Interesting, did you have a problem with using the plastic housings as a removable connector? The housings on my cable fit perfectly, but a bit firmly into the card's connector shroud.

Is there a problem with the pin to crimp contact connection electrically? I'm almost certain that using MEK to weld the housings together to form a unit will be problematic for use as a removable connector. The unitized assembly may go in, but it probably won't come back out unless the outsides of the resulting rectangle are filed (maybe sanded) to a bit smaller profile.

I've been looking for the pic I have of the SuperMac(?) VidCard cable showing the ferrite ring and the twisted RGB/dedicated ground pairs used in place of the Radius cable's micro co-ax cable shielding. I ran across the zombie's mention of his gallery pic of the Xceed cable assembly in your Xceed thread: No joy yet on the pic or in finding my borked Radius cable. However I did find a pic illustrating the only instance of a ferrite free VidCard cable assembly I've ever collected. I wish a ferrite juju master would chime in to explain why it may or may not be advisable to implement it for this cable build. I'm curious to learn how size and shape matter in terms of tuning its effectiveness?

It's curious to me that the Xceed cable uses tubular form factor 'rings' without the wire loopage seen in most 'ring' configurations. I also found the full set of VGA sense coding pages from which the diagram above was taken.

I'll need to post those here as collecting tangential sense coding/cable/adapter building info here seems the thing to do. Yep, the model I'm using for this build includes both ferrite ring loopage and twisted pair signal/ground implementations. Anecdotal evidence for both is overwhelming, I've been collecting every picture of every card/cable combination for the Compacts that I've run across for well over fifteen years now and exceptions to either 'design rule' amount to one single instance IIRC, though in the auction pics of one combination evidence for or against presence of the ferrite ring is inconveniently hidden from view. Edited November 13, 2017 by Trash80toHPMini. Cross one off the list: figured out the confusion about my having two versions of the card and I do., but all four examples of the RCPII/IIsi are identical. The first pic I had posted in the other thread was of the Pivot SE/30 cable in its socket on the SE/30 version of the Pivot Card. In the second pic it was shown in the socket of the IIsi version.

No mystery there. Interesting that the two cards are so nearly identical, maybe I can use clues from visible traces on the SE/30 version to figure out where the connector lines wind up on the IIsi card for the header-chop investigation? Meanwhile, in looking over I cribbed his trick for preserving reversibility of this breakout board video connector hack and a most convenient solution for mounting the ThickNet transceiver for mine!

If we use the original backplane plate where ants substituted aluminum angle everything is simplified. Mounting small 'L-brackets' behind the DA-15 solder cup panel mount connector's standoffs allows for mounting the breakout board to them aligned nicely from behind its ThickNet connector board mount standoffs. There is then no need to desolder anything at all from the breakout board! Not only that, my ThickNet Transceiver will mount vertically on its intended connector right next to the neck board and the Antenna for the WiFi board mounts on the backplane plate with the video connector with no need for removal of the ThinNet BNC connector in doing so. ' I'll have to translate/condense that mess of.TXT into pictures.

Ferrite beads prevent interference in two directions: from a device or to a device. A conductive cable acts as an antenna – if the device produces energy, this can be transmitted through the cable, which acts as an. In this case the bead is required for, to reduce. Conversely, if there are other sources of EMI, such as household appliances, the bead prevents the cable from acting as an antenna and receiving interference from these other devices.

This is particularly common on data cables and on medical equipment. May not need it, but I'll definitely be putting ferrite rings on my cables. ' I ordered up the ThickNet-10baseT transceiver for my SE/30 build and placed an offer on the VONETS WiFi card. Edited November 14, 2017 by Trash80toHPMini. Is that really necessary? The original video cable from Radius doesn't have one.

The import of that just hit me. Has anyone got a pic of Radius' cable for the IIsi version of the card?

Re-read the ferrite bead article just now and realized why there would be differentiation in the cable implementation between models of the Pivot card as well as the presence of three ferrite rings on Xceed's internal/external cable harness. The SE/30 has a 'Television' inside the case whereas the IIsi does not. Alleviating RFI between components, CRT and external cable wiring for the internal/external monitor setup would have been important for the Xceed GS card setup as it was in bottling up RFI produced by the SE/30's CRT and picked up on the internal wiring 'antenna' of the RCPII cable for the SE/30. There would have been no absolute necessity for the bead's shielding in the case of the IIsi cable because there was no CRT induced RFI to be picked up on the internal cable and the ferrite bead present on the card's dedicated Pivot video cable would have sufficed.

Upshot: while the bead may not be as necessary for an SE/30 cable build in this age of digital TV, it's probably a good idea to include it as it was necessary for regulatory compliance back in that day of analog TV and rabbit ears. Edit: while likely not quite as WA as most of my Guesses, I am guessing here nonetheless.

' Edited November 15, 2017 by Trash80toHPMini.