1 |
On 1/15/21 9:00 PM, Adam Carter wrote: |
2 |
>> On a remote network I run ethtool on both cards and I got both 1000Mb/s |
3 |
>> speed |
4 |
>> |
5 |
>> |
6 |
> As the 20 odd MB/s you're getting is above what is possible on 100M |
7 |
> ethernet, you can rule out any ethernet interfaces at 100M. |
8 |
|
9 |
1.) One Gentoo PC (that is about 20-30meters away from the switch) negotiated the speed of only 100 despite being capable of doing 1000. |
10 |
I'll have to buy a new switch and make a new CAT5e cable to test it. |
11 |
But but it will take some time. |
12 |
|
13 |
> Can you describe the network between the two systems with the slow transfer? |
14 |
|
15 |
2.) The two Gentoo PC that are meters away from the switch are my concern firs. |
16 |
One is a server, another small PC run 24/7 and both negotiated speed of 1000 with the switch. |
17 |
|
18 |
I have to re-test the transfer speed between these to boxes first, and check to light on the switch if it is green and/or orange |
19 |
|
20 |
> If there is a fast WAN from one side of the globe to the other it could be |
21 |
> latency related. OpenSSH used to have a fixed internal window size that |
22 |
> made it slow on high bandwidth high latency links, and I notice the hpn USE |
23 |
> flag still exists in the openssh ebuild, which implies the issue with |
24 |
> openssh still exists. Rsync can use either ssh or its own protocol, so if |
25 |
> there's a high latency link between the two boxes and rsync is using ssh, |
26 |
> you could investigate rebuilding openssh with +hpn. |
27 |
> |
28 |
> What does ping show the latency as? |
29 |
> |
30 |
> Otherwise i'd be thinking about packet loss. First place to start for that |
31 |
> is on the endpoint interfaces; |
32 |
> ifconfig enp35s0f0 | grep err |
33 |
> RX errors 0 dropped 0 overruns 0 frame 0 |
34 |
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 |
35 |
|
36 |
I'll test the above for errors tomorrow. |