Issue with File Transfer Speeds using an ATP800

PeterUK

Unfortunately LAG does not work like that by design I'm not sure someone said no but I think the reason has to do with packets arriving out of order which I don't see why that should be a problem but they think it is.

Their are many LAG hash types IP/MAC by source and destination and some do by ports (TCP/UDP) but in short lets say the hash LAG is by IP source and destination between two switches in a two port LAG and a computers on either side if the switches.

Ports 27 and 28 of each switch are in the LAG

Switch 1
PC A 192.168.0.2
PC B 192.168.0.3
PC C 192.168.0.4
PC D 192.168.0.5

Switch 2
PC E 192.168.0.6
PC F 192.168.0.7
PC G 192.168.0.8
PC H 192.168.0.9

a TCP session from PC A to E will use port 27 of the LAG if PC B and PC F start a session port 28 of the LAG will be used Using the Full LAG

But a TCP session from PC A to E will use port 27 of the LAG if PC C and PC G start a session port 27 of the LAG will be used due to the hash of the LAG sending packets out a given port meaning the LAG can only be fully used between odd and even IP source and destination to try and even out the traffic by the LAG and as you can see not a good system.

NEP

I don't know enough about LAG but what you are saying sounds plausible/correct. And I think I followed what you said at the bottom about them being on the same port if they are the same IP. However, it would stand to reason that if all of the even IPs are on one port and all odds on another, it has to be better than all of them being on one. I'd also think that this would improve even more with more ports. Maybe not. What it did remind me of is the quote…

"You can please some of the people all of the time and you can please all of the people some of the time, but you can't please all of the people all of the time."

By the way, thank you for all the replies. The insight is appreciated. My coworker and I have noticed you in other threads that we've posted and have debated about what you do given getting responses in the middle of the day :-) Though I suppose if UK is an indicator it would be late afternoon to evening. Anyway, thanks again.

Zyxel_Melen

Hi @NEP

Sorry for the wait. About the question "Is the ATP800 capable of this higher throughput?" The answer is yes. We did a local lab for cross subnet Windows file transfer, a.k.a. SMB, and get the result is around 800 ~ 900 Mbps. Here are the details of our lab.

Model :ATP800

Version : V5.40

Test topology:

PCA-------------ge3------ATP800----ge4---------PCB

PCA: CPU 12th Gen Intel(R) Core(TM) i5-1240P

PCB: CPU 13th Gen Intel(R) Core(TM) i7-13700H

Configuration: System default / IPS on / Anti-Malware on

Result video: 777289744.762213.mp4

Since there has may reason that cause the low file transmit speed, we need your help to provide two remote PC to trace this issue (AnyDesk or TeamViewer) and find what cause it.

About the bug which affects the "Tx/Rx Statistics" where the graph shows a different value than the selected port, could you help to use the jam.dev browser extendsion to record it and share with us?

NEP

We had run the exact same test as you just did and got the same results on the bench. The only problem with that is that there is literally no load on the ATP. It's just two devices. Per one of our prior comments, we loaded on our Production config and the speeds dropped significantly, even though only two devices were connected. I sent the obfuscated config via Direct Message on 8/8. Did you happen to try loading that config onto your test ATP? What were the results?

As for providing two remote PCs to trace the issue. What are you hoping to accomplish? You didn't ask for access to the ATP interface, so I assume you just want to see that the speeds we reported are actually accurate. I don't know what else you could tell.

For the Rx/Tx bug, I'd rather not install the Jam extension just to get that info. I performed the following on an ATP200 and it has the issue as well. To reproduce I believe this requires two connections. We have WAN (P2) and LAN (P4). Open the dashboard, take note of what the WAN graph looks like, change the port selection view to LAN, take note of what the LAN graph looks like, switch to some other window to do work, and then wait for the graph to refresh (appears to be 1 hr). After the "wait" period ends, the port selection will still be the LAN, but the graph will be for WAN.

Zyxel_Melen

Hi @NEP

No, we test with the default configuration, which is used to verify the device's capability. The remote access for PC is not just test it again; we will also investigate the firewall's details during the testing. I forgot to mention we also need access to the firewall in the previous comment.

Additionally, thanks for the detailed information about the Rx/Tx bug. We will investigate this issue.