So, both devices are struggling with that. However I do see that too on my transfers (870Mbps), and as we are strying to reach max speed here, this is to be expected (especially if one device is not as fast as the other one).
One thing that can help, is to adapt the buffer sizes on the network cards. My NAS has it set to maximums. Note that this can also backfire if the CPU/System cannot free up the buffers. It however helps lower the interrupt requests.
Note2: This wonât work on the Vero, the driver has no such capability.
The one thing I do not see on decent/clean setups, are the below error messages. means there is another switch in the network, and thereare some issue with these.
Note, in very simple terms, the spanning-tree protocol is usually inter-switch communication, elections etc. to determin who is master, and exchange informations etc.
So - I rather suspect there are issues on the traffic transfers at high speed where one side is not able to reception the data fast enough. This effect however can be induced by a switch (layer 2, it is transparent to both TCP/IP session communication parties), or by the layer 2 of the network card drivers.
We see these from time to time. Broadcom chips have made issues in the past, reason that for high-speed network interfaces we tend to only use Intel Chipsets based network cards, and no Dual or Quadruple cards.
I am using a NETGEAR GS208-100UKS 8 Port Gigabit Switch to which my Vero 4k+ and Generic HTPC (file server) are directly connected and I get good speeds:
Yes. No difference.
To summarize my findings:
The problem only occurs, if the Vero is connected with the internal eth0 port to my TP-Link JetStream switch or an old DLink unmanaged Gigabit switch.
It does not occur, if I use USB ethernet adapter on the Vero or
if I insert something else (Mikrotik router) between Vero eth0 and the TP-Link.
I have a bunch of TP-Links lying around. I can test them, if you want me to.
They are usually nice, cheap and well working.
Only problem is, that TP-Link changes the hardware revision like other people change their underwear.
If you get reports from people having problems with TP-Link switches, you should ask them for the hardware revision. Some switches of the same type have 5 or 6 versions, each with different hardware.
Yes, I have one. I have powered down the Vero in the meantime, do I have to install the debug kernel again, or is it persistant? Is a âgoodâ log enough? (I already posted the bad one).
These range from cheap and cheerful unmanaged to expensive managed enterprise switches.
This issue is proving to be challenging to solve due to neither Sam or myself being able to reproduce it yet⌠Hopefully Sam will have his hands on an affected switch shortly.
This is getting a little bit frustrating to keep reading this if iâm honest.
It is not only switches that are the problem, myself and user Matt.Capes still have the same problem when we remove our switches from our networks, probably other users as well but i have lost track of the multitude of threads/users with similar issues (and did these other users even test network performance without a switch anyway ?)
I have replied to Sam on at least 2 occasions on 2 threads to point this out, but he hasnât acknowledged this.
Also why has Sam not got one of the affected Veroâs back in to actually test the unit ?
Surely that would have been one of the first things to happen wouldnât it not ?
All I keep reading for several days now is that he will have one of the affected switches in âshortlyâ to to test⌠It cant be that hard to buy a ÂŁ20 switch off ebay/amazon and get it delivered next day can it?
Almost pristine.