Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ethernet History Deepdive – Why Do We Have Different Frame Types?

lostintransit.se

Post reply on HN
Print view View original

31–40 of 86 posts

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#31

Post by akira2501 »

kstrauser wrote: post #28
leoc wrote: post #9

Earlier quoted context omitted.

(Intentional) jumbo frames at layer 2 and expanded MTUs at layer 3 are certainly available (as you may know). In fact it seems (I am, it should be obvious, not an expert) that using jumbo frames is more or less the common practice by now. There does in fact seem to have been some standards drama about this, too: I can't find it now, but IIRC in the '00s someone's proposal to extend the header protocols to allow the h…

The common advice I've heard for jumbo frames is not to enable them unless you can do it for every devices on your LAN, and even then it's probably not worthwhile outside specific situations like a separate iSCSI network or such. I just now ran iperf3 from my Mac to my Synology without jumbo frames: [ ID] Interval Transfer Bitrate Retr [ 7] 0.00-10.00 sec 10.0 GBytes 8.61 Gbits/sec 0 sender [ 7] 0.00-10.00 sec 10.0 G…

It seems much more effective on plain 1000Base. It's the difference between 850Mb/s and 975Mb/s for me.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#32

Post by kstrauser »

akira2501 wrote: post #31
kstrauser wrote: post #28

Earlier quoted context omitted.

The common advice I've heard for jumbo frames is not to enable them unless you can do it for every devices on your LAN, and even then it's probably not worthwhile outside specific situations like a separate iSCSI network or such. I just now ran iperf3 from my Mac to my Synology without jumbo frames: [ ID] Interval Transfer Bitrate Retr [ 7] 0.00-10.00 sec 10.0 GBytes 8.61 Gbits/sec 0 sender [ 7] 0.00-10.00 sec 10.0 G…

It seems much more effective on plain 1000Base. It's the difference between 850Mb/s and 975Mb/s for me.

That surprises me a little. From the Wikipedia article[0] I'd expected jumbo frames to be only about 5% more efficient.

[0] https://en.wikipedia.org/wiki/Jumbo_frame

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#33

Post by p_l »

Hikikomori wrote: post #24
betaby wrote: post #3

Earlier quoted context omitted.

OSI is very widely used, most of the large ISPs use it. End consumers are just unaware of that fact. See https://en.wikipedia.org/wiki/IS-IS

Would call it stretch to say it was widely used by ISPs. Some old ones may still be using integrated IS-IS as their IGP (early OSPF had scaling issues and complicated solutions for that), but that's nothing like widely using the ISO stack. But they might have used IS-IS it to route NSAP in their network at some point in time to manage ATM-era equipment, the ISP I worked still had some ctunnels for that purpose, I dou…

It was still widely used for IPv4 and v6 in 2000s. ex telco engineer told us that two major reasons was that IS-IS was simply more efficient, and that they didn't require IP communication between routers - meaning troubleshooting and management was easier than providing p2p routes for IP-based protocols.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#34

Post by [deleted] »

dale_glass wrote: post #4

I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.

[deleted]

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#35

Post by dale_glass »

toast0 wrote: post #11
dale_glass wrote: post #4

I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.

I mean, larger packets (and working path MTU detection) could be useful, but with large (1500) byte packets and reasonable hardware, I never had trouble pushing 10G from the network side. Add TLS and some other processing, and older hardware wouldn't keep up, but not because of packetization. Small packets is also a different story. All my hardware at the time was xeon 2690, v1-4. Nics were Intel x520/x540 or similar…

I discovered that putting a 10G interface into a bridge implies a very significant slowdown. Linux has to do stuff on the CPU to do the bridging, so that turns off a large part of the card's acceleration.

That's not a good thing for a server that runs a bunch of VMs.

Fortunately SR-IOV exists, but it seems a tad silly to me that I have to do all this weird PCIe passthrough stuff just for this. It's nice, don't get me wrong, but a bit too exotic for what should be a simple setup.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#36

Post by londons_explore »

I wish layer 2 and layer 3 were 'refactored' to force all links to be point to point, which they effectively are in the modern world. When was the last time you saw ethernet frame collisions because you used a hub not a switch?

We'd get rid of the idea of a broadcast domain. We'd get rid of Mac address and ARP. Switches and routers would become the same device. We'd just use ip addresses for routing, and the 'next hop' would always be the opposite end of the link you sent a packet over.

The world would be a simpler place, and no functionality would have been lost.

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#37

Post by imoverclocked »

immibis wrote: post #14
dale_glass wrote: post #4

I wish we could have another and bump the packet size. We're at the point where we can have millions of packets per second going through a network interface, and it starts to get very silly. It's at the point where even a 10G connection requires some thought to actually perform properly. I've managed to get bottlenecked on high end hardware requiring a whole detour into SR-IOV just to get back to decent speeds.

Maximum packet size is already configurable on most NICs. 9000 is a typical non-default limit. If you increase the limit, you must do so on all devices on the network. https://en.wikipedia.org/wiki/Jumbo_frame

I’ve seen Cisco gear that supports 8192… that was fun to figure out with a separate network team :) “yup, we’ve enabled jumbo frames!”

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#38

Post by jhayward »

akira2501 wrote: post #30
mannyv wrote: post #25

One thing that isn't mentioned is that the physical layer at the time was 'flat' ie: a network had a shared wire. That means bus arbitration (to prevent collisions) was a big deal. Token ring solved that by passing tokens, which presumably guarantees latency. I believe Ethernet just raised a line high, and it was up to everyone to respect that. Of course that changed when switches came out. I have a 10/100 hub in a c…

> I believe Ethernet just raised a line high, and it was up to everyone to respect that. It's actually much simpler than that. When you transmit you also listen. If what you hear is not what you sent, there is a collision, and you backoff.

To be specific, it's even more basic than that. For 10Base-5 and all the coax ethernets, it was "if there's more energy on the wire than you are transmitting, a collision is present".

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#39

Post by mportela »

HappMacDonald wrote: post #26
amelius wrote: post #19

Earlier quoted context omitted.

Maybe we can then also redefine pi as 2*pi, while we're at it.

Or just use tau and call it "tau"

What a throwback! I remember when the Tau Manifesto came out: https://tauday.com/tau-manifesto

Re: Ethernet History Deepdive – Why Do We Have Different Frame Types?

#40

Post by toast0 »

dale_glass wrote: post #35
toast0 wrote: post #11

Earlier quoted context omitted.

I mean, larger packets (and working path MTU detection) could be useful, but with large (1500) byte packets and reasonable hardware, I never had trouble pushing 10G from the network side. Add TLS and some other processing, and older hardware wouldn't keep up, but not because of packetization. Small packets is also a different story. All my hardware at the time was xeon 2690, v1-4. Nics were Intel x520/x540 or similar…

I discovered that putting a 10G interface into a bridge implies a very significant slowdown. Linux has to do stuff on the CPU to do the bridging, so that turns off a large part of the card's acceleration. That's not a good thing for a server that runs a bunch of VMs. Fortunately SR-IOV exists, but it seems a tad silly to me that I have to do all this weird PCIe passthrough stuff just for this. It's nice, don't get me…

Oh yeah, bridged mode on my little pentium system brings perf way down. It was fine on 1G, but when I upgraded to 10G and wanted to hit numbers, I needed to stop doing software bridging. For me, I have slots and NICs, so I moved away from virtual ethernet on a bridge to actual ports; main host gets the 10G, and everything else gets to use 1G ports.

No SR-IOV on my board, but that's ok.

Post reply on HN