0
\$\begingroup\$

I was wondering how this would scale. If you have one ethernet port on a device and it can handle 1 Gb/s - let's say - it can handle 1 Gb of data each second, right?

But if you add more ethernet ports, does the amount of data the device can receive increase linearly?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ Minor correction, the data rate is 1Gb/s but with all the protocol and encoding overheads the throughput is much less, so it can't handle 1 Gb of data each second. Whether it scales linearly depends on the 'device'. \$\endgroup\$ – Tom Carpenter Oct 23 '15 at 20:15
  • \$\begingroup\$ 1 Gbps Ethernet is specified as 1 Gbps before encoding. So for serial gigabit Ethernet (i.e. over fiber) the raw serial rate is actually 1.25 Gbps due to the 8b/10b line code. However, there will be protocol overheads that depend on specifically how the data is packetized for transmission. \$\endgroup\$ – alex.forencich Oct 24 '15 at 8:52
3
\$\begingroup\$

Yes, assuming the following two details are true:

  1. The device can utilize both ports at the same time, and the software can handle multiple connections at once. This is often not true, but for embedded systems you can do this if you design for it.
  2. The switching network can handle it, i.e. if you have a 1Gb/s connection going to your ISP or device of concern and a router, running 2Gb/s worth of bandwidth from your computer to the router will do nothing.

For example, I work for a medical device company and we have a large embedded system running 4 10Gb/s Copper Ethernet. Now a semi custom UDP protocol and Jumbo Frames is used so it is not to crazy to manage. To take advantage of this though we leverage some Altera FPGAs to handle the data on a hardware / firmware level long before any real software touches it and the OS/Software level sees it as a single Ethernet connection so programs can take advantage.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thanks. My suspicions are confirmed, but you never know with these situations sometimes. :) \$\endgroup\$ – dylnmc Oct 23 '15 at 20:31
  • \$\begingroup\$ @Hans has a good example of why this commonly does not work with the USB3 example. \$\endgroup\$ – MadHatter Oct 23 '15 at 20:32
  • \$\begingroup\$ +1. The issue is more software than hardware related - it's relatively easy to design hardware for XAUI or simmilar, what's also required is to spec the software to handle the required datarate too (or drop the rate to one it can handle). \$\endgroup\$ – stanri Oct 24 '15 at 15:28
3
\$\begingroup\$

In theory yes. In practice, not always as easily.

1Gbit/s is essentially the bit-rate standard on the wire. The ethernet ports may be connected to a back-end bus that has limited bandwidth, especially if you're combining multiple.

Example: there are many dual USB3.0 to PCI-e 1x computer addon cards. USB3.0 can go up to 5Gbit throughput, but PCI-e 2.0 1x (common at the time of USB3.0 going mainstream) only goes up to 4Gbit/s data bandwidth. So although it adds 2x USB3.0 ports, it can not even (or barely as @alex.forenich pointed out) saturate a single port.

Additionally ethernet uses rather small packets to transfer data. At 1500 bytes max. payload, you can have up to 81000 packets/second at 1Gbit/s traffic. If each packet is handled individually via interrupts, that can build up to a lot of CPU time. This could be improved by using jumbo frames.

The protocol used may not scale with multiple connections. E.g. some (high-end) switches may support link aggregation, but only can provide the double bandwidth over multiple TCP connections.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Yes, "Don't take one interrupt per packet" would definitely be quite early on the list of things to look at if trying to get reasonable throughput... \$\endgroup\$ – user1844 Oct 23 '15 at 20:38
  • 1
    \$\begingroup\$ USB 3.0 is really 4.0 Gbps, the 5.0 Gbps figure is a marketing figure that includes the 20% 8b/10b encoding overhead. \$\endgroup\$ – alex.forencich Oct 23 '15 at 21:08
1
\$\begingroup\$

It is possible to 'bond' multiple ports together under certain circumstances. Generally, both ends of the link need to support this otherwise it won't work properly. See https://en.wikipedia.org/wiki/Link_aggregation .

Now, utilizing that bandwidth is a different story. Generally bonding would be used for things like switch uplinks - i.e. you have a 48 port 1G switch and you bond 4 ports together for a 4G uplink. If there are any bottlenecks along the path, then the usable bandwidth could be significantly limited. And these bottlenecks could be internal or external - i.e. between the CPU and the NIC, or between switches on the network.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ You don't generally get bandwidth equalling link_rate * links with aggregation due to the software (routing) overheads required to use all the links efficiently. \$\endgroup\$ – David Oct 24 '15 at 8:55
  • \$\begingroup\$ I would say it depends on how they are bonded and how fast the links are to begin with. There should be no issue with bonding gigabit links these days, even in software. 10G links are a different animal. \$\endgroup\$ – alex.forencich Oct 24 '15 at 8:59
  • \$\begingroup\$ Fair point - some interesting discussion here (relevant to 10G as you say): electronics.stackexchange.com/questions/52838/… \$\endgroup\$ – David Oct 24 '15 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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