( airween | 2021. 01. 24., v – 14:25 )

A mérést az is befolyásolja, hogy mellette milyen egyéb forgalom zajlik.

Mondjuk azon a gépen nincs sok futó folyamat - a load 0.05, forgalom valamennyi van, de most épp minimális. És emellett van ez az asszimmetria - gondolom ha nagyon bekavarna más, akkor az mindkét irányban megjelenne.

Az iperf (ami tkp. iperf2) tud mindkét irányban mérni (akár egyszerre is), így nem szükséges megcserélni a szerepeket.

Közben megtaláltam én is - bár azt hittem, az iperf már a 3-as verzió, valóban csak a v2 volt. A `-r` kapcsolót is megtaláltam, használtam is, de így is aszimmetrikus az eredmény. (Megj.: a 3-asban nincs `-r`, csak `-R` - de lejjebb láttam, hogy írtad.)

Az iperf feltehetően már nem nagyon fog fejlődni, inkább iperf3 javasolt helyette (tudom, írhattam volna előbb is, de csak most lett világos, hogy annak, aki nem nagyon használja ezeket, ez nem egyértelmű).

Semmi gond, már azt tök jó, hogy van eszköz objektívebb vizsgálatra (nem ismertem korábban) :).

Ez pl. ugyan nem tud egyidejűleg mindkét irányban mérni, és nem is tervezik, hogy ezt beleteszik, viszont minden másban jobbnak mondják a fejlesztők, az iperf esetében szerzett tapasztalatok alapján írták újra ezt. Iperf3 esetében változott az alapértelmezett port (5001 helyett 5201), meg kicsit a paraméterezés és az alapértelmezett megjelenítés is. Itt is lehet mérni szerepcsere nélkül a másik irányú sebességet (-R vagy --reverse).

Ezeket is megtaláltam, köszi még egyszer. Sajnos az eredmény ua: ATOM -> kliens 360-370Mbps, kliens -> ATOM 970Mbps.

Okozhatja ezt a jelenséget az, hogy az Atomos gépen egy bridge interface van, ami összefog egy WiFI eszközt is? (A másik oldali kliensen is bridge-ben van az eth if amúgy... de ott a virtuális gépeknek van "csak".)