( airween | 2021. 01. 24., v – 18:05 )

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.