RS485 vs Ethernet

[ZeroResistance]

I recently read regarding RS485 the following statement

The multiplication of the data rate in Mbps and length of cable in Meters should not be more than 10

this is some kind of rule of thumb for length of cable and data rate over a RS485 network.
So a data rate of 10Mbps would limit the distance to 1m.

Which got me thinking that even Ethernet uses differential signalling, and it uses 2 differential pairs to send and receive respectively, here I'm talking about 10 and 100Mbps speeds and not about gigabit ethernet which uses all 4 pairs?

Why then does this rule not apply to Ethernet, I mean I see that ethernet lan networks which work upto 100Mbps could use pretty long cables some times in 10's of meters, and if I remember correctly Ethernet uses a clock speed of 125Mhz for 10/100Mbps what does Ethernet do that cannot be done in RS485?

TIA

[rrinker]

 Impedance for one. And Ethernet is a 1 to 1 connection, not multidrop like RS485. Even lower speed Ethernet requires twisted pairs to maintain impedance characteristics, while RS485 at fairly high speeds, at least for a serial bus, works fine with all sorts of wire. Really, the most they have in common is that they use differential signaling.

[pwlps]

...what does Ethernet do that cannot be done in RS485?

The Ethernet protocol features a collision detection mechanism.

[ZeroResistance]

Impedance for one. And Ethernet is a 1 to 1 connection, not multidrop like RS485. Even lower speed Ethernet requires twisted pairs to maintain impedance characteristics, while RS485 at fairly high speeds, at least for a serial bus, works fine with all sorts of wire. Really, the most they have in common is that they use differential signaling.

So how does impedance change the game here?

...what does Ethernet do that cannot be done in RS485?

The Ethernet protocol features a collision detection mechanism.

Ok, So that is a software specific feature, correct? I was mainly interested in how does ethernet circumvent the cable length issue while still moving data around at high rates.

[pwlps]

So how does impedance change the game here?

Precise impedance matching ensures that there is no significant reflected signal, you can send a data packet without worrying it will get corrupted by its echos.  Without impedance matching you have to wait after every bit until the echoes fade out (the echoes manifest as oscillations following each pulse edge).

[paulca]

And Ethernet is a 1 to 1 connection

Only modern Ethernet.  Unless I miss understood.  Ethernet was traditionally a "bus" network with everyone broadcasting on the same wire/medium.  Wifi still is.  Carrier-sense multiple access with collision detection (CSMA/CD).  "Connections" are not implemented at the Ethernet level, Ethernet is fire and forget, connectionless.

Of course the limitations of a coaxial bus network were realised and it moved to a hubed star topology (A hub being a multi-port repeater) but the larger the network segment the more bottle neck from the single collision zone.  Switches (a multiport bridge) became cheaper until now nobody would really consider using a bus or hub ethernet network and by using a switch the collision domains do become more-or-less 1 to 1, though it's a bit more complex depending on the switch architecture, network topology and size of the MAC tables in the switches.

[ZeroResistance]

So how does impedance change the game here?

Precise impedance matching ensures that there is no significant reflected signal, you can send a data packet without worrying it will get corrupted by its echos.  Without impedance matching you have to wait after every bit until the echoes fade out.

So is twisted pair one of the ingredients for impedance matching?, and if we do correct impedance matching in RS485 will the length limitations at high data rates be resolved?

[mikeselectricstuff]

That ratio seems very conservative. 4M over 100m.of cat6 works fine. Using cat5/6, the cable resistance can often be the first limit you hit, but using thicker cored cable overcomes this.
If sending multiple rs485s on one cable, crosstalk can be an issue, so I always spec cat6 for this

[pwlps]

So is twisted pair one of the ingredients for impedance matching?, and if we do correct impedance matching in RS485 will the length limitations at high data rates be resolved?

I would say yes, in principle you can increase the bandwidth by careful impedance matching. (but I don't have experience with RS485 so I don't know if there are other limiting factors built-in there maybe somewhere at the protocol level, let's RS485 specialists comment on that). 

[Berni]

The reason why 100Mbit Ethernet is better is the encoding.

Both RS485 and BASE100 Ethernet use impedance matched twisted pair that is terminated on the end. The reasons that make Ethernet better is the use of isolation transformers on each end to drastically cut down on common mode interference and the use of 4B5B and MLT-3 encoding. One of the reasons for the encoding is to remove DC from the signal so that it can pass trough those isolation transformers, the other reason for the encoding is to shove more bits into less frequency bandwidth by using 3 level signals rather than binary. Additionally a bit of equalization is often used to correct for the cables frequency response.

Since cables tend to get more lossy at higher frequency means that Ethernet experiences less signal loss on a cable and the resilience to noise makes the whole thing more reliable.

That being said there is no real hard limit on cable length. In general better quality cable allows you to go longer distances until the signal degrades too much. So the numbers you find are more of a general rule of thumb of what to expect from a typical cable in typical use cases. In practice you will find that with enough care you can get even RS485 to run at huge speeds over impressive distances (But it might not work under all cases or not be quite perfectly reliable).

For transferring a large amount of data over long distances at high speeds Ethernet is the way to do it. You don't even need to implement any of the real protocols to use it. You only need it when you want to connect to a real network with real routers and switches. You can still just connect two Ethernet PHYs together with a network cable and use it like a really fast serial cable between two MCUs using your own proprietary protocol.

[paulca]

As an ill-informed IT person I thought the cable length for Ethernet was determined by timing, not signal strength.

[Berni]

As an ill-informed IT person I thought the cable length for Ethernet was determined by timing, not signal strength.

The RX and TX data path are not really coupled together, its much like two separate tubes going in each direction. Not that much in the way of smarts in the Ethernet PHY, its only smart enough to detect if more than one device is talking on the network and report a collision so that the Ethernet controller can do something about that (Since you can still use old school hubs on modern Ethernet ports). I think it can also signal a error in the encoding pattern but not completely sure about that one.

An example of a bus that is limited in length by timing is the CAN bus.

To completely avoid collisions all together the CAN bus uses a special arbitration method where all devices on the bus can play a role in. Because of the way it works it requires devices to respond correctly within 1 bit period, so if the length of cable is long enough to delay the signal by more than that amount the arbitration will start failing and everyone will start trying to resend data and constantly fail again and all hell breaks loose. Because of this you will get a very sudden cutoff point in the longest possible cable as only a meter or two of extra cable might cause a previously working bus to stop working all together. Getting better quality cables won't really do much (Apart from getting higher velocity factor cable but that can only go so far before you start nearing the speed of light)

EDIT:
Actually there is one case where propagation delay can be problematic in Ethernet. Its in that case of having multiple devices on the same line where two devices transmit a packet on the line at the same time but are far enough for there packets not to collide due to propagation delay, but a device sitting somewhere in the middle will have the two packets collide there (Like two trains running towards each other from the two devices on opposite ends of the line). So the devices on the end would both think there was no collision and not re transmit the packet, but the device in the middle seen just a garbled mess of both packets slammed together.

[mansaxel]

As an ill-informed IT person I thought the cable length for Ethernet was determined by timing, not signal strength.

That is somewhat true for the 10Base-2 (and the old 10mm yellow banana cable as well) network where you have a multidrop network made from coax and T-pieces.

For the other physical modes where you as discussed upthread have switches or run back-to-back between computers, distance is limited by attenuation. Electrical 10/100/1000Mbit Ethernet is -- by standard -- limited to 5+5+90 metres of cable (think switch -> patch cord -> patch panel -> fixed installed cable -> outlet -> patch cord -> computer) but in practice, and with fewer splices, can be run up to about 200 metres on good cable. 

Optical has no practical limit, but you usually need an amplifier after ~110km of single mode cable, providing you have high-power transceivers. (People suggesting multimode should be taken outside and reeducated, mostly because multimode is an echo chamber where signals exit the Hall Radius after 550 metres at 1000Mbit/s. This is bad for you, and today is as expensive as singlemode.)

I have gotten 1000Mbit/s to work on 125 km, without intermediate amplifiers, using a long-range transceiver. We run a couple of un-amplified ~30 km links at 100Gbit (using 100G-BASE-LR4 which is a 4-channel DWDM around 1310nm) across town, and I'm just now preparing for a job where we'll be renting 100Gbit links over 600km spans. Those are handed off to us using 100G-BASE-LR4 as well.

Society evolution through technology tip: If you want your country to flourish, make sure that dark fibre is available and cheap. It is an amazing force multiplier.

[ZeroResistance]

I recently read regarding RS485 the following statement

The multiplication of the data rate in Mbps and length of cable in Meters should not be more than 10

this is some kind of rule of thumb for length of cable and data rate over a RS485 network.
So a data rate of 10Mbps would limit the distance to 1m.

From https://en.wikipedia.org/wiki/RS-485 :

As a rule of thumb, the speed in bit/s multiplied by the length in metres should not exceed 10⁸

That would be 10e8/10e6 => 100m @ 10Mbps.

That's some amazing information, I probably didn't register that raised to 8, but that pretty much nails this question.

[dom0]

...what does Ethernet do that cannot be done in RS485?

The Ethernet protocol features a collision detection mechanism.

No Ethernet link made in this millenium uses CDMA/CD, because it uses full-duplex. Gigabit Ethernet uses echo cancellation to run full duplex over the same pair (transmitting while receiving on the same channel, conceptually like a telephone).

[mansaxel]

No Ethernet link made in this millenium uses CDMA/CD, because it uses full-duplex. Gigabit Ethernet uses echo cancellation to run full duplex over the same pair (transmitting while receiving on the same channel, conceptually like a telephone).

But most every electrical Ethernet port retains the ability, at least at 10Mbit/s. It of course for all practical purposes is obsolete now, but it still is there.  I know we ran 10/half duplex as standard on some client systems as a crude but efficient speed regulator up to about 2010.  A strongly contributing factor was the complete and utter failure that was the first 10 years of 100Mbit/s Ethernet autonegotiating devices. While 100 Mbit/s frequently required manual intervention and carefully controlled configuration to work at all, 10Mbit/s half-duplex worked, and reliably so.

Gigabit Ethernet over 4 pairs copper is, in comparison, a very good protocol, and the implementations are with very few exceptions interoperable. They even work reasonably well towards 100Mbit/s devices, and in auto-negotiation at that.

[ZeroResistance]

For transferring a large amount of data over long distances at high speeds Ethernet is the way to do it. You don't even need to implement any of the real protocols to use it. You only need it when you want to connect to a real network with real routers and switches. You can still just connect two Ethernet PHYs together with a network cable and use it like a really fast serial cable between two MCUs using your own proprietary protocol.

How would a Ethernet PHY compare to a RS422 transceiver. So lets say we take a CAT5 cable and and use 2 pairs, one setup with a RS422 transceiver and another with only a Ethernet PHY and run them both at say 1Mbps, wouldn't these 2 setups be fundamentaly the same, I mean give similar performance?

Also how do we interface the MCU with the PHY, I see that most PHY's are MII / RMII interface, is it easy to create such an interface on a MCU, the MCU's with bulit RMII generally have MAC's embedded in them.

[ZeroResistance]

If I use only a PHY and a MCU, am I still limited to send data in Ethernet frames / packet size? Or can I send arbitrary length data?

[ZeroResistance]

You can send whatever you want, but if you do so the ethernet switch won't know what to do with your packets and very likely will just drop them I'm afraid.

Are there know techniques of connecting a PHY to MCU, most PHY's have a MII/ RMII port and MCU's don't seem to have this by default and if the do have one they have an embedded MAC as well?

[borjam]

And Ethernet is a 1 to 1 connection

Only modern Ethernet.  Unless I miss understood.  Ethernet was traditionally a "bus" network with everyone broadcasting on the same wire/medium.  Wifi still is.  Carrier-sense multiple access with collision detection (CSMA/CD).  "Connections" are not implemented at the Ethernet level, Ethernet is fire and forget, connectionless.

Indeed, you are right.

Ethernet has gone through several iterations. The first one was a bus based on coaxial cabling. Bring a bus, collision detection and avoidance was mandatory of course.

The first star cabling schemes using twisted pair were still a bus, with the hub being a multi port repeater. So it was still half duplex and it needed collision detection.

However, once switches (which are multi port bridges instead of repeaters) became popular they made full duplex Ethernet possible. And collisions do not exist on full duplex Ethernet.

Hubs were somewhat common during the first years of twisted pair 10 Mbps and 100 Mbps Ethernet until switches became more affordable. On GbE I have never seen a hub.

If you are on a twisted pair Ethernet network with switches and you have more than zero collisions on a port probably you have a negotiation mismatch (unless the Ethernet card of the affected node is really ancient), which was quite common on Fast Ethernet (100 Mbps). Probably one of the sides of the is in full duplex while the other is in half duplex. I have seen such mismatches reducing effective throughput to values as low as 64 Kbps.

[Berni]

For transferring a large amount of data over long distances at high speeds Ethernet is the way to do it. You don't even need to implement any of the real protocols to use it. You only need it when you want to connect to a real network with real routers and switches. You can still just connect two Ethernet PHYs together with a network cable and use it like a really fast serial cable between two MCUs using your own proprietary protocol.

How would a Ethernet PHY compare to a RS422 transceiver. So lets say we take a CAT5 cable and and use 2 pairs, one setup with a RS422 transceiver and another with only a Ethernet PHY and run them both at say 1Mbps, wouldn't these 2 setups be fundamentaly the same, I mean give similar performance?

Also how do we interface the MCU with the PHY, I see that most PHY's are MII / RMII interface, is it easy to create such an interface on a MCU, the MCU's with bulit RMII generally have MAC's embedded in them.

You normally can't run a Ethernet PHY at a arbitrary baud rate (Tho you can probably trick it to some extent by feeding it the wrong clock frequency) and the Ethernet isolation transformer might not like working at frequencies this low. But ignoring all of that you would still get an advantage out of Ethernet. The RS422 uses direct UART encoding and so it requires a minimum of 500KHz of bandwidth for a 1Mbit baud rate while Ethernet uses MLT-3 encoding to require only 250KHz of bandwith at 1Mbit. This means less signal losses in the same cable. Additionally being transformer isolated makes it immune to ground loop problems up to a few kilovolts.

That being said driving a Ethernet PHY is significantly more complex than just UART. So in most cases the advantages are only worth it if you need the 100Mbit or 1Gbit speeds. Running RS422 at only 1Mbit will work fine over some very long cables. Getting high speeds(>50Mbit) over long cables(>50m) to work reliably is actually rather difficult, but with Ethernet its not a problem at all.

Because of the old hub approach to Ethernet the device can expect to see a lot of traffic that is to be ignored by the device, so indeed the MAC layer of the networking protocol is usually done in hardware, but can be set to receive everything on the bus(This does force you to using a minimum 64byte long frame tho)  Any MCU supporting Ethernet will have a MMI, RMII, GMII, RGMII... etc bus and this is simply Ethernet in parallel 4 bit or 2bit bus form. Running such a bus without a built in controller is probably pretty difficult, perhaps it can be done with QSPI, but anyway Ethernet is not that hard to find on MCUs. If you adhere to the really simple MAC layer spec then you can also put normal L2 network switches between your devices and your packets will get routed trough allowing you to build a big complex network with high speeds everywhere, yet still ignore any of the higher up stacks that are much much more complex like IP and TCP. Much like a massive RS485 bus on steroids and caffeine.

But that's if you need the speed. There is no point in using a firehouse to water a little flower in a pot.

[ZeroResistance]

You normally can't run a Ethernet PHY at a arbitrary baud rate (Tho you can probably trick it to some extent by feeding it the wrong clock frequency) and the Ethernet isolation transformer might not like working at frequencies this low. But ignoring all of that you would still get an advantage out of Ethernet. The RS422 uses direct UART encoding and so it requires a minimum of 500KHz of bandwidth for a 1Mbit baud rate while Ethernet uses MLT-3 encoding to require only 250KHz of bandwith at 1Mbit. This means less signal losses in the same cable. Additionally being transformer isolated makes it immune to ground loop problems up to a few kilovolts.

That being said driving a Ethernet PHY is significantly more complex than just UART. So in most cases the advantages are only worth it if you need the 100Mbit or 1Gbit speeds. Running RS422 at only 1Mbit will work fine over some very long cables. Getting high speeds(>50Mbit) over long cables(>50m) to work reliably is actually rather difficult, but with Ethernet its not a problem at all.

Because of the old hub approach to Ethernet the device can expect to see a lot of traffic that is to be ignored by the device, so indeed the MAC layer of the networking protocol is usually done in hardware, but can be set to receive everything on the bus(This does force you to using a minimum 64byte long frame tho)  Any MCU supporting Ethernet will have a MMI, RMII, GMII, RGMII... etc bus and this is simply Ethernet in parallel 4 bit or 2bit bus form. Running such a bus without a built in controller is probably pretty difficult, perhaps it can be done with QSPI, but anyway Ethernet is not that hard to find on MCUs. If you adhere to the really simple MAC layer spec then you can also put normal L2 network switches between your devices and your packets will get routed trough allowing you to build a big complex network with high speeds everywhere, yet still ignore any of the higher up stacks that are much much more complex like IP and TCP. Much like a massive RS485 bus on steroids and caffeine.

But that's if you need the speed. There is no point in using a firehouse to water a little flower in a pot.

So, to sum up the big advantage of Ethernet over RS485 is

1. Isolation
2. Encoding

If we incorporate these 2 into RS485 would we have something as good as Ethernet?

Secondly my intent wasn't to run the PHY at a arbitrary baud rate, but to find if the PHY still limits you to send data in 64 byte frames? I mean If we have a private ethernet network and send arbitrary amount of bytes to the PHY will the PHY act like a true pipe and deliver it to the other end or will it do some processing on its own and drop the packets if they are not as per spec.?
I guess encoding and CSMA/CD is handled in Layer 2 of Ethernet so that would be the MAC sub layer correct?
so the PHY would just be a dumb transmitter that doesn't enforce any rules on data format, would this be correct to say this?

[Berni]

So, to sum up the big advantage of Ethernet over RS485 is

1. Isolation
2. Encoding

If we incorporate these 2 into RS485 would we have something as good as Ethernet?

Secondly my intent wasn't to run the PHY at a arbitrary baud rate, but to find if the PHY still limits you to send data in 64 byte frames? I mean If we have a private ethernet network and send arbitrary amount of bytes to the PHY will the PHY act like a true pipe and deliver it to the other end or will it do some processing on its own and drop the packets if they are not as per spec.?
I guess encoding and CSMA/CD is handled in Layer 2 of Ethernet so that would be the MAC sub layer correct?
so the PHY would just be a dumb transmitter that doesn't enforce any rules on data format, would this be correct to say this?

Yes in theory that is mostly what separates half duplex 100Mbit Ethernet from RS485.

MAC is part of the 2nd layer and has no knowledge of the physical medium. Its just a wrapper around the data that attaches a "From: To:" tag on it so that network switches can determine where something should be going according to the MAC address.

Layer 1 is the physical layer that does all of the encoding and collision detection. Its this layer that places the required preamble in front along with the start of packet byte and finishes the frame with the required interpacket gap. Only some of this functionality lives inside the PHY chip, the rest is inside the Ethernet controller. For example the PHY needs to have the preamble and start of frame fed into it nibble by nibble like its normal data when transmitting. It just starts paying attention when the transmit enable pin is active, taking in data from the MII bus, running it trough the encoding algorithms and blindly spitting it out onto the Ethernet bus. If it senses someone else also driving the bus then it raises its error pin to tell the controller about it. Receiving is similar, it just listens on the bus and upon seeing appropriate bit transitions it starts to synchronize itself to the data stream while pumping it trough the decoding algorithm and out of the MII bus. Its then the Ethernet controllers job to look at the data to find where the packet starts and assembling it back into bytes to be handed off to the MAC layer above for further processing. So in this regard the PHY is very dumb and could be used as a direct 4bit link of the MII bus data pins. If you run the MII bus using a FPGA or similar you can completely disregard the Ethernet specification and send whatever data you want in whatever packet size you want. Heck you could connect 4 switches to the MII TX data pins and have them toggle 4 LEDs on the MII RX pins on the PHY on the other end. The PHY just blindly does whatever you tell it to do.

But PHYs can also be very complex in regard to there other features such as link auto detection, automatic crossover of RX TX, distance to fault using reflectometry...etc and have a bus similar to two way SPI to configure those. But in general the PHY automaticaly starts up in a default configuration that does the basic job.

You can in theory bitbang a Ethernet PHY to make such a totally raw data link, but typically the PHY generates all the timings so you need to follow its pace. Something that's not so easy to do on a MCU as the parallel bus speed of a MII link is 25MHz, all the other bus types are even faster. But with perhaps some QSPI re purposing or funky interrupt driven DMA work it can probably be done, very easy to do on a FPGA tho.

[paulca]

However, once switches (which are multi port bridges instead of repeaters) became popular they made full duplex Ethernet possible. And collisions do not exist on full duplex Ethernet.

You can still get collisions as switches cannot always handle receiving more than one frame for a single destination on multiple ports.  If you consider a dozen hosts responding to a discovery or broadcast ping.  It comes down to the switch, how many internal channels it has and whether it even has frame buffer space to store any of these packets.  I'm don't believe they emit the collision jamming signal on the receiving ports, I expect they simply drop the unswitchable packets.

Of course it's fairly  easy to fix this with a router that can queue to put the packets into sequence, in the network somewhere, but the circumstances are limited to specific use cases.

[mansaxel]

You can still get collisions as switches cannot always handle receiving more than one frame for a single destination on multiple ports.  If you consider a dozen hosts responding to a discovery or broadcast ping.  It comes down to the switch, how many internal channels it has and whether it even has frame buffer space to store any of these packets.  I'm don't believe they emit the collision jamming signal on the receiving ports, I expect they simply drop the unswitchable packets.

Most every professional switch these days has queues and handles this reasonably well. What you write can be true for a switch where "store" in "store-and-forward" is a few KiB per port. A 10/25/100GE switch typically has 30-40 MiB of buffers; the ones I'm building with at the moment have some 37.8MiB. My applications typically run at from a few Mbits/s RTP up to 1.5Gbit RTP, all multicast and with quite controlled packets per second rates. Also, they use PTP which has extreme demands on timing, which works, so, no, I'd argue that "several frames arriving at the same time (FSVO "same") and having the same destination mac address" is a (admittingly sometimes hard) queuing problem, not a collision problem.   

[ve7xen]

However, once switches (which are multi port bridges instead of repeaters) became popular they made full duplex Ethernet possible. And collisions do not exist on full duplex Ethernet.

You can still get collisions as switches cannot always handle receiving more than one frame for a single destination on multiple ports.  If you consider a dozen hosts responding to a discovery or broadcast ping.  It comes down to the switch, how many internal channels it has and whether it even has frame buffer space to store any of these packets.  I'm don't believe they emit the collision jamming signal on the receiving ports, I expect they simply drop the unswitchable packets.

Of course it's fairly  easy to fix this with a router that can queue to put the packets into sequence, in the network somewhere, but the circumstances are limited to specific use cases.

What you're describing isn't a collision, and CSMA/CD won't / wouldn't detect it anyway. In full-duplex Ethernet there is only one transmitter capable of transmitting on each pair by physical design (or there is echo cancellation in GigE+). This situation can result in a transmit buffer overflow, and will show up in your switch statistics as an output drop. Most switches use a store-and-forward architecture, so every port needs a receive buffer of some sort, and most designs are non-blocking on the backplane, so input drops are basically impossible. Any practical design also requires an output queue length of > 1 to handle the situation where the output port is occupied when a packet arrives for it (very common) and avoid resulting in massive packet loss. These queues don't have to be that large, but many modern switches have multiple MB per port; all modern switches have at least a few MB of (sometimes shared) transmit buffer spread across their ports.

Flow control is a sort of signalling mechanism to tell a transmitter to slow down, but it's not that useful, because of the multipoint nature of Ethernet and that the usual place for buffers to fill is at the output port, so it's non trivial to reflect this back to the input port and not cause delays for other frames destined elsewhere. Likewise a switch will never (and can't, anyway, since it doesn't transmit on its receive lines) create a collision on purpose.

[paulca]

I wasn't aware that modern switches had such large buffers.  I do remember on a Cisco course that they used something like write through switching so they didn't "store and forward" persay which would create a frames worth of latency, but started writing to the output port as soon as the input port started receiving (and the destination was determined).

Still a large buffer can result in latency which might be fine on very fast links and non-timing critical protocols, but on slower links and more time sensitive stream based packets it would be better to simply drop packets.  I believe packet switching portions of telephone networks work this way, when never is better than late as users will barely reprieve a packet dropped, but will notice an out of order late one as a chirp.  If the "other end" is likely to drop the packet as it's late, switches can choose to "early drop" as soon as they detect the packet is behind schedule so as to not create bottle necks further along sending out of date packets.

But I studied all this back in like 2002 so it's a bit foggy and things have most certainly moved on.

[ve7xen]

I wasn't aware that modern switches had such large buffers.  I do remember on a Cisco course that they used something like write through switching so they didn't "store and forward" persay which would create a frames worth of latency, but started writing to the output port as soon as the input port started receiving (and the destination was determined).

Some switches optionally do cut-through switching, where the switch starts forwarding as soon as it's received the destination MAC address, assuming the destination port is known, available, and operating at the same bit rate. This has some issues (for example the switch can't verify the FCS before forwarding, so will propagate errors) and usually isn't enabled by default, but can be useful when minimum latency is the goal. As the bit rates increase, though, the latency advantage decreases too (as frame size stays more or less constant). And since you need to degrade to store-and-forward in any situation you can't use cut-through, it's the lowest common denominator.

Still a large buffer can result in latency which might be fine on very fast links and non-timing critical protocols, but on slower links and more time sensitive stream based packets it would be better to simply drop packets.  I believe packet switching portions of telephone networks work this way, when never is better than late as users will barely reprieve a packet dropped, but will notice an out of order late one as a chirp.  If the "other end" is likely to drop the packet as it's late, switches can choose to "early drop" as soon as they detect the packet is behind schedule so as to not create bottle necks further along sending out of date packets.

Yes, this is the so-called 'bufferbloat' problem. The length of buffer is usually configurable for this reason, often based on individual QoS queues, so your realtime traffic will drop very quickly, while bulk traffic can queue as long as you have buffer space, or whatever else is appropriate for your application. Modern Ethernet switches are incredibly flexible, it's pretty amazing what the ASICs are capable of.

This is getting to be very off topic though so I'll leave it at that .