pokud dobre pocitam, neni 100 MB/s, ale 1 Gbit/s == 1000 Mbit/s (slusni obcane, prominte, obchodnici vladnou svetem ;-)) == 125 MB/s. To je pri kopirovani filmu docela rozdil :-)
Uprimne, 100 MB/s z OCZ Vertex 3 na desce se sata2? To si rika o koupi nejakeho rozumneho radice.
Kdyz uz delate takovehle testy, vyzkousejte nekdy prenos bez/s jumbo frames. Moje posledni testy ukazovaly zlepseni v radu jednotek procent (nejvice v pripade 9K, asi 10%), ale na Pentiu III :-(
Pri sietovom prenose treba ratat s overheadom, t.j. kazdy paket ma nejaku hlavicku protokolu (TCP, IP...) a taktiez je mozne, ze na sieti bol aj nejaky iny traffic, ked aj minimalny. V clanku sa nepisalo, ze sietovy kabel siel priamo do druheho pocitaca.
Tym padom rychlost 100-110MB/s sa da povazovat za realne maximum na gigabite.
MTU 1518B
- 18B ethernet
- 20B IPv4
- 20B TCP
-> nejmene 58B z jednoho paketu je rezie. To jsou necele 4 procenta. 4% z 125MB je 5MB. Takze porad mi ke zminovane stovce 20 MB/s chybi. A to je opravdu dost. I tech vasich 10 je dost, vzdyt je to "skoro 100Mbit"! Proto se taky ptam na vliv jumbo frames :-)
Provadet mereni na levne siti a neodpojit ostatni stroje? To je moc i na clanky tohoto typu...
"se uplne vyprdni" neni zrovna profesionalni odpoved. Radsi bych si precetl "pri pouziti sitovych karet XYZ pres switch UVW teklo N kpps, coz realne odpovida M MBps na danem protokolu, a na jadre A.B.C to prineslo zrychleni/zpomaleni D %, prestoze se packet rate zmensil"
Misto "ti to rozesere sit" se da napsat "nedoporucujeme nasazovat do siti, kde hrozi pripojeni nekompatibilniho hardware". Tohle jsou veci, ktere da rozum. Ale testovani sebere nejaky ten cas (dokonce vetsi nez psani prispevku do diskuse), tak by ho mozna bylo fajn vyuzit efektivneji.
Ja SMB na stahovani filmu nepouzivam a v clanku o pouzitem protokolu nic moc neni, akorat se zminuje FTP v zavorce v jinem kontextu. Proto pocitam dostatecne velky soubor a tim zanedbavam rezijni spojeni FTP -> jen binarni data. Jestli je to merene pomoci prenosu v SMB, patri to tam napsat s poradnym varovanim.
Prosímtě, tak jinak. Jumbo-frame má měřitelný reálný význam při nasazení v dedikovaných 10Gbit sítích se switchi v ceně desítek tisíc dolarů. Takovou krávovinu prostě na síti postavené ze šrotu a běžných desktopů nebude nikdo vědecky testovat. Obejdi si deset kancelářských počítačů v nějaké malé firmě (klasicky nakupovaných tak, že když jeden zdechne nebo začne nadmíru padat, tak se koupí nový). Co integrovaná karta, to jiná max. MTU. Aby to fungovalo, musíš všechen ten šrot sladit na nejvyšší všude podporovanou MTU. Do toho máš síťovou tiskárnu, která samozřejmě žádnou Gbit síťovku nemá, dvě webkamery (ditto) a v rohu už deset let stojí záhadná zaprášená piksla, při jejímž odpojení se něco brutálně rozesere, takže na to nikdo nešahá a obchází to uctivě obloukem od té doby, co o to zavadila uklizečka smetákem a firma byla celej den offline. No, a tady budeš testovat jumbo frames a jestli z toho vymáčkneš o 10MBps víc. LMAO.
Tak jinak :-) Obchazel jsem tuhle napriklad pocitacovou ucebnu ve skole, kde jsou vsechny stroje stejne a behem vyuky studenti loaduji gigabajty obrazku/videa/map ze serveru, pro ucely vyuky. Bohuzel, skolstvi ma dneska strasnou spoustu penez na servery, ktere nejsou ze stareho zeleza.
Nebo kancelar se 4 cca tri roky starymi pocitaci pripojenou do cisca na chodbe za nekolik desitek tisic, protoze ve stejne budove je takovych kancelari 20. Firma se ctyrmi pocitaci urcite da prednost dedikovane 10GE siti pred serverem ze stareho zeleza. Tiskarna bude zapojena do nej, kdyz uz tam tech 50W bude zrat. A jak na potvoru, zamestnanci renderuji vselijake vizualizace jako o zivot. A jestli pracuju se souborem a stahuje se mi byt jen o vterinu dele, na produktivite to je znat (psal o tom jednu dobu blog i Joel Spolsky). Je to presne ten rozdil mezi "zmacknu refresh-vidim vysledek" a "zmacknu refresh-chrrrr-vidim vysledek".
Tech pripadu, kdy by to pomohlo, je vic. Nikdo netvrdi, ze to musi vsichni nasazovat. Pritom staci napsat 1 prepinaci skript a kazde mereni 2x zopakovat. Nebo uvest odkaz na relevantni mereni. Evidentne je ale jednodussi posilat kilobajty plamenu do diskuse, takze si to o destivem vikendu nekde zmerim sam.
Ano, souhlasim. Az na to, ze v tomhle pripade se i ten SOHO switch cely svuj zivot flaka, protoze relativne daleko vic zatizene jsou tyhle sroty. A ty maji i jinou funkci nez jen predavat data mezi diskem a sitovkou, takze dava smysl jim tu praci ulehcit.
Necekam zadny radovy narust, jen me zajima rozdil treba na necem v tom socketu AM2.
Boze ...
load average: 0.00, 0.01, 0.05
AMD 2k (skt A), prave routuje cca 5+5Mbit, streamuje cca dalsich 30Mbit do vnitrni site a dalsich 10Mbit uklada na disk ... generuje to neco pres tisicku pkt/s
Takze se du dloubat v konfiguraci site, nastavovat dzambofrejmy, abych z toho loadu udelal 0.04 ... to se vyplati.
Stavime !DOMACI! server - ctu uz v nadpisu. Ty doma generujes miliony paketu za vterinu abys potreboval resit, ze ti nestiha switch? Jumbo frames ma smysl resit ve velmi (!velmi!) specifickych pripadech, a pokud stavim server (a sit) z "odpadkace", tak nema smysl neco takovyho ani zminovat.
Pro zajimavost, muj domaci switch zvladne 48Gbit/s a 35Mpkt/s.
Je to šílenec. Před pár lety jsem překládal test asi patnácti 10Gbit switchů z amerického Network Worldu. Jako jen to testovací zařízení stále asi jako auto střední třídy a testování trvalo tejden - ta piksla musí bejt schopná zahltit síť, jinak testování nemá smysl. To jsou ale ti Amíci blbci, když "staci napsat 1 prepinaci skript a kazde mereni 2x zopakovat." - v podstatě stačilo vzít ze smetiště nějaký Pentium a mohli jet. :-)))
O 10GE sitich a milionech paketu jsem ja nezacal. Chtel jsem jen vedet, jaky ma vliv nastaveni vetsiho MTU _v domacim prostredi_. 1 prepinaci skript na serveru ze srotu samozrejme staci, nikdo tu negeneruje zadnou extremni zatez.
Co je na tom divneho? Az tu bude clanek o nestihajicich switchich, rad si ho prectu. Tady spis nestiha ten stary srot, kdyz kopirovani z 500MB/s SSDcka pripojeneho do sata2 po gigabitove siti bezi jen na 80% teoretickeho maxima dane site.
„MTU 1518B - 18B ethernet - 20B IPv4 - 20B TCP -> nejmene 58B z jednoho paketu je rezie. To jsou necele 4 procenta.“
Člověk by řekl, že při TCP tam toho lítá trochu víc. Ono se také TCP spojení navazuje, pakety se potvrzují.
Nehledě na to, že IP je síťová vrstva, pod tím fungují nižší vrstvy a ty si také leccos mohou posílat pro služební účely.
Vazne tam tech acku, arpu, syn/finu, dns, mdns a ruznych announcementu lita 10 MB/s? I kdyby to mereni probihalo stylem "ssh remote spust_mereni.sh > vysledek.txt", po par vterinach se tyhle jednorazove veci amortizuji.
To, o cem autor clanku pise, ze je "maximalni prenosova rychlost 100 MB/s", je 80% teoretickeho maxima. Vsechny tyhle ptakoviny dohromady pres 10% neprelezou.
"Velke ramce se projevi jen tehdy, kdyz nekdo posila spoustu malych"
Vazne?
Mam-li wirespeed gigabitovy switch, muzu mit pakety klidne 64B a porad z nej vytahnu gigabit, coz se o PC ze stareho zeleza rict neda, protoze 125M / 64 = 1.9 Mpps. Kernel zpracovava pakety, ne bajty, a to navic jeste v burstech kvuli interrupt livelock mitigation. Takze kdyz udelam pakety vetsi, zvladnu toho vic "pri jednom". Dava smysl?
Kdyz je mi duch DMA kontroleru naklonen, buffery jsou spravne zarovnane, mam dobre napsany operacni system a mesic je v uplnku, muzu pouzit zero-copy operace, takze do ovladace pritecou primapovane stranky s daty z user-space (jako iovec) a kopiruje se jen jednou, odsud do karty, a dela to DMA za me. Co me zajima, je realny vysledek pomeru zpracovani jednoho paketu (interrupt, zamky na deskriptorech na karte, kontrola hlavicek atd.) a jeho kopirovani (ktere je umerne jeho delce) pri paketech ruznych velikosti.
Takze vezmu-li sunku, ktera bude pri gigabitu na pokraji svych sil, zajima me, jak moc ma v realu vliv si s timhle pomerem hrat. A gigabit v domacich podminkach vygeneruju velmi snadno, pricemz sunka bude mit s velkym mnozstvim paketu problemy drive nez posledni xeon za spoustu penez.
Prosímvás, a k čemu přesně vám tohle bude na té šunce, která bude ukládat data na deset lej starej IDE disk (viz článek)? Přičemž za slušnou Intel síťovku dáte asi víc, než stojí celej ten autorův šrot dohromady, akorát ji nebudete mít kam zapojit, protože v troubě vypečený šrot nemá PCI Express slot. :-))))))
To neres, sak on neumi ani citovat to na co reaguje => je to negramot => pojdme jej politovat, takovych se uz moc nenajde, meli by sme ho vystavit v zoo.
Obyc desktopovka stoji tusim tak 1k5 (coz pocitam naprosto minimalne zdvoj az trojnasobi cenu toho vraku), slusnejsi stoji 3k+ a to se vyplati, ze ;D.
BTW: Jak se rika, na kazdy klinec sa najde palica, takze s trochou nasili se urcite najde nakej slot do kteryho pasne. Ja uz videl na toto tema veci ... skoda ze v tech dobach nebyl fotak beznou kapesni pomuckou.
No, s kladivem by to s minimálním úsilím mohlo jít do nějakého AMR slotu, občas se na těch šrotech najde. :P
Ta sunka by ukladala data na ten novej OCZ Vertex 3 nebo zanovni HDD, o kterym pise clanek, ze na limit narazi. Za i82574L dam sest stovek a ten srot, se kterym to autor clanku testoval, pcie ma.
K dalsimu prispevku: to nebyla citace, ale parafraze. Muzete ji misto urazeni opravit. Zatim jsem krome vasich nazoru nenasel jediny test, ktery by jasne vyvracel pouziti jumbo frames na hardware podobnemu tomu ze clanku. Opravdu nehodlam zalohovat na deset let stary IDE HDD, ani na compactflashky v raidu.
Moje vysledky z Pentia III byly, jak uz jsem psal, 10%. To neni zanedbatelne, muzete-li si to ve svem prostredi dovolit pouzit. Mate vysledky ze srotu ze clanku?
Nikdo o nicem nepolemizuje, ani o autorovych kvalitach a znalostech ;-)
To nekomu vadi, ze se cena zdesetinasobi? Pokud to bude fungovat plnou rychlosti a nikomu nebude vadit riziko, ze kterakoliv komponenta upecena v troube muze kazdou chvili vybouchnout a neni v zaruce, co je za problem?
Mel jsem za to, ze to je cil clanku. Vzit srot, zdesetinasobit jeho hodnotu vymenou komponent, na kterych zalezi (zdroj, disky, sit) a pouzivat ho k tomu ucelu stejne jako nekolikanasobne drazsi stroj novy. Rizika at si kazdy nese sam.
Ja v supliku volne SSD/terabajtove HDD nemam, vsechny se pouzivaji. Vy ano? Jestli cenu zdeseti- nebo zdvacetinasobim kupovanim veci, ktere nemam, mi prijde irelevantni. Bez disku se totiz dost blbe neco stavi.
Pokud vite o barebone sestave, kde neplati:
cena_barebone_bez_disku > cena_serveru_ze_supliku + 600_Kc_za_sitovku
postnete sem prosim odkaz.
Na rozdil od autora clanku, ja suplikove disky ani zdroje nehodlam pouzivat. Chce-li je nekdo pouzivat, usetril ;-) Rec byla o SSD a zanovnich HDD.
Tak zde musim dat za pravdu. Ekonomicke mysleni rady ajtaku konci u ceny zarizeni(zdarma). Nepocitaji uz naklady usle prilezitosti(napr.podilet se na opravdu zajimavem projektu). Nepocitaji cenu prace. Nepocitaji nutne zdroje k vynalozeni ke zprovozneni levneho pc.
Nakonec cena takoveho renovovaneho pecka dosahne ceny levneho nettopu s atomem jenz ma jeste nizsi spotrebu. A to se vyplati;)
A predesilam ze se v tomto pripade nejedna o to naucit se neco noveho a o zabavu. Je to hloupa a blba x86 platforma ktere jsou vsude hromady. Kdyby si na ebayi nakoupili hromadu atmelu,armu,sparcu,powerpc,fpga xilinxu a ja nevim ceho tak ani neceknu. Tady je to o nicem. Neni co se noveho ucit a o cem badat.
To záleží hlavně na nastavení burstů a velikosti paměti přiřazené síťovce. Pokud máte stejně velkou paměť a bursty nastavíte vhodně tak, aby se paměť posílala při velkém zaplnění, tak výkon bude víceméně stejný a váznout to bude hlavně na síťovce. Nakonec nepřenášíte real-time video. Co se projevuje vám, je akorát to, že bursty máte nastavené pořád stejně a alokovaná paměť se moc nevyužívá, tak se zvětšením velikosti paketů přenese víc dat během každého burstu.