gigabit ethernet a valóságban

Sikerült kiépíteni a gigabites kártyával ellátott gépek között a gigabit hálót (switch-el), már cat6-os kábellel mennek, de csak nem tudom az átviteli sebességet kimaximalizálni.
Eddig nfs-t használtam, de azt most felejthetem is el...

nfs legjobb esetben is 5 mega átvitelére képes, és még a procit is megzabálja.
A szervergép, amiről másolni akarok egy 1,8-as p4, ami ondemand-al ugrál a max és a min (225mhz) órajel között. ide vinyó, semmi különleges. (debian testing, debian-os kernel, mert már arra sem érzek nagy kedvet, hogy új kernelt forgassak:)

Miután kipróbáltam pár progival, az mtu növelése és az ipv6-ra való átállás sokat dobott az átvitelen. A szerver valami miatt nem bírta a 9000-es mtu-t, bár azt tapasztaltam, hogy 3000 fölött inkább már lassít, úgyhogy maradtam a 3000-nél.

Kipróbáltam pár ftp szervert is, végül a vsftpd nézett ki a leggyorsabbnak.
megabájtperszekben, amiket max a progik produkáltak:
nfs ~ 5 (ipv6-ot nem igen támogat)
ssh ~ 7 (titkosítás miatt gondolom, mert a hálóból olyan 10 körül használ)
samba ~ 10
vsftpd ~ 15
apache2 ~ 40 (ez persze csalóka, mert a vinyó ugyanakkor csak 20-25-el tud írni, úgyhogy időről időre rendesen leesik)

Itt jött a kliensoldalal a probléma... transzparendsen szeretném használni a szerver vinyóját, hogy bármilyen programmal bármihez hozzá tudjak férni.
nfs-el ez megoldott volt.
Az ftp tetü lassú, azt a sebességet el tudtam érni curlftpfs-el (http://curlftpfs.sourceforge.net/) is. Végülis elviselhető, de persze ennél több kell! :)
apache2 volt a leggyorsabb, de mivel lehetne ezt kihasználni? nincs nagy kedvem mindig böngészőben töltögetni, sőt írni sem tud. Beizzítottam benne a dav-ot.
cadaver továbbra is produkálja a 40 körüli sebességet. Jó megoldásnak tűnt a fuse-t használó wdfs (http://noedler.de/projekte/wdfs/index.html), de mikor láttam, hogy az is csak 12-15 körül tölt, szembesülnöm kellett vele, hogy a következő szerepel a rídmíjében:
- read/write of big files (~ 50 MB+) is slow, because the _complete_ file
will be GET/PUT on a request.
ez reálisnak is tűnik, mert cp-vel a 800 megás fájl másolását, ha ctrl+c-ztem, akkor másodpercekig tartott, mire reagált rá és addig töltötte tovább.

Itt állok gyórs szerverrel, de rendes kliens nélkül...
http://httpfs.sourceforge.net/ nem akarja megenni az apache-ot.
vannak még másmilyen fuse dav fájlrendszerek, de azok 50 millió évesek...
http://www.asperasoft.com/index.html ez érdekesen hangzik, de fizetős, meg ki tudja milyen a kliensprogi...
http://grifi.sourceforge.net/ ehez valami eszeveszed gridftp szerver kéne. (meg ez sem mai gyerek)

( Elbandi v | 2007. 06. 12., k – 19:32 )

mihez kell ekkora sebesseg?
tobb kliens egyszerre fogja irni a vinyot? mert akkor az a vas keves lesz.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

igazából a szerveren töltöm a torrenteket. (azureus-al. x nincs a gépen, de ennek tudtam heggeszteni mindenféle más felületet (majd arrol is írhatnék egy részletes leírást), és a nincs kitiltva egy csomó oldalról, mint a legtöbb egyéb kliens).
aztán mikor lejöttek, sokszor szeretném elvinni magammal a laptokkon, hogy máshol tudjam megnézni. ez persze mindig reggel jut eszembe, amikor rohanok, szóval gyórs átvitel kell. következés képpen a szerver vinyójának csak olvasni kell (gyórsan)

Azt nem fogja tudni egyszerre két dolog felmountolva tartani. Szerintem neki pedig az kell, hogy a szerver is tudja piszkálni a filerendszert meg a kliens is. Vannak ilyen nfs alternatívák, hogy pl AFS. Érdemes lehet inkább ezeket megkukkantani.
Az ssh egyébként szerintem rosszul van konfigolva. Egy 600MHz-es P3 is éppen ki tud hajtani 100mbit-et (gyakorlatilag kb 11MB/s érhető el), ha jól van beállítva. Érdemes az ssh.conf-ban az adott hostra egy külön bejegyzést csinálni. Mivel lokál hálón fog csak menni, ezért lehet csutka titkosítást is használni, mint blowfish, cast128 vagy arcfour. Asszem az utóbbi kettő volt talán a leggyorsabb, de már régen mértem ilyesmit. A régebben default 3des-hez képest legalább 2-2.5x gyorsabb lesz. Ami viszont még fontosabb, hogy a tömörítés teljesen legyen kikapcsolva, az ugyanis borzasztóan eszi a processzort és emiatt lokál hálón többet árt, mint használ.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

az a baj, hogy pont a szervernek az ssh-ja van kinyomatva a netre.
a véletlenszerű hosztokról jövő brútforszoktól meg az sshdfilter véd. az nagyon bejött :)
a 100mbit-et ki is használja kb, de afölé nem megy nagyon. nekem meg elvben 1000mbit kéne.
afs úgynézem még experimentál, de majd meglesem azt is.
a gridftp mondjuk első látásra igéretesnek tűnik (de remélem a szerver részében nincs java használva. az azureus is eszi a procit (mondjuk a 225-re lehúzott procinak a felét:)))

Az ssh-nál az nem jelent problémát. Ha bruteforce-olnak akkor az autentikációs protokoll részt piszkálják csak (sőt leginkább csak a jelszót próbálják kitalálni). Ez azt jelenti, hogy legfeljebb az RSA és DSA titkosítások játszanak szerepet. Ezek csak a beléptetéskor/kulcsegyeztetéskor kellenek. A session titkosító az ami lehet 3des, blowfish, aes, cast, arcfour stb. ez az ami a már felépült kapcsolaton az adatforgalmat viszi és az a szerepe, hogy ne tudja harmadik fél a forgalamat lehallgatni. Az a jó, hogy a *kliens* gépen az ssh.conf-ban szerverenként külön meg tudod adni, hogy milyen titkosítást preferáljon. Olyan gépre amit *te* a *kliensről* lokális hálón érsz el, gyenge titkosítást állíthatsz be. A gyenge nem azt jelenti, hogy wep szintű, 2 perc alatt egy géppel megtörhető, csak annyit, hogy tudományosan ismert a brute force keresésnél valami előnyösebb algoritmus, és egy erős clusterrel belátható időn belül megfejthető a kulcs. Az átlag script kiddie nem tud ezekkel sem mit kezdeni. Ha tudna, akkor az openssh fejlesztők azonnal ki is vették volna a lehetőségek közül. Egyébként az AES128 is gyorsabb a 3des-nél, de senki nem gondolja úgy, hogy gyengébb lenne, sőt a jelenlegi tudásunk szerint valamivel még erősebb is.
Szóval visszatérve a lényeg az, hogy ha kivülről éred el a gépet, akkor a kinti *kliensen* mást állítasz be és akkor erősebb titkosítást, mondjuk AES256-ot fog használni. Gondolom úgysem 1Gbit-es a netelérésed, tehát ott nem kell spórolni a cpu terheléssel. Sőt 1-2Mbit esetén még simán megéri a tömörítést is bekapcsolni.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

a brútforsz dolgot csak érdekességnek mondtam :)
de ezt a kliensenkénti állíthatóságot nem tudtam (nem mondnám, hogy különösebben törődtem volna témával :)
azt mondjuk furcsálom, hogy kivülről és belülről is ugyan úgy relatív lassú, mire az ssh szerver bekéri a jelszavam. egyszere alap telepítésű debian szerver. semmit nem állítottam rajta. az sshdfilter is az auth logot figyeli és iptables-el tiltja a nem kívánt próbálkozókat.

akkor ezt a kliensenkénti dolgot majd lehet meglesem, de gondolom lokál hálón csak van valami rendes titkosítatlan megoldás fájlátvitelre. van egy ugyan ilyen apró probléma a cégnél is. ott is nfs-el csináltam a mentést, de a gép mikor éjszaka menti a többi gépekről az anyagot, sokszor már annyi adat van, hogy nem végez reggelre. nfs egy retek...

"de gondolom lokál hálón csak van valami rendes titkosítatlan megoldás fájlátvitelre"
Az ssh-t valahogy fordításnál kell patchelni, hogy engedje azt, hogy titkosítás nélkül menjen a forgalom. -> nem jó megoldás. Az ftp szerintem jó lenne. A vsftpd amennyire én tudom kb a leggyorsabb ftp szerver. Egy hosszú átvitel közben nézzél meg egy top-ot mindkét gépen, hogy mégis mennyire van leterhelve a cpu. Főleg a system terhelés érdekes. Ha valami driver zűr van, akkor a nagy system terhelésben látszani fog. Ki kéne nyomozni tényleg, hogy mi a szűk kereszmetszet, mert ha a net 40MB/s-et elvitt, akkor csak a vinyó körül lehet valami.
Abban egyébként egyetértünk, hogy az nfs szar, az egyes műveletek körülfordulási ideje miatt van egy csomó üresjárat benne, emiatt nem skálázódik jól.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( XMI | 2007. 06. 12., k – 23:28 )

Egyébként, ha ki akarod próbálni, hogy ténylegesen mit bír a net, akkor az egyik gépen:
nc -l -p 12345 > /dev/null
utána a másik gépen:
time dd if=/dev/zero bs=4096 count=*sok* | nc -q 0 szervergep 12345
utána elosztod a 4096*sok-at a másodpercre átszámolt idővel és megkapod byte/sec-ben az átviteli sebességet.
Az nc-t lehet, hogy másképp kell paraméterezni, mert abból többféle verzió is van, a lényeg, hogy legyen egy olyan switch berakva, ami megmondja neki, hogy lépjen ki, ha eof-ot kapott stdin-en.
Gyanús, hogy nálad a vinyó lesz a fő szűk keresztmetszet. Ha 20-25MB/s-et bír (hmmm nem egy 2.5"-os notebook vinyó ez véletlenül? Ha ondemand skálázódik a processzor az erősen notebookra utal.), akkor a filerendszer overhead-ek után simán lehet, hogy csak 15MB/s marad. A másik meg, hogy ha hdparm -t -vel megméred a vinyódat, akkor az az elejéről mér egy kicsit és közvetlenül az eszközről olvas. Lehet, hogy gyorsabbnak gondolod a vinyódat, mint amilyen valójában. A vinyók az elejükön kb 2x gyorsabbak, mint a végükön, most nem magyarázom el részletesen, hogy miért. Tehát számít, hogy hol a partíció, azon belül hova kerül a file, stb. A bonnie++ csomaggal lehet kicsit tesztelni. A zcav végigméri a vinyó átviteli sebességét, amit utána gnuplottal szépen ki lehet rajzoltatni. Hosszú ideig tart, de érdekes az eredmény. A bonnie-val meg filerendszer szintű műveleteket lehet megméretni. A buffered read/write eredmények az érdekesek praktikus szempontból.

Még egy ötlet, ha torrenttel letöltött fileokat akarsz másolni, akkor ne csodálkozz, ha lassú lesz, ugyanis az kis darabokban összevissza sorrendben tölti le. Már nem emlékeszem, hogy melyik kliens hogyan allokálja a fileokat letöltés közben, de biztosan van olyan (vagy az azureus vagy a konzolos pythonos), amelyik igen csúnyán fragmentált fileokat hagy letöltés után, amiket nagyon lassan lehet csak olvasni, mert a vinyó folyton seekel közben.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

a hálót a wmnet nevű kis dockap-al, a vinyót pedig egy gdesklets-es diskio mérővel mérem.
http://www.deviantart.com/deviation/45649761/
itt van egy régebbi kép, de ma is így néz ki a desktopom kb :)
mondjuk a szerver vinyóját nem mértem.
a gép maga egy gigabyte alaplap, egyáltalán nem laptokk vinyó.
hda: SAMSUNG SP1614N, ATA DISK drive
hda: max request size: 512KiB
hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)
hmmm... ugyanakkor most látom, hogy udma100.
na ezen nemtom hogy lehetne segíteni, mert 80 eres kábelen van.
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01)

hát, hogy az azureus fragmentál az lehet, de ha egyszer az apache bír 40 megát, akkor a többi progi miért nem...

UDMA100: ezen ne akarja segíteni, az Intel chipset az ennyit tud, sose támogattak ATA133-at. Egyébként is nem ez fogja korlátozni neked. Egyébként az apache-ra pont azt írtad, hogy a 40 megát nem bírja folyamatosan, csak amíg cache-ből megy.
Továbbá azok között a mérések között, amiket én mondtam, meg te írsz van egy nagy eltérés. Ezek a desktop appletek lényegében monitorozó programok, amik azt mérik, hogy a futó alkalmazások éppen mennyire használnak ki valamit, míg amiket én írtam, azok benchmark programok vagyis maguk terhelik le az adott eszközt és mérik meg, hogy eközben mennyit tud. Tehát érted a lényeget, egy valós alkalmazásnál nem tudod miért lassú, csak azt tudod megmérni, hogy lassú. Nem tudod mi a szűk keresztmetszet. Az egy-egy alrendszert külön megterhelő benchmarkok pont azért vannak, hogy meg tudd állapítani, hogy mi a szűk a keresztmetszet.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

hmmm... igaz.
na majd végigméregetem egyenként a cuccokat, akkor biztos okosabb leszek a témában.

fuse-nak egyébként vannak ilyen paraméterei:
-o large_read issue large read requests (2.4 only)
-o max_read=N set maximum size of read requests
-o use_ino let filesystem set inode numbers
-o readdir_ino try to fill in d_ino in readdir
-o direct_io use direct I/O
-o kernel_cache cache files in kernel
-o [no]auto_cache enable caching based on modification times
-o entry_timeout=T cache timeout for names (1.0s)
-o negative_timeout=T cache timeout for deleted names (0.0s)
-o max_write=N set maximum size of write requests
-o max_readahead=N set maximum readahead
-o async_read perform reads asynchronously (default)
-o sync_read perform reads synchronously
amikre tudok gondolni, hogy lefoghatják a wdfs-t esetleg, ha mégsem a nagy fájméret a gond, amiről beszél a rídmíje.

most néztem apacsról, ipv6-on wget-el. 40M-el jön, de addig a diskio aplet nem ír lemezaktivitást, mikor elkezd a lemezre írni, akkor leesik 16 körülre. ez azért fura, mert az én oldalamon sata vinyó van (desktop gép. nf7-s2g) gondolom a sata vinyónak nem kéne lefogni a dolgot. lehet, hogy a kernelben keféltem el valamit...
ata1: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xCC00 irq 16
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-7, max UDMA7, 234493056 sectors: LBA48
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA SAMSUNG SP1213C SV10 PQ: 0 ANSI: 5
SCSI device sda: 234493056 512-byte hdwr sectors (120060 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO
or FUA

a netcat-al hiába próbálkoztam
semmilyen forgalmat nem generál. sem a wmnet szerint, sem a tcpdump szerinte. (valami minimális 1-2 csomagot, de nem többet)
a végén így próbáltam:
nc -l -p 12345 > /dev/null
cat /dev/zero | nc 192.168.0.8 12345
vagy
cat /dev/random | nc 192.168.0.8 12345
de egyik sem. miután egyszer elindítottam a klienst, utána, ha újra próbáltam, a szerver oldal refjúzolt, szóval tuti, hogy valamit kommunikáltak.

( msandor v | 2007. 06. 15., p – 22:43 )

valami nem kerek nálad az NFS-el, mert nekem az a leggyorsabb átvitel két gép között...

--
by Mikul@s

ezt írtad: nfs legjobb esetben is 5 mega átvitelére képes, és még a procit is megzabálja.

az igaz, hogy nekem csak 100-as hálóm van, de arra akartam célozni, hogy ki is használja mind a 100 Mb6s-ot az NFS...
tehát több, mint 2*5 mega...

és semmit se varázsoltam a konfigokkal, csak sima megosztás async,secure,rw módban...

--
by Mikul@s