Nem lehet, hogy a kliens a gyenge láncszem a történetben? Úgy gondolom, küldeni egyszerűbb, mint venni, és az látszik, hogy amikor a kliens küld, akkor azt az ATOM CPU fel tudja dolgozni, viszont amikor az ATOM CPU küld, akkor a kliens nem tudja ezt megfelelő sebességgel "elkapkodni".
Nem. A kliens jóval combosabb minden paraméterében: i3-7100 (4 core), 16G RAM, M2 SSD... Ill. az Atom gép switch-ének egy másik portjára tettem egy laptopot (i5, 8G RAM), és ott a mostani kliens, ill. a laptop között simán megvolt a 970Mbps, mindkét irányban. A laptopról az Atom felé ua, mint a mostani kliens felé: Atom -> laptop 970Mbps (tehát a laptop a kliens), laptop -> Atom 360Mbps (Atom a kliens).
Az jutott még eszembe, hogy megpróbálhatod a küldést meghatározott sebességgel, mondjuk 200 Mbps-mal, majd ezt emeled addig, amíg a másik oldal már nem tudja azt fogadni. Alapértelmezésben TCP-vel megy a teszt, ha átkapcsolsz UDP-re, akkor egyszerűbb a dolga mindkét oldalnak, mert nem kell foglalkozni a nyugtázással.
Az UDP önmagában elég katasztrofális eredményeket hozott (1Mbps körül volt mindkét irányban), most megnéztem az általad írt bandwiith kapcsolóval, így udp-n 650Mbps-t mért (1G-t adtam meg):
# iperf3 -R -c 172.20.10.254 -u -b 1G
Connecting to host 172.20.10.254, port 5201
Reverse mode, remote host 172.20.10.254 is sending
[ 4] local 172.20.10.2 port 53057 connected to 172.20.10.254 port 5201
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-1.00 sec 69.8 MBytes 585 Mbits/sec 0.136 ms 0/8932 (0%)
...
[ 4] 9.00-10.00 sec 78.0 MBytes 655 Mbits/sec 0.062 ms 0/9990 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 766 MBytes 642 Mbits/sec 0.070 ms 24/98020 (0.024%)
[ 4] Sent 98020 datagrams
iperf Done.
root@basil:~# iperf3 -c 172.20.10.254 -u -b 1G
Connecting to host 172.20.10.254, port 5201
[ 4] local 172.20.10.2 port 41006 connected to 172.20.10.254 port 5201
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 102 MBytes 854 Mbits/sec 13038
...
[ 4] 9.00-10.00 sec 113 MBytes 948 Mbits/sec 14466
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.09 GBytes 938 Mbits/sec 0.087 ms 95757/143139 (67%)
[ 4] Sent 143139 datagrams
TCP-n nem megy 360-370M fölé.
Még egy furcsaságot láttam az Atomos gépen:
# mii-tool eth0
eth0: negotiated 1000baseT-HD flow-control, link ok
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Link detected: yes
Tehát az mii-tool szerint half duplexben van, az ethtool szerint FD-ben :). A kernel szerint is FD:
# cat /sys/class/net/eth0/duplex
full
Szóval így elfogadom az FD-t, viszont egyelőre nincs tippem, mi lehet a szűk keresztmetszet.