Recent content by meyergru

In the meantime, I solved that problem another way: I just exchanged my wall boxes with CAT.6 ones - and voila, speed changed to 10 Gbit/s immediately. Thus, the speed mixing problem does not occur any more.

Oh, I got the answer from Mikrotik:

As for 10/1, sure thing as >128K will be enough for that. What was your observed window size for 40/10? I suspect it to be larger than that for 10/5. Also again: you cannot cut & forward while reducing speeds - in that situation, the switch cannot get rid of the packets at their receive rate...

Exactly as expected, so the buffer is not much larger than on my switch. Changing the parameters could only limit TCP window size to below the physical buffer size - for example, if you disable window scaling, the size would be limited to 64K, which should yield an even lower throughput. I...

I am referring to the TCP window size that is effectively being negotiated on the line as can be seen in a Wireshark trace: 870495 192.168.10.97 192.168.10.3 TCP 1514 4399 → 18767 [ACK] Seq=1100727273 Ack=1 Win=131072 Len=1448 TSval=18647398 TSecr=1972253487 18767 4399...

I explained that already: Consider the case were you have a limited buffer of, say, 128K. It does not matter how big the buffer size is when you do not match speeds as each packet that is being sent can be transmitted to the receiving end. On the other hand, when you mix a 10 Gbe sender with a...

And what was your actual window size? If it was limited, that may well be the same problem. What makes you think the buffer size is not the problem? Actually, at 128K and 5 Gbe, the handshake rate is 5000/s. I don't know if Windows TCP stack can handle that, especially considering the fact that...

It is correct that my switch does not "see" the real downlink speed being only 5 GBit/s. But even if a switch has that knowledge, with a speed mix there will always be drops after the packet buffer has been exhausted. Have you tried if your TCP window size is large or if if becomes reduced...

Apart from that, I do not have Cat.5e, but Cat.5a that is more than twenty years old. Besides, the switching speed IS reached on all ports. The switch can do it at 10/10 ratio and at 5/5. What matters here is that some receivers cannot handle the to-be-expected drop of 50% at 10/5 ratio of the...

I have a centralised structured cabling with in-wall runs from the cellar to first floor at around 20 meters. Splitting that up is no option. I would have to write off my invest in the Cisco as well. But before that, I would like to confirm that the next switch does not have the same problem...

I tried flow-of-control, makes no difference. Also tried to limit bandwidth on ingress and egress to no avail. I never tried jumbo frames, but I doubt that they could fix that problem as the number of TCP "handshakes" is not reduced. I all seems to boild down to a larger buffer in the switch.

How do I know that the buffer size is small? The memory size of my switch is 1.5 MByte (it's in the specs, your switch has 2 MByte). It is a sure thing the buffer size is one limiting factor for the TCP window size, that is just how window scaling works. I can tell from the wireshark traces...

I am stuck with old Cat.5 cabling in my house and I had 10 Gbe before, but that proved unreliable. With 5 Gbe, the connection itself is fine (I once had problems with an Asus Aquantia based card, probably because of early Windows drivers), however TCP is too slow at these speeds if the switch...

What I know by now is that apparently the buffer size of the switch is too small (although it apparently has 1.5 MByte of RAM). A wireshark trace showed that the TCP window size is at 128K, which causes a pumping effect and TCP retransmissions because of the packet drops. When I disabled TCP...

The transceivers are QSFPTEK: https://www.amazon.de/gp/product/B081YKGBR4 I did not look before, but as could be expected by the fact that a Windows/Windows transfer does full speed in both directions, the switch shows no errors at all. BTW: In order to rate-limit the downlink in ingress, I...