Új hozzászólás Aktív témák
-
#94180096
törölt tag
Elvileg az van fenn.
Pv-vel is megnéztem az írás/olvasást:
pv /dev/zero > /mnt/testfile Itt párszáz kbyte/s és 120Mbyte/s között ugrál másolásnál. Másoláskor egyenletes sávszélességet kellene produkálnia, vagy rosszul gondolom?
pv /mnt/testfile > /dev/null Itt egyenletes sebességet produkál, igaz lassan. 6-7 Mbyte/s
Nem tudom, mi foghatja le a második esetben. Talán beállítottam valami korlátozást? Bár nem rémlik ilyesmi.
Az első esetben meg ez az ugrálás a furcsa, Vagy nagyon kicsi az érték, vagy irreálisan nagy. -
#94180096
törölt tag
Érdekes, hiába kapcsolom be a TOE-t az atomos gépen így:
ethtool -K eth0 tx on
ethtool -K eth0 rx on
ethtool -K eth0 sg on
ethtool -K eth0 tso on
ethtool -K eth0 gso onnfs nem lesz gyorsabb tőle és a CPU-t is ugyanúgy eszi.
Így csatoltam a kliensen:
sudo mount.nfs -o tcp 192.168.1.104:/távoli_könyvtár /mntAmi még érdekesebb, mostanában az írás gyorsabb mint az olvasás.
Az írás 30-50Mbyte/s.
Az olvasás 6Mbyte/s ami nagyon kevés..Biztos valami elállítódott..
-
Kipróbáltam mindkettőt. Az MTU emelésétől az NFS kliens már nem is működik, windows valami érvénytelen művelet hibát ír.
Iperfet próbáltam még, host = client, guest = server:------------------------------------------------------------
Server listening on TCP port 55555
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57559
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 8.50 MBytes 7.09 Mbits/sec
[ 5] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57578
[ 5] 0.0-10.0 sec 495 MBytes 415 Mbits/sec
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57589
[ 4] 0.0-10.9 sec 12.6 MBytes 9.71 Mbits/sec
[ 5] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57599
[ 5] 0.0-10.7 sec 4.38 MBytes 3.42 Mbits/sec
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57625
[ 4] 0.0-10.7 sec 4.88 MBytes 3.81 Mbits/sec
[ 5] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57633
[ 5] 0.0-10.0 sec 93.4 MBytes 78.3 Mbits/sec
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57642
[ 4] 0.0-10.9 sec 17.1 MBytes 13.2 Mbits/sec
[ 5] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 57652
[ 5] 0.0-10.6 sec 4.12 MBytes 3.27 Mbits/sec
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 58035
[ 4] 0.0-10.0 sec 306 MBytes 256 Mbits/sec
[ 5] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 58046
[ 5] 0.0-10.0 sec 472 MBytes 395 Mbits/sec
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 58054
[ 4] 0.0-10.0 sec 478 MBytes 401 Mbits/sec
[ 5] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 58067
[ 5] 0.0-10.0 sec 412 MBytes 345 Mbits/sec
[ 4] local 192.168.90.100 port 55555 connected with 192.168.90.1 port 58074
[ 4] 0.0-10.0 sec 476 MBytes 400 Mbits/secA végére megjavult. De így is röhej. Inkább alszom. Majd próbálok másik virtuális NIC-et.
-
bambano
titán
windows verzió függő, de kapcsold ki a linuxon a tcp window scalingot*
ezt pl. xp-n is muszáj kikapcsolni, ettől akár harmincszoros gyorsulás is elérhető.
xp-re esetleg rakj fel hálózati tuningoló programot (pl. upc webjén meg lehet keresni).ha virtualizált az egész környezet, meg kellene próbálni jumbo frame-eket használni a virtuális networkön.
* úgy értem, hogy a window scaling rosszul van megoldva windowsokon, ráadásul verziófüggően rossz. ezért jobb, ha nem hagyod, hogy egerésszen vele, hanem a linuxon tiltsd le és akkor a windows is lekapcsolja.
szerk: addig ne nyugodj meg a hálózatot illetően, amíg a bazi fájl apacsról olvasása 110 alatt van.
-
Ja hát linux-linux között minden normálisan működik. De amint képbe kerül a windows, feje tetejére áll a világ.
Bazi fájl sambán írása linuxra 65-70MB/s. HDD-ről SDD-re, amin a virtuális gép is van.
Bazi fájl apache-ról olvasása 45-50MB/s.
Bár igaz, ez SSD-ről SSD-re, de szerintem nem ez a szűk keresztmetszet, feladatkezelő is megmondta, a chrome terhelte 100%-ra az egész CPU-t. 
~3000 apró fájl olvasása NFS-sel ~1.9MB/s, sambával ~4MB/s.
Blokkméretet gondolom kliensoldalon kéne állítani, de a dokan / nekodrive a kliens, s nem találtam ilyen opciót.
szerk:
Bazi fájl sambáról olvasása 50-55MB/s.
Bazi fájl NFS-ről olvasása 16MB/s.

-
bambano
titán
válasz
juhaszattee
#10
üzenetére
és akkor összevetjük az eredeti kérdésben szereplő sima otthoni windows stringet a válaszodban szereplő ultimate és enterprise meg hasonló stringekkel, éééés....
-
bambano
titán
mindenféle trükközés nélkül két teszt:
2148532224 bájt (2,1 GB) másolva, 18,2705 mp, 118 MB/mp
8589934592 bájt (8,6 GB) másolva, 73,1415 mp, 117 MB/mpkis trükközéssel gigabiten:
2148532224 bájt (2,1 GB) másolva, 0,261153 mp, 8,2 GB/mphmm. kis meglepetés, hogy a debianos nfs már tcp-n megy.
-
juhaszattee
csendes tag
Kicsit el van dugva, de állítólag megy, én nem próbáltam.
Arch wiki a világ legjobb dolga

-
Ja, benéztem.
Sambát használok jelenleg a virtuális linux és windows host között, és elég lassú kis fájlok esetén. Kicsit utánanéztem. Lehet akkor meg kéne próbálnom átállni NFS-re, viszont sima otthoni windows alá állítólag nincs kliens. Vagy van, csak el van dugva? Meghajtóként csatolnám, ahogy eddig a samba share-t. -
bambano
titán
ööö van itt egy kis konfúzió.
az nfs alapból udp-n üzemel. tehát a tcp offload engine alapból nullát ér az nfs gyorsítása szempontjából.
-
#94180096
törölt tag
-
Próbálj ki egy gettólinuxot, azzal maximális teljesítmény érhető el. Persze közel nulláról kell telepíteni a rendszert, és mindent a csomag-kezelő fordít le, ami lassan megy, de az eredmény a lehető leggyorsabb lesz, ha érted a témát.

Egyébként szerintem maga a limit az NFS-ben lesz.
-
Az offloadingot az eszköz-kezelőben elvileg be tudod lőni a hálókártya beállításainál.
-
#94180096
törölt tag
[hadszóljon]
Új hozzászólás Aktív témák
- PRÉMIUM WHITE PC - 9800X3D / 9070 XT Hellhound Spectral White OC / ASRock X670E Taichi Carrara 3
- Apple iPhone 15 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Asus ROG Strix G16 Notebook! i9-14900HX / RTX 4060 / 16GB DDR5 / 1TB NVMe! BeszámítOK
- MSI Katana GF76 - 17.3"FHD 144Hz - i5-11400H - 8GB - 512GB - Win11 - RTX 3050 Ti - MAGYAR
- 2027ig GYÁRI garancia Lenovo V14 / Ryzen3-7320 / 8gb DDR4 ram / 500gb NvMe SSD / WIN11
- Bomba ár! Dell Latitude 5500 - i5-8GEN I 16GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- HIBÁTLAN iPhone 13 Pro Max 256GB Sierra Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3521
- Okosóra felvásárlás!! Samsung Galaxy Watch 5 Pro, Samsung Galaxy Watch 6 Classic
- Apple iPhone 13 Pro Max Graphite ProMotion 120 Hz, Pro kamerák 256 GB-100%-3 hó gari!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő


Iperfet próbáltam még, host = client, guest = server:
Bár igaz, ez SSD-ről SSD-re, de szerintem nem ez a szűk keresztmetszet, feladatkezelő is megmondta, a chrome terhelte 100%-ra az egész CPU-t. 





