5
\$\begingroup\$

I already tried googling but I cannot find an exact answer. Some say it is synchronous, some say asynchronous.

For example, see these links:

https://www.quora.com/Is-Ethernet-synchronous-or-asynchronous

https://superuser.com/questions/260965/what-is-ieee-802-3-ethernets-communication-type-synchronous-or-asynchronous#:~:text=Ethernet%20is%20Asynchronous.,no%20clock%20pins%20or%20pairs.

Ethernet has no separate wire for clock signal, so does it make it asynchronous?

But Ethernet also does not use start and stop bits, so does it make it synchronous?

And by the way, can we encapsulate Ethernet into RS-232? That is, can we use RS-232 to carry or transport Ethernet?

\$\endgroup\$
7
  • \$\begingroup\$ That depends on which Ethernet interface you mean. Do you have a specific one in mind? \$\endgroup\$
    – Justme
    Apr 5, 2021 at 17:46
  • 1
    \$\begingroup\$ What does "encapsulate Ethernet into RS-232" even mean? I can use a processor to receive characters by RS-232 and send them over ethernet...which is pretty much what all consumer computing devices do. \$\endgroup\$ Apr 5, 2021 at 17:58
  • 1
    \$\begingroup\$ It doesn't have a start bit, but it has a start-of-frame which is called a preamble packet 101010...This data "clocks" or you can say it embeds the clock rate. This can be used to synchronise the sampling clock at receiver at the beginning of every frame on Ethernet. I guess it's still debatable to whether call it synchronous or asynchronous. One can argue both the ways. \$\endgroup\$
    – Mitu Raj
    Apr 5, 2021 at 19:31
  • 3
    \$\begingroup\$ Do not get worked up about terms like synchronous or asynchronous. Those terms dont really matter, you are going to see here and elsewhere that the definition changes per company or group of people or standard interface, etc. Just dont care about those terms. Then of course ethernet is ethernet there are tons of standards many different interfaces that fall under that umbrella, wired, optical, wireless electrical, wireless optical, etc, etc...And yes many of us started off with internet over a modem using an RS-232C connector. later pcie based with no rs-232 but still serial. (look at ppp) \$\endgroup\$
    – old_timer
    Apr 5, 2021 at 20:54
  • 1
    \$\begingroup\$ Note that RS-232C is not a protocol standard (use a less incorrect term like uart instead) it is a pin/connector and voltage level standard, the timing of the "bits" you send across it are not defined (there nor anywhere, they pre-date the notion of writing down standards). \$\endgroup\$
    – old_timer
    Apr 5, 2021 at 20:55

7 Answers 7

12
\$\begingroup\$

Ethernet has no separate wire for clock signal, so does it make it asynchronous?

Not having a separate wire means nothing.

Some ethernet data uses Manchester encoding and some use data scrambling. Both allow the receiver to lock-in to the data and are therefore regarded as synchronous. Note that you don't need to transmit clock separately to data to have a synchronous data link; if the clock can be merged with the data and successfully recovered as an entity in its own right then that makes it a synchronous transmission.

I am certainly not speaking for all variants of ethernet; just the ones I have some knowledge of i.e. 10 Mbits/sec (Manchester encoding) and 100 Mbis/sec (Scrambling).

Maybe read A Beginner’s Guide to Ethernet 802.3 written by Analog Devices.

can we use RS-232 to carry or transport Ethernet?

Then it wouldn't be ethernet. You can use RS232 to carry a payload of data at a fairly modest speed over a short distance so, if you can live with that limitation (why would you?) then you can repackage an ethernet frame and send it via RS232.

\$\endgroup\$
20
\$\begingroup\$

I think you're getting multiple answers, because the real answer is that you can't quite wedge what the various flavors of Ethernet are into the definitions of "synchronous serial" or "asynchronous serial". In fact, not all Ethernet flavors are entirely serial, because they involve parallel wires.

Ethernet has no separate wire for clock signal, so does it make it asynchronous?

But Ethernet also does not use start and stop bits, so does it make it synchronous?

Most Ethernet flavors have framing bits, that establish both the start of the frame and that prime the bit timing recovery circuitry of the receivers. You could, given enough beer, convince me that these are "just start and stop bits" -- but after I sobered up, I may no longer agree.

Ditto convincing me that they cannot be start and stop bits.

And by the way, can we encapsulate Ethernet into RS-232? That is, can we use RS-232 to carry or transport Ethernet?

In a sense, yes. You could design a protocol that would encapsulate Ethernet frames and send them via RS-232. Or semaphore, if you could find a patient enough pair of sailors. Or just about any other sufficiently flexible means of transmitting digital information. Delay would be an issue, so you'd probably need something that acts more like a switch than a bridge.

Since most Ethernet communications is using Internet Protocol, your best bet is to not try to wrap Ethernet in serial, but rather to use PPP, which is well-established, solid, and just works.

\$\endgroup\$
8
  • 12
    \$\begingroup\$ Reminds me of IP over Avian Carriers. \$\endgroup\$
    – Vilx-
    Apr 6, 2021 at 6:47
  • 2
    \$\begingroup\$ +1 for linking to beer. talented engineer. \$\endgroup\$
    – danmcb
    Apr 6, 2021 at 6:55
  • \$\begingroup\$ Oh bugger, now I'm almost tempted to implement an Ethernet over serial tunnel. Or maybe I should just search deeper, someone must have done it already... \$\endgroup\$
    – ilkkachu
    Apr 6, 2021 at 13:03
  • \$\begingroup\$ Ah, socat can do it. \$\endgroup\$
    – ilkkachu
    Apr 6, 2021 at 13:11
  • 1
    \$\begingroup\$ You could also argue the reverse: the UART start bit is a preamble that establishes timing for the current frame. \$\endgroup\$ Apr 7, 2021 at 9:59
6
\$\begingroup\$

It really depends on which particular Ethernet interface is in question, there is no "the" Ethernet interface so there can be no single answer.

For example, Ethernet between a MCU and PHY typically uses the MII bus, which is synchronous interface. It even has two clocks, one for transmitting data, and one recovered for receiving data. The RMII combines the clocks into one which means the PHY has to have a data FIFO to tolerate clock differences between devices.

And it is true that for example 10 Mbps and 100 Mbps sent over copper wires have no separate clock. But the data is sent with a coding to allow the reciver to recover a clock. 10Mbps Ethernet uses Manchester coding where there is always a transition in the middle of a bit. As the bus is idle the data preamble gives the receiver time to lock on to the clock for every packet. 100Mbps Ethernet uses 4b5b coding of data to provide clock transitions, and an IDLE symbol is being transmitted continuously so the receiver never loses synchronization while the link is up.

So, does it have a clock line? Yes at the PHY MII level, no at the medium, as it is embedded in the data. Is this synchronous or asynchronous? It depends on the definition. The clock must and will be recovered at the receiving end to receive the data symbols correctly.

Regarding if Ethernet traffic can be sent over RS-232, you have to first understand that RS-232 is a standard for only an electrical interface, it does not take any part which data is sent and how to send it. I have to assume you mean the typical usage of RS-232 serial ports which use an UART to transfer data. Yes, SLIP protocol was used already over 30 years ago to transfer IP packets over a serial interface instead of Ethernet interface. So yes, you can basically send Ethernet data over RS-232 if you want.

\$\endgroup\$
3
\$\begingroup\$

Ethernet, in its various forms, embeds clock timing in the stream (such as the Manchester encoding used for original 10Mbit Ethernet), or provides a means to identify and recreate the clock to properly decode symbols using special markers.

Either way, the timing for this embedded clock comes from the transmitting source, and the receiver is obliged to recreate it locally. It does so as long as it can see a signal from the transmit link partner, for the duration of a packet. The receiver compensates for any mismatch (drift) between the two clock sources as it recreates its local clock.

UART receivers also recreate a local clock using two things: a shared understanding of the baud with the transmitter, and alignment of its sampling clock using the start bit. But unlike Ethernet, the UART recovered clock is only effective for one frame time (typically 10 bit times including start and stop for 8N1 serial.) It’s not continuous. Successive UART frames have no known phase or delay to each other.

This is a long-winded way of saying that UART is asynchronous, while Ethernet is semi-asynchronous, or more precisely, plesiosynchronous at the packet level. That fancy term that sounds like a the name of a dinosaur just means that the link partners use a similar clock frequency, but the clocks at each end are not locked to each other.

Ethernet packet-to-packet timing isn’t defined by a clock however, so in a broader sense Ethernet is asynchronous.

The Ethernet receiver has to compensate for any drift between the transmitter and its local clock. As it is, Ethernet is packet-oriented, with data flow is managed in higher levels of the protocol stack to avoid over- or under-run conditions.

As far as how data get sent, that's a higher-level question.

You can encapsulate serial UART (byte-oriented) streams over Ethernet, as an application-to-application connection. A common way to do this is by a software mechanism called sockets. A socket is basically a serial data tunnel through an IP network, and looks like a physical serial port to the application.

You can also send IP streams over a UART, using protocol like PPP or SLIP. This method is how a serial modem provides an internet connection. PPP still persists within cellphones for example, as the protocol used to connect the phone’s application processor to the baseband radio, and it shows up with other modems as well.

So you can wrap serial in IP and send it over Ethernet, or you can wrap IP in serial and send it to a network. Confusing? You bet. Lucky for us, there’s a roadmap that explains this, called the OSI layered network model. More here: https://www.google.com/amp/s/www.networkworld.com/article/3239677/the-osi-model-explained-and-how-to-easily-remember-its-7-layers.amp.html

As you look OSI, consider the interfaces and how they’re used and use the OSI model to help determine the ‘who encapsulates who’ untangling. OSI also is helpful in understanding how to make application frameworks that are network-independent.

”smells like seven layers, that beaver eatin’ Taco Bell” - Les Claypool

\$\endgroup\$
2
\$\begingroup\$

Ethernet wave forms bring both data bits and synchronization bits.

Clock bits are encoded in the waveform and are recovered in realtime by the receiver.

The receiver uses the recovered clock bits to synchronize the recovery of the data bits.

Ethernet is a synchronous interface because the stream contains both data and clock information.

\$\endgroup\$
7
  • 3
    \$\begingroup\$ In that case, is UART also a synchronous interface, because there are both synchronization bits and data bits? \$\endgroup\$
    – Justme
    Apr 5, 2021 at 20:52
  • \$\begingroup\$ UART is not synchronous because the receiver has its own oscillator. There's no clock recovery. \$\endgroup\$ Apr 6, 2021 at 8:02
  • 3
    \$\begingroup\$ Technically, the method of oversampling, which every UART typically uses, is a method of clock recovery. It's just very crude and simple one. It allows the receiver to receive a continuous byte stream of data even if transmitter sends it about 2% too fast or too slow. So as you see, both UART and Ethernet provide a stream of symbols that provide clock and data information for recovery, so where is the difference then that makes Ethernet synchronous but not UART? \$\endgroup\$
    – Justme
    Apr 6, 2021 at 9:48
  • \$\begingroup\$ @Kubahasn'tforgottenMonica: If one were to use a UART protocol to send information with one start bit, one data bit, and one stop bit [a technique used by many things like infra-red or simple RF remote controls], would that be "synchronous" or "asynchronous" by your definition? \$\endgroup\$
    – supercat
    Apr 6, 2021 at 22:56
  • 1
    \$\begingroup\$ @supercat It will be synchronous if: 1. All transmitter edges are synchronized to the baudrate clock, and not some multiple as is the case with typical UARTS. 2. The transmitter transmits symbols often enough for the receiver not to lose lock. 3. The receiver uses a clock recovery technique to synchronize its baud clock to the transmitter. Even a 1-8-1 serial transmission can be synchronous as long as the transmitter never reverts to idle level but transmits idle symbols, and it uses x1 clock (not x4, x8, x16, etc). \$\endgroup\$ Jun 10, 2022 at 20:02
1
\$\begingroup\$

Asynchronous for sure. Commonly for a bus synchronous means there is a separate clock signal used by the receiver to sample the data.

Ethernet: no separate clock, and clock signal is recovered from the encoded wave pattern.

RS232: no separate clock, and the sampling clock is generated from native clock at the receiver. So you need to tell the receiver the clock speed of the transmitter or the receiver can't receive the data correctly. This works since UART is received word by word, at the begining of each word, the clock is aligned with the transmitter and the clock won't shift too much during a single word.

Ethernet doesn't have start bit, but it will have start pattern.

\$\endgroup\$
0
0
\$\begingroup\$

Asynchronous usually means that the data stream is not coded in a way that facilitates clock recovery. The transmitter and receiver clocks are not synchronized - they free-run, and the encoding is such that the receiver resynchronizes itself at some "start of frame" marker, but never adapts the clock frequency. That's RS-232 (among others).

On the other hand, all Ethernet copper and fiber is coded to facilitate clock recovery and thus the receiver clock aligns to the transmitter clock. Ethernet is definitely synchronous, even though no separate clock lines are needed: the data is self-clocking synchronous.

UARTs, as usually implemented, are not synchronous because the frequencies of the clocks are independent. Only a time reference is shared via the start bit, but the rising/falling edges are not used to adjust the frequency of the receiver. The oversampling used by UARTs is not clock recovery - it's clock phase realignment at the start bit. The frequency never changes.

With Ethernet, the receiver clock gets continuously phase-locked onto the recovered transmitter clock, forcing the frequencies to be equal as well.

It is in possible to turn the "asynchronous" serial connection into a synchronous one. It requires special hardware though:

  1. The transmitter must synchronize transmit edges to the x1 baud clock. Normal UARTs begin the start bit at the "next available" edge of a x16 baud clock, i.e. they issue the start bit as soon as possible, and not at the next x1 bit slot as referenced to previously transmitted symbol.

  2. The transmitter must not revert to the idle state, and should be transmitting idle symbols instead.

  3. The receiver must have a PLL with a narrow capture range - say +/-10% of the baudrate. The loop filter needs a time constant of several tens of bit periods, so that the clock phase can carry across the missing edges between the start bit and the stop bit.

When that's done, the receiver operates on a x1 clock, and a simple shift register can be used to deserialize the data, using the start bit as a trigger to copy the data to the output register, and reset the shift register to the idle state (all 1s).

I have seen UARTs implemented that way in some old homebrew computers. Perhaps the designer just used what they had on hand, without having to wait for a UART to arrive.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.