0

Background (Why I want to do this)

My computer is connected to a flow control switch.The switch will limit the speed of each accessed IP to 10mbps.So I want to access multiple IPs and merge them to improve the network speed

What I have done so far

I refer to these articles:

  1. Windows-Creating Virtual Interface Over a Single Physical Interface
  2. Force an application to use a specific network interface
  3. https://www.altaro.com/hyper-v/hyper-v-network-teaming-understanding-link-speed/
  4. https://learn.microsoft.com/en-us/powershell/module/netswitchteam/new-netswitchteam?view=windowsserver2022-ps
  5. http://woshub.com/configure-nic-teaming-windows/

Now I have access to multiple IPs, and can reach the peak network speed of each network card through the curl command

all vEthernet can work

But I can't combine their network speeds to one network card through NIC Teaming

I try run New-NetSwitchTeam -Name "SwitchTeam01" -TeamMembers "vEthernet (net1)","vEthernet (net2)","vEthernet (net3)","vEthernet (net4)"

But I got a 10mbps vEthernet

SwitchTeam01 10mbps

What I need help with

  1. How to aggregate these virtual network cards and improve the speed?
  2. Is there any easier way to achieve what I am trying to do?
Curtis James
  • 11
  • 2
  • Same question : Are you trying to aggregate NICs for combined bandwidth? If so, it doesn't work like this. – harrymc Oct 24 '22 at 14:18
  • I just want to aggregate virtual ethernet to get combined bandwidth – Curtis James Oct 25 '22 at 15:24
  • You can't combine bandwidth. Aggregation is a failover feature, not performance. I can detail more in an answer, but it will be negative. – harrymc Oct 25 '22 at 15:27
  • I understand Thank you – Curtis James Oct 26 '22 at 12:27
  • You actually already did create a faster network connexion; what you attempted worked, it was your *test* that failed. You wont make any individual packet travel faster, but you'll be able to send as many packets on this virtual network as the total that could be put through the physical, so long as they're not sequential (a real device wouldn't have this limitation). Id est you increased your bandwidth. Try the test again, but run two `curl`s *at the same time*, I think you'll find a huge decrease in the time it takes for them to complete vs using either network without aggregation. – Hashbrown Jun 19 '23 at 16:19

1 Answers1

0

Network adapter Teaming does not aggregate bandwidth. Adapter teams are not created for bandwidth aggregation, but rather for load-balancing and fail-over.

This is because a network connection can only have one route connecting one network physical connection on each side of the connection.

You may create a team on four gigabit adapters, see that link speed report of 4 gigabits, and believe that you've created a 4 gigabit pipe. But in fact you have made a link aggregation of four gigabit adapters that act as one logical unit.

For more explanations, see this article.

When multiple physical paths are available, some technologies can make use of that to increase transmission speed. However, not adapter teaming. Some technologies, such as MPIO and SMB multichannel, work better when you leave adapters unteamed.

For more information, see the article Hyper-V and Network Teaming: Understanding the Link Speed.

harrymc
  • 455,459
  • 31
  • 526
  • 924
  • Wouldn't using it for load-balancing make it faster? That article gets hung up on making a single stream faster, but it fails to realise most use-cases are made up of many connexions; each of these individual streams can use a different member of the team *simultaneously* to achieve higher throughput. Even just a basic round-robin of the team members when transparently feeding tcp requests to the fake device would result in a multiple of elapsed speed as a whole so long your bottle-neck was your local NICs, and not the network they're connected to. – Hashbrown Jun 19 '23 at 16:01
  • @Hashbrown: The point is that 4 x 1Gbits is not equal to 4Gbits, except in aggregate bandwidth. But no one connection can achieve 4Gbits. – harrymc Jun 19 '23 at 18:31
  • No, the point is that in most usecases aggregate bandwidth **is** all you care about. Pulling a file via udp at four points simultaneously *will* get you the file literally four times faster (in the ideal case, I think MS teaming is really only capable of 1.4x per doubling of team size). This means your effective data rate IS 4gbit. No one stream would achieve this, no, but usecases relying on single streams for an entire computer's connexion is relegated mostly to VPNs. – Hashbrown Jun 27 '23 at 05:02
  • @Hashbrown: One connection cannot use multiple adapters, and even if it could, the data arrives from the source in a single stream so there's no gain. Only very specific programs will use multiple connections for one download/upload, such as torrent clients and multi-threaded download managers. For most programs the situation is 4x1GB=1GB. – harrymc Jun 27 '23 at 08:17
  • Or web browsers? Or watching netflix and downloading stuff from steam at the same time? Heaps of *use cases* other than "I'm using *only one application*" exist that would take full advantage of a system with a multi-nic team. To imply it's not useful simply because there's a **tiny** usecase of "I want this one stream in this one application that is all I care about on my whole machine to go obscenely fast" is absurd especially given it wasn't so much as even hinted in the question! – Hashbrown Jun 27 '23 at 14:00
  • His issue is that individual nics are being arbitrarily limited, and he wants to be able to see a more full utilisation. This being a single connexion was an assumption you just ran with, an incredibly unlikely one, is all I'm trying to point out here. Having multiple nics in a team will absolutely increase his *throughput* bypassing the limit completely, without any clarification on specific needs, and probably just needed education on *how* the speed is "faster" and why it didn't align with his test. Your answer focused entirely on "teaming cant do that", which is wrong. – Hashbrown Jun 27 '23 at 14:04