Maverick567
Established Member
I watched a Linus tech video fairly recently which covered this exact issue, from memory there experience wasn’t massively different to yours, with the link not getting anywhere near the speed expected.
I watched a Linus tech video fairly recently which covered this exact issue, from memory there experience wasn’t massively different to yours, with the link not getting anywhere near the speed expected.
Pedant alert - usually when we denote aggregated links on network diagrams, we annotate them with a "loop" symbol around the participants, like this...
View attachment 1440382
...not that this is going to solve your problem! [/PEDANT]
@mickevh just for clarity, (this is a question not a statement) Aggregated Links dont actually double (triple etc) the speed of the links combined but allow more bandwidth for individual processes using the links. So on a 2 x 1 Gb LAG a single process will only use upto 1Gb on a single channel (not 2 Gb) of the LAG and 2 processes will use 2 x 1Gb channels. Is this correct ?
I watched that too, but they were saying that about a simple Windows file transfer. None of my tests above are using that, that's the point. A multi-threaded robocopy (which is what LTT used) confirmed the speeds iPerf is reporting. Windows file copy is much slower.
@mickevh just for clarity, (this is a question not a statement) Aggregated Links dont actually double (triple etc) the speed of the links combined but allow more bandwidth for individual processes using the links. So on a 2 x 1 Gb LAG a single process will only use upto 1Gb on a single channel (not 2 Gb) of the LAG and 2 processes will use 2 x 1Gb channels. Is this correct ?
Usual causes of patch panel issues are poor termination or possibly the spring connector either being bent or dislodged. Sometimes you can get a flakey patch cable as I found out due to the plastic end causes a miscontact