Hi,
like Vince mentioned before, it is important to understand the principle of the loadbalancing.
Loadbalancing over L2 interfaces will typically not be packet based, but hash based.
The reason it is not normally not packet based is that there could be minor latency differences on the 2 links, so packets of 1 link could arrive a bit sooner/later than the packets of the other link.
When all these packets are for the same TCP session, it means that the packets would arrive out of order, and you would experience a lot of TCP retransmits, causing worse performance.
So with the has-based system you do not have this problem.
The hash is calculated per packet and the algoritm will use several fields from the actual packet for the calculation.
The original concept was to use the source + dest mac address of the packet. As a result, every packet with the same source and dest mac would result in the same hash result (e.g. 0 or 1). This hash result is used to assign the packet to a physical interface.
So assume a packet from mac A1 to mac A2 would result in a hash 0, and hash 0 would be assigned to link 1, then all future packets from A1 to A2 will actually take link1 (ensuring in order delivery). There is no adaptive loadbalancing here, so even when link1 is at 100% and link2 at 0%, the packets from A1 to A2 would still be sent over link1.
A packet from A1 to A3 would result in hash 1, and would always take link2 in this example.
Since this means that e.g. all traffic from a host to a gateway (which has the same source/dest mac), would take the same link.
To overcome this limitation, the algoritm has been updated, and can use other fields from the packet. So all current switches will take the source/dest IP from the packet for the calculation. Again, this means that all packet from/to the same hosts would take the same link.
More recent switches (not the 2910 AFAIK), will allow the Layer4 (TCP/UDP port) to be used as input for the algoritm. So when you have 2 different TCP sessions between 2 hosts, these 2 sessions could be sent over 2 links. Consider however that in case the dest TCP port remains the same, and the client TCP port (which will change per TCP session) for session 1 is 1024 and for session 2 is 1026 (increment by 2), then the resulting hash will be the same and both sessions will use the same link.
If the switch supports this, it is typically an option which needs to be configured on the switch.
All comware based switches support this, for the provision, you should consider 2920/3500/3800 models (2620 supports this, but it is only100Mbps).
Also consider that when performing 2 file copies, it is possible that the same TCP session is used, so you would not experience this benefit.
Last consideration is that each device in the chain will perform its own hash calculation. So when you have pc1 to switch1 to switch2 to pc2 (all connections with 2 links using link-agg), then it is possible that pc1 will transmit based on tcp to the switch (which is were you will see outbound good loadbalancing), but switch1 will calculate its own hash for the traffic to switch2 (in case of 2910 this will be based on source/dest ip), so it is possible all traffic is sent over 1 link, then switch2 will do its own calculation to pc2 (so if switch 2 would support tcp based loadbalancing, then traffic would be sent over 2 links again), and then it arrives on the pc2.
The return path is again calculated based on its own rules.
So bottomline : 2x 1G links is not 2G ! if you need more performance, the only valid solution is 10G (10GbaseT is quite cost effictive nowadays).
Hope this helps,
Best regards,Peter.