Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
beriem intel sieťovky z jediného dôvodu: najlepší ovládač, najdlhšia podpora. navyše majú ako jediní TOE, ktorý mi funguje so všetkými kernelmi.
intel ovladace su zrovna pekne svinstvo, napriklad na sietovky pre "desktopove" dosky neexistuje ovladac pre win server a treba to roznymi sposobmi ohackovat
doma mam na gbit sieti stroje s realtekom, killerom, intel sietovkou aj usb3.0 sietovym adapterom a nepostrehol som absolutne ziadny rozdiel v nicom...
blahoželám, do porovnania zahrňte ešte kávovar a bude to kompletné (USB3 nemá ani DMA, takže nevidieť rozdiel je len dôkaz, že neviete dané sieťovky porovnať)
ale teraz vážne; nemyslím si že to, čo vy považujete za rozdiel je to, čo ja považujem za rozdiel.
napr od supermicro mám sieťovky s čipsetmi intel 82575 a 82580. väčšinou sú to 4 alebo 2-portové karty. rozdiely medzi realtek a Intel kartami sú také, že s danými kartami pri 4Gbps (802.3ad) mám vyťaženie procesora v jednotkách percent. s realtekom to boli desiatky percent.
čo sa týka vašich problémov s intel sieťovkou vo windows serveri, tak predpokladám že hovoríte o všadeprítomnej intel 217-V. v linuxovom serveri funguje v pohode, vo windows serveri si musíte priplatiť za intel 217-LM. rozdiel je v nich iba vo firmvéri (LM podporuje aj vpro) a v tom že intel a MS sa dohodli, že v serveroch lacnú 217-L podporovať nebudú. ani jedna z týchto kariet do servera nepatrí, ich výkon je pri TCP fragmentácii v serveri nepoužiteľný.
nechápem prečo ľudia vášmu komentáru dali +
Ano - intel se historicky v mnoha věcech uchyluje k tomu, že tlačí koncové zákazníky do své segmentace desktop/server. Aby náhodou někdo neprovozoval serverové služby na levném desktopovém hardwaru, ó hrůzo! Z mého pohledu není server jako server, spousta serverů se reálně dost fláká, není potřeba mít v každém serveru supervýkonnou síťovku.
Zatím co jsem u Intelu potkal případy, kdy ovladač byl pro desktopové Windows ale nikoli pro serverové Windows, nebývalo to zadrátováno v binárech ovladačů, ale jenom v doprovodných INFech, nebo dokonce jenom v EXE instalátoru. Stačilo vypárat INFy z EXE instalátoru (případně stáhnout od intelu alternativně zabalený download = zipáč namísto EXE) a nasměrovat ručně "device manager" na serveru do správného adresáře, kde má INF hledat. Serverové varianty Windows mívají shodnou verzi NT kernelu s některou desktopovou variantou Windows - aktuálně cca NT 6.2/6.3 = Win8/8.1/2012/2012R2.
https://en.wikipedia.org/wiki/Windows_NT#Releases
- takže leckdy stačí najít správný INF. Pokud mohu soudit, digitální podpisy na ovladačích (reálně CAT soubor) dosud enkódují verzi NT kernelu, nikoli obchodní variantu/edici windows (desktop/server). Čili editovat INF už sice nelze jako za starých časů v XP a snad ještě 7, ale vybrat správný INF pro příslušnou verzi NTček pořád ještě jde :-) Otázkou je, jak dlouho do budoucnosti.
Toto nepovažuji za hackování, spíš za obcházení marketingových naschválů v intelím package managementu.
Tak zrovna jedna Intel sitovka me neskutecne nas**la pres vikend... potreboval jsem zkopirovat par desitek GB dat z jednoho laptopu, a odhadl jsem ze nejrychlejsi to bude pres domaci 1Gb sit (misto USB flesek/disku apod). Omyl, intel sitovka v laptopu tvrdosijne odmitala jit na 1G jak ve woknech, tak v linuxu... nakonec jsem to pustil pres ty 100M a sel delat neco jineho... neni vsechno intel, co se trpyti.. jinak na tendle problem sem narazil poprve, dosud mi intel (i jine) sitovky fungovali bez problemu.
jestli tě třeba nebrzdil kabel, šikulo ?
Me pri nasazovani gigabitu prekvapila ochrana proti prepeti. Jsem si rikal, co tam asi muzou mit, nejake diody nebo tak neco ... a ono ne, ono je to dost chytre na to, aby to neumelo gigabit ale jen 100MBit.
Precti si znovu co jsem napsal, a dej si facku.... napsal sem jasne "domaci 1Gb sit" takze jsem ji asi delal na 1Gb i zkousel, nemyslis ? sikulo....
Gigabitový ethernet používá 4 páry, pro 10/100 stačí dva (oranžový a zelený, piny 1/2/3/6). Pokud máte vadu na modrém nebo hnědém páru, jsou dvě možnosti: linkne se to na giga (protože handshake probíhá na nízké rychlosti) a pak to hnije = všechny přijímané pakety mají vadný checksum a jsou zahazovány, nebo si toho síťovky všimnou a linknou se rovnou na stovce. Mimochodem pod windowsama se dá na Eth portu zobrazit počítadlo chyb:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\Connections\StatMon]
"ShowLanErrors"=dword:00000001
Naproti to chce managed switch, abyste něco viděl.
V práci jsem několikrát řešil problémy typu "jede to pomalu" nebo "nechytí se link", mezi konkrétními dvěma krabičkami s RJ45 zásuvkou. Mám ten luxus, že mám k dispozici reflektometr - je to jak nasadit si potápěčské brýle, když lovíte něco na dně. Mezi zaznamenanými problémy jsem zažil např.:
Klasicky patchcord krimpovaný nekvalitními kleštěmi, který nemá všechny nože pořádně zamačknuté.
Nebo to může být rukama (všechny žíly musí být zasunuté až na konec dutinky) nebo špatnou volbou materiálu (konektory určené pro licnu krimpované na drát nebo naopak). Výsledkem bývají vaklavé kontakty - někdy hned, někdy až po pár měsících provozu. Taky jsem už viděl nedodržení zapojení párů apod. (krimpoval diletant) - to bývá teprve legrace.
Patchcord nakrimpovaný konkrétními kvalitními kleštěmi měl poměrně hluboko zalisované nožíky v RJ45, což v některých zásuvkách RJ45 (ne ve všech!) způsobovalo vadný kontakt = telepatický spoj. Stačí, aby zásuvka měla trochu míň napružené kontakty (takové ty drátky z fosforbronzu, jak česla nebo velrybí kostice) nebo se RJ45 sameček v zásuvce trochu víc vykloní / vytáhne až na doraz co dovolí aretace... = ztratí kontakt. Domáčknete konektor do zásuvky a chytí se.
V konkrétním modelu a značce notebooku jsem viděl RJ45 samici, která měla tuším prostřední dva piny víc zapadlé - nebo každý druhý víc zapadlý... už se nepamatuju. Jestli to bylo kvůli hotswapu nebo kýho čerta... prostě nějaký proprietární vynález-kurvítko = designová "vlastnost". Některé konektory pak do toho nedosedaly správně. Řešení: vzít jiný patchcord (míň zalisovaný) nebo zhotovit jemný háček z kancelářské sponky a přiměřeně mikrokalibrovaným hrubým násilím vyléčit vrozeně chromé kontakty v RJ45 samičce...
Osobně se mi podařilo nakrimpovat asi dva patchcordy, kde byl v konektoru zkrat mezi piny v páru. Jak? Konektor měl na konci dutinek ještě příčnou škvíru mezi žilami (nevím jak a proč a jestli je to normální) - a licny jsem při krimpování zarovnával těsně před zasunutím zabudovaným ostřihovačem na kleštích, který byl po letech používání už dost tupý... takže z konců žil (licen) koukaly "fousy". No a ty fousy se mi v konektoru na hlubokém konci dutinek potkaly v příčné škvíře... na druhý pokus stačilo konce žil ostříhnout ostrými štípačkami nebo nožem a už se to nepotkávalo.
A pak si ještě vybavuju neblahou tendenci asi posledních 3 let, že se ultrabooky osazují stovkovým metalickým ethernetem, nikoli gigáčem, jak bylo zvykem asi posledních 8 let předtím - ale na to byste si asi nenaběhl...
A pak historické vtipy typu karta 3com proti switchi Cisco Catalyst, kde se musela dávat natvrdo rychlost+duplex, protože auto-nego nefungovala... ale to jsem už asi 15 let nezažil. Možná jednou u nějakého opravdu obskurního železa.
Neprijde mi moc predstavitelne, ze by se dve 1000-base-T zarizeni spojili po kabelu ktery nema vsechny 4 pary tak, ze by tvrdili, ze maji link, ale pakety neprochazeli. V takove situaci prvotni inicializace te linky proste selze. Trochu otazka je co se stane po tom, cekal bych, ze "standardni" implementace PHY to bude zkouset do zblbnuti a bude ve stavu "link neni, ale ledka sviti". Inteli drivery na to maji nejaky timeout po jehoz vyprseni vramci autonegation zacnou ignorovat rychlosti nad 100MB.
Vice zasunute dva piny v 8P8C jsou pomerne normalni vlastnost nekterych (obvykle "znackovejsich") konektoru. Prijde mi, ze to asi kdysi melo nejaky smysl pro nejakou telco aplikaci, nicmene dnes je to asi hlavne o tom, jake konektory byly zrovna levnejsi (mam tu treba dva jinak vicemene identicke switche a na kazdem jsou konektory v tomhle ohledu jine).
Ohledně toho 1Gb handshaku na neúplném kabelu... nemám to zdokumentované a už si nepamatuju podrobnosti, je možné, že to tehdy bylo nějak "hraničně nahnilé" - realita je analogová :-) čili tím nechci zpochybňovat Vaše tvrzení, které je patrně naprosto správné.
Možná to tehdy bylo tak, že byl kabel relativně krátký a nakrimpovaný 1+2, 3+4, 5+6, 7+8 = nesprávně páry, úvodní handshake na 100 Mbps (10 Mbps?) klapnul, ale na gigu to pak nejelo... vážně už je to dlouho :-)
Další věc je, že jsem zaznamenal drobné odchylky v chování některých Eth portů. Třeba jeden levný switch od Netgearu byl ochoten linknout se na fyzickém loopbacku sám proti sobě (RX/TX v RJ45 zasmyčkováno) s následkem broadcast stormu nebo čeho - přitom jiné switche jsem k témuž donutit nedokázal. Ten případ s Netgearem jsem zaznamenal tak, že při propojení na jiný poměrně obskurní switch docházelo k broadcast stormu po *vypnutí* toho protějšího switche (asi nějaký silnější přeslech ve vypnutém stavu, nebo co - moc jsem to nezkoumal).
S gigovým RTL8111 a příbuznými (8168, 8169) jsem nikdy problém nezaznamenal. Zpočátku jsem měl tendenci nahrazovat je intelkami, po nějakých praktických srovnáních třeba v SQL provozu (rychlé dávky request+response) už to nedělám, neviděl jsem rozdíl. Možná jenom nemám tu správnou zátěž, abych pozoroval nějaký rozdíl v propustnosti a latencích malými pakety, ale v principu bych se toho nebál. Moderní gigové Realteky (8169 apod.) jsou na PCI-e, mají tuším SG-DMA, mají Message-signaled interrupty (IRQ), mají driver pro všechny možné OS (v leckterých OS od přírody) - co víc si přát... na PCI-e už tolik nerozhoduje velikost lokálních bufferů v čipu síťovky (viz datasheety moderních Intelů, máte problém se ten údaj dočíst, mimochodem queueing je na úkor latence) a latence reakce na IRQ(MSI) je asi buřt resp. shodná jako u Intelu... Co se týče ToE, je to hack do TCP/IP stacku hostitelského OS, odhadem se netýká UDP, reálný přínos je IMO sporný (četl jsem i nějaké negativní zkušenosti) - dejte vědět, pokud máte konkrétní čísla. Jestli má Intel delší latence než Realtek při krátkých paketech, může to být taky nějakou optimalizací softwaru ve smyslu "interrupt amalgamation" / polling / NAPI = za účelem snížení zátěže CPU...
Konkrétně z nekritického obdivu vůči hardwaru Intel jsem taky časem trochu odrostl.
Ohledně průchodnosti u firmy Intel: na gigabitu to není tolik vidět, ale třeba 10Gb Intelky z prvních dvou generací zaostávaly v průchodnosti za konkurencí (Myricom, určitě za specializovanými "capture" kartami dalších výrobců). Konkrétně gigové intelky mívaly dost rozdíl ve vyvážení bufferů RX/TX mezi desktopovými a serverovými variantami (na délku latencí krátkými pakety nemá vliv, spíš na průchodnost velkých objemů skrz TCP a ztrátovost při extrémní zátěži), plus softwarový naschvál že pro teaming musela být v systému aspoň jedna serverová intelka... Celý úžasný teaming v driverech od Intelu stojí a padá hlavně na tom, že MS Windows OS neumí nativně pořádný transparentní SW bridge (a případně další varianty "channel bondingu").
Taky jsem u Intelu zaznamenal několik otravných problémů. Jeden čas (údajně v začátcích e1000e) docházelo sporadicky a náhodně ke spontánnímu narušení doprovodné konfigurační EEPROMky Intel NIC čipů (93c46 nebo tak něco) - problém byl softwarový, nebo přinejmenším softwarově řešitelný, ale než na to přišli a v ovladačích upravili, trvalo to pár let.
Dalším problémem u expressových Intelek byl vadný power-saving režim na PCI-e lince (vypínání budičů při neaktivitě, nebo kýho čerta) - opět trvalo řádově roky, než někdo z linuxové komunity zjistil, v čem je problém, obratem to opravili v Linuxu, Intelu pak trvalo několik dalších měsíců, než to opravil taky v driveru pro Windows... a tohle byl problém, který trápil mnoho uživatelů hlavně na serverech, hodně lidí brečelo nad nesmyslnou ztrátovostí paketů.
Závěr článku souhlas - většina lidí síťovku neřeší. Soudě dle sebe bych ale síťovku řešil asi víc než zvukovku. Ta je mi opravdu putna, ale když vidím realtek LAN, trochu se ušklíbnu :).
Na druhou stranu Killerku bych nechtěl, považuji ji za přehypovaný produkt a nejsem si úplně jist kompatibilitou s budoucností (přeci jen to není a priori síťovka, ale procesor a pro něj je potřeba ovladač a firmware pro daný konkrétní OS - je to sice veselé řešení, které má obrovský potenciál na různá vylepšení, ale je to jako kupovat si na WiFi router PCčko a nasadit tam patřičné linuxové distro - je to zbytečný overkill). Neméně zajímavým a podle mě málo zmiňovaným faktem je, že Killer NIC kromě toho, že to je procesor, tak to je vlastně procesor s integrovanou síťovkou. A jsou si všichni jisti, že ta v procesoru integrovaná síťovka jako taková je lepší než běžná síťovka na desce? Já bych o tom dost pochyboval :). Takže máme (možná) běžnou síťovku a k tomu mezivrstvu v podobě procesoru, který ji dokáže ovládat - čili meziprvek navíc, o jehož zrychlujícím přínosu bych si osobně dovolil pochybovat. Ano, dnes je to typicky ARM, dříve to byla variace na Power, jestli se nepletu. Jednu takovou jsem viděl, byla od Freescale.
Pro mě je též optimální nasadit Intel, v krajním případě Broadcom. No, ale když už nic jiného není, i ten Realtek svou práci odvede ;-). Intel preferuji mj. z toho důvodu, že v čipsetu nezabírá PCI Express linku navíc (pro něj coby pro „integrovanou“ síťovku je v čipsetu už jedna linka vyhrazená a když není Intel síťovka, je tato linka nevyužitá a nevyužitelná).
Uplny suhlas so zaverom clanku aj s tymto.
Jediny nezmyselny produkt (cisty marketing) z tych spomenutych je ta Killer sietovka ( a to ju chtiac nechtiac mam v MSI tiez). Ten ich marketing o znizovani latencii v hrach je na smiech.
Intel - spolahlivost, podpora, vyborne ovladace, rokmi preverene, istota aj v server segmente
Realtek - odjakziva lowcost riesenie, avsak spolahlive a pre desktop uplne postacujuce
Broadcom - zalezi od modelu - byvali aj pruserove, da sa s nimi existovat ako pises - ale preco, ked je k dispozicii Intel a ceny su porovnatelne ?
Pokud se nepletu (a u je to nejaky patek, co jsem o tom cetl), tak Killer umi především jednu zajímavou věc - obsluha site nevytezuje CPU, data netecou "sem a tam", ale zpracovava se to vse hned na tom cipu a OS uz pak dostane "spocitana data", která jinak nejak "pocita" CPU.
Coz imho ma smysl v konkretnich pripadech, jako:
1. CPU nestiha - coz je otázka, nakolik je to aktualni v nabusenych hernich sestavách, kam to miri, imho vcelku zbytecny argument
2. snizeni latence kvůli rychlejšímu zpracovani dat. To imho smysl mit muze. Ona kazda milisekunda muze mit vliv a ne ze ne. A snizeni latence o 1ms muze proste byt docela fajn věc. Ovšem bavime se o nejakych TOP hracich, pro drtivou většinu lidi je to jedno.
Takze se jedna spise o marketingovy tah, pricemz urcite vyhody to ma, ale většina lidi je nedokaze docenit :-)
(Btw, svého casu jsem mel ping na nejake herni servery okolo 8-10, a tam uz změna o 1ms dela docela slusne procento :-))
V podstate mate ve vsem pravdu. Jen bych upresnil. TCP offload engine umi dnes kazda slusna sitovka, nicmene sam Atheros uvadi, ze u killeru mu jde hlavne o UDP. Ve slidech je jedina killer featura a to klasifikace packetu a nasledne na nem zalozeny QoS. V podstate se ale vyhoda projevi pouze v pripade, ze mate na pozadi zapnute torrenty.
http://www.slideshare.net/MSICS/inteligentn-ov-een-killer-e2200-v-produk...
Pod článek se mohu klidně podepsat. Mám v ntb síťovku "killer" a jaksi nepozoruju proti realteku rozdíl. A to mám nainstalovaný i ten jejich imba hyper soft, ala dlaždice, takže to vypadá jak metro aplikace i když to metro aplikace není (fakt divné). Dá se tam naklikat síťová priorita procesů, takže si třeba můžete nastavit pro hry vyšší prioritu než pro ostatní věci. Nikdy jsem to nepoužil. Pokud jsem někdy měl vysoký ping ve hře, tak bych ho měl tak jako tak (kvůli ISP, serveru atd). Jediné co je na tom "cool" (vyslovuj "trapné") je název - "killer". Nejsem si jistý jestli "dragon" od realteku je dostatečně cool, aby killera přebil v trapnosti názvu a tudíž ho milovníci "gaming" vzhledu (rozuměj "asijského nevkusu") preferovali před killerem. Být obchodní oddělení realteku, přidal bych pár dalších slovíček vyskytujících se v gaming světě (killer, sniper, tactical, ultra, hyper, super a podobně) aby to mělo na cílovou skupinu větší efekt
V dobach, kdy jsem ještě stahoval nejake věci a zaroven jsem hral online hry a zaroven linky ještě nebyly az tak propustne, jako dnes, bych se byl byval bez nastaveni priorit paketu nehnul - respektive bych nemohl stahovat a hrat zaroven.
Takze ono to svůj smysl mit muze...Samozrejme pokud někdo sedi na slusne lince a vlastne ani moc nestahuje, tak je to jedno
To ano, ale z Tvojej sietovky to ma zmysel tak po tom kabli ktorym sa pripajas do switcha, alebo routra. Inak povedane kontrolovat dokazes iba to, co odchadza smerom od Tvojho pocitaca. Samozrejme, pokial si mal prislusne nastaveny aj router (pripadne switch), to je ina vec, tam taketo veci pomozu (uprednostnovat DNS a hry ktore hras a torrenty spolubydla dat na najnizsiu prioritu). Ale zase ... tam si to nastavis opat iba smerom k Tvojmu providerovi, a dalej ti uz nedovolia kecat do toho ako si spravuju svoje siete.
Priznam sa, neviem co take by bezny domaci uzivatel resp. hrac potreboval aby zahltil Killer sietovku tak, ze musi prioritizovat trafiku na svojej lokalnej sieti. Ak uz zacne vymyslat veci s pripajanim sietovych diskov alebo virtualizaciou, nie je to bezny hrac. Napada mi jedine in-home streaming na iny pocitac.
Jojo... cool názvosloví a zvrhlé očně výtěrové dekorace (třeba kapotáž žebrovaných chladících tělísek na čipsetu tuším u některých boardů ASUS) mě taky dovádějí k slzám...
Ohledně Killeru... pokud to shrnu, cesta paketů vypadá takto:
A) standardní varianta:
PHY->MAC->[pci-e]->RAM->nabušený x86 hostitelský CPU
B) killer:
PHY->MAC->[pcie-]->lokální RAM->podvyživený ARM/Power CPU->[pci-e]->hostitelská RAM->nabušený hostitelský CPU
Co z toho asi může mít kratší latence? Principielně?
Má to asi takový smysl, jako vkládat redukci ATX napájení 20pin->24pin mezi starší zdroj a nový motherboard, "že aby se snížily přechodové odpory" (kravinimum, naopak se tam vsune další přechoďák do série.)
Offload celého IP stacku na koprocesor je IMO z principu skoro nesmysl. Akcelerovat se dají vybrané konkrétní funkce, za cenu hnusného hackování v IP stacku v hostitelském OS, a možná i za cenu
"zaseknutí vývoje" IP stacku v hostitelském OS.
Nakonec zbývá argument, že killer dělá hlavně QoS... fakt je, že jsem nezkoumal, co to vlastně umí, ale nějaký QoS scheduler umí síťový stack pod Windows od přírody už někde v XP SP3. Dále lze argumentovat, že QoS blázinec patří hlavně na vstup do úzkého hrdla - což v typické topologii LAN+WAN není koncový komp, ale router který kouká do hubené WAN linky. Na koncovém kompu to má relativně omezený smysl - výhodou by mohlo být, shapovat pásmo nikoli podle TCP portů (které se u P2P služeb a priori dost těžko definují), ale podle aplikace, která socket otevřela -> opět to patří spíš na hostitelský procesor a OS, než do nějakého koprocesoru s vlastním firmwarem, který vidí už jenom pakety.
Přijde mi, že s tím síťovým koprocesorem je to asi jako s HW RAIDem. Dala by se hledat výhoda v autonomii (koprocesor žije, i když je hostitelský OS mrtev), a případně ve fičurách, které soudobá "čistě softwarová" řešení postrádají. V případě Killeru nevidím ani jedno...
"Dala by se hledat výhoda v autonomii (koprocesor žije, i když je hostitelský OS mrtev)" - velky brat ma isto z takejto implementacie velku radost a vobec - z celeho riesenia tym uP.
Mě je zcela šumák, jaké řešení na desce či přídavné síťovké kartě mám. Podstatné je, aby to zvládalo -RYCHLE- právě ty malé UDP pakety (online hraní) a aby ovladače nebyly nějaké šílené. Ideálně aby to mělo podporu přímo ve Win, což v praxi může smazat rozdíl mezi lepším, ale nepodporovaným přímo M$ řešením a integrovaným shítkem.
Když jsem kdysi srovnával klasické realtekové PCI síťovky s PCI Intel síťovkou, tak kromě nepohodlnosti (nebyla Win podpora přímo, bylo třeba instalovat ovladač) měla Intel síťovka rychlejší přenos velkých souborů, ale o něco slabší ping odezvu. A rychlost odezvy u mě vyhrála...
To ovšem bylo před 10 lety... Dneska bych neočekával nějaké velké rozdíly a pokud soudruhům z Realteku uniklo, že hráči her budou vyžadovat co nejlepší PING a že tedy UDP pakety musí mít přednost a musí je zvládat SAKRA rychle, pak je nejvyšší čas, aby to opravili.
Určitě dokážou lepší věci, než "kanón na vrabce" v podobě ARMu + zabudovaného síťového rozhraní s jednom čipu. A pokud ne, tak k čertu s nimi!
PS. S "hustonázvoslovím" jděte k šípku.
Pro připojení k netu je to jedno. Pokud ale přes síťovku potřebujete v rámci LAN kopírovat s maximální rychlostí, tak preferuji Intel.
Mě je jedno co tam mám za síťovku, ale příležitostně mě míchne, že Vmware Hypervisor většinou Realteky neumí. Takže takové to domácí virtuální žvýkání odpadá. :/
To je normalne. Vo Vmware viacero desktopovych sietoviek nefunguje. Aj preto Vmware nepouziam.
To je fakt dobry dovod vyberat virtualizacny nastroj podla desktopovej sietovky....
Tak ony dneska ty hypervisory umí víceméně totéž, jen se to jinak jmenuje. Pokud chcete něco pro domácí použití a provozovat to na běžném PC, tak na ten problém s ovladači prostě narazíte. Málokdo si koupí na domácí hrátky certifikovaný server. Ano, taky jsem přecházel z VmWare na Hyper-V kvůli problémům se síťovkami a rychlosti diskových operací. Ne, že bych snad chtěl VmWare podezřívat z nižšího výkonu, ale prostě to mé železo nebylo ve WmWare podporováno. Do Windows Serveru jsem ovladače dostal jednodušeji.
Nejde o server, ale o konkretny komponent - sietovku. Ale v podstate doma sa take riesenie tolerovat da.
To je prave zaujimave, mne spoznal integrovane Realtek sietovky na doskach kde som to skusala spustit (nejake Gigabyte dosky s AMD chipsetmi). Intel Desktop sietovky nie, len serverove, ale tieto Realteky bez problemov pouzival aj ked oficialne by nemal.
Tak ja sitovku doma resim docela urcite a jeden z hlavnich pozadavku je u mne 2x sitovka, idealne Intel.
S realtekem mam obecne spise horsi zkusenosti se stabilitou site a zivotnosti sitovek.
Ja zase musim Realtek vychvalit, ze maji uz dlouho pohodlne dostupne ovladace na webu. Treba Broadcom sveho casu na webu psal, ze ovladace poskytuje jen pro zakazniky a ne pro uzivatele. U Intelu se clovek musi proklikat spoustou modelu, nebo se modlit, aby jejich program hledajici ovladace mel zrovna svetlou chvilku. U Realteku mam proste stazene ovladace na disku, ktere muzu pouzit pro jakoukoliv jejich sitovku v jakemkoliv PC, co mi zatim proslo rukama.
A to já zase jedu pro změnu na PHY od marwellu. Zatím jsem ho potkal v naprosto každém hi-endu, co jsem kdy vlastnil (K8N Platinum, Sapphire X58). Síťovka je mi tak nějak u zadele, protože v současné době mám latenci na některé onlinovky i nad 50ms, vzhledem k zarušení města wifinama a faktu, že ISP má jedinou end-point možnost právě tu wifi.
O vyhypovaném killeru jsem slyšel, podle mne pěkná kravina. Ještě mě tehdy fascinovalo, že to prodávají jako kartu a to za "lidových" cca 2kkč+. Stejně useless jako PissX karta ještě od firmy Ageia.
Zvukovka na desce je už něco trochu jiného, ale je mi v podstatě jedno, co na desce mám, stejně si tam strčím svoji X-fi elite pro.
Hmm... já mám na Marvell (Yukon2 gigabit NIC) negativní vzpomínky. Na konkrétním modelu motherboardu měl systematickou vadu - po nějaké náhodné době provozu (pár hodin až pár dní) se čip kousal, pod Linuxem bylo potřeba hlídat skriptem (pingem) konektivitu a v případě potřeby vyresetovat PHY (tuším ethtool -r). Ani to někdy nepomohlo - v tom případě jedině reboot. A podle ohlasů různě po webu jsem nebyl sám, ani to nebyla vada zrovna mého motherboardu. Marvell SAS/SATA je fajn. Marvell čipset do SoHo switchů... taky nikdy žádný problém. Marvell onboard síťovka... ježí se mi chlupy, přestože už to v nových revizích křemíku asi opravili. To už radši Atheros (Attansic) L1, pár let zpátky populární superlevný onboard gigabit (pro výrobce boardů patrně levnější alternativa k levnému Realteku). Člověk musel trochu pohledat drivery, ale pak to jelo bez řečí.
Jo tak to nevím, frčím pod okénkama a absolutně bez problému. Spíš mi vadí zlobící windows share skrze několik mašin, kdy po pár dnech provozu je síťový disk nedostupný.
To má možná něco společného s tím, že implementace Marvell PHY je v Linux kernelu neskutečná prasárna. Inicializuje se jako jeden jediný chip a pak se postupně přihazují zněny a přibližuje se tomu skutečnému. Na výrobcem doporučenou konfiguraci se kašle, errata k těm čipů očividně nikdo neviděl.
Celé to vypadá, že se to dělalo stylem - přečetli jsme nějaké registry z inicializováho chipu, tak to tam nasypem a uvidíme, co to udělá.
Marvell za to nemůže, ty chipy jsou dobré, dobře dokumentované. V embedded je používám několik let.
Hezky :-) Díky za komentář. Možná by se dalo polemizovat, jestli je ta dokumentace otevřená nebo pod NDA, a pokud otevřená, tak odkdy... ale i tak. Díky za informaci. V mém případě se jednalo o 88E8053.
Děkuji za tohle téma. Potýkám se s podezřením, že právě Realtek síťovka je slabým místem v dostupnosti mého počítače z intenetu. Načítání webových stránek běžících na domácím serveru je pomalé. Streamování do wan se kouše ačkoli na lokale OK. K poskytovateli bych měl mít dostatečný uplink. Napadlo mne, zda tyhle desktopové síťovky nemají nějakou asymetrickou strategii.. Tj. optimalizaci na downlink a slabý výkon v uplinku. Stojí za to pořídit nějakou NIC Intel dedikovanou síťovku? Navíc nemůžu vyloučit i virtualizovaný server na stávajícím železe. Díky za jakoukoli skutečnou praktickou zkušenost.
Zkusil bych nekde pujcit od kohokoliv libovolnou PCI nebo PCIe sitovku. Klidne i 100mbit RTL8139 nebo podobny strep. To co popisujete muze byt kombinaci vasi sitovky a treba switche, ktery si s ni nerozumi (super vzacne), vadnym kabelem (hodne caste), vadnou sitovkou (vzacne), rozhrabanym OS/SW (caste).
RTL8139 jsem historicky cca 10 let zpátky zažil v některých sestavách, kde se choval "nahnile" - onboard RTL8139 pustil třeba jenom 30 Mbps, přitom diskrétní intelka zasunutá do PCI slotu jela za jinak stejných okolností 100 Mbps. Nepochopil jsem. Od té doby neberu RTL8139 jako etalon průchodnosti při hledání problémů.
Souhlas, podíval bych se na kabel. Stačí malá mechanická nekompatibilita nebo "vychytávka" v některém z konektorů. Bohužel ideálním nástrojem na ladění tohoto je reflektometr, což je dost těžko dostupná hračka... sám mám jenom bastlený adaptér k osciloskopu (ale ukazuje bezvadně - dáno vlastnostmi osciloskopu).
Je zajímavé že ve světě v kterém se zakazují žárovky, nafta se kurví MEŘEM a energetický štítek je nutný i na otvírák konzerv nikoho ani v odborné diskuzi, o eurohumerech nehovoříc, nezajímá klíčový prvek a to spotřeba na přenesený bit. Jasně je to nepodstatné, jak se to vezme, úspornou síťovkou lze uspořit více než zákazem žárovky ve špajzu.
Ve světě kde nikdo nepokutuje Microsoft za skoro každoměsíční 1GB aktualizací pro jejich skvělý OS a Office. jde na rozdílu mezi nejúspornější Gbit síťovkou a nejhorší Gbit síťovkou uspořit celosvětově řádově GWh.
Pokud mě paměť neklame jde najít síťovky které na přenos bitu spotřebují 20nJ ,ale i síťovky s 600nJ /bit o klidové spotřebě nehovoříc.
Každoměsíční 1 GB? A pak ses probudil a měl ruku v nočníku....
A vy jste asi spadl z Marsu, že.
no pokud by se hovořilo o WIN10 . tak je to 3Gb za týden x 5 mil. testerů
Hovořilo se obecně o sw Microsoftu a jen pro Win 7 Ultimate x64+Office 2013 x64 je poslední dobou zcela běžné, že ,především aktualizace offce, hodí 1GB , uživatelská základna je pak o několik řádu vyšší než je základna beta testerů Win X.
Win7/8 + Office 2013 opravdu dela ten 1GB+ aktualizaci kazdy mesic :-( .
Aniž bych vůči vám chtěl být hrubý, tak vás musím požádat, abyste držel hubu, jinak se toho nějaký zelený exot chytne a opravdu budeme lepit ty energetické štítky i na větráky v PC. Jak vás může jenom napadnout o takových věcech mluvit nahlas? ;-)
Hlavně by už konečně měli začít dávat na desky 10gbps síťovky. Nebo alespoň ty nové 2.5gbps, 5gbps (které by měly fungovat na stávajících kabelových rozvodech Cat5e, Cat6), až je schválí normovací výbor. Nakonec, už teď to mají ohlášené procesory přímo v sobě (10gbps).
Gigabit je vykopávka. Pomalu je to moc málo i pro lepší video (4-8K super hyper).
Nehledě na vysokou latenci, CSMA/CD a podobné zhůvěřilosti z dávnověku.
Jinak jedině Intel, s TOE a dalšími věcmi. Drivery jim fungují nejlépe pro všechny systémy.
Killer je dobrý pro hráče, protože má prioritizaci "herních" paketů přímo v sobě.
Ako sorry, ale zase musis za kazdu cenu byt cool ? Pokial nemas nastrkane sietove veci v hube resp. tam, kde existuje nejaka zdielana kolizna domena, moze ti byt cele CSMA/CD ukradnute.
Este by ma zaujimali tie dalsie veci z davnoveku...
Ten nezmysel so sirkou pasma pre video radsej nekomentujem.
Ad Killer - pokial sucasne neprenasas (presnejsie - nevysielas) 100vky Mbit/s v x-streamoch na gigabite pocas hrania, moze ti byt nejaka prioritizacia napr. UDP ukradnuta. I tak je ta pridana latencia radovo mensia, nez cela trasa k serveru.
Kůl nekůl, že něco neznáš, neznamená, že to neexistuje.
CSMA/CD vadí vždy, i když jedeš přes switch - prodlužuje to latenci, 1gbps je tím pádem zbytečně pomalý, projevuje se to ve všech aplikacích, kdy na latenci extrémně záleží - třeba při přenosu mnoha malých paketů, při synchronizaci procesů přes síť, vzdáleném volání procedur (RPC aplikacích, DCOM+, Corba, ...).
Věcmi z dávnověku myslím třeba to, že na 1gbps nejde pustit nic konvergovaně, například RDMA, FC, ...
A kolik myslíš, že má nekomprimované - nebo s bezestrátovou kompresí - profesionální video ? Nebo i se ztrátovou kompresí, H.264, H.265, ale s velmi vysokým rozlišením 4-8K při 120 fps.
Před pár lety jsem takovou věc psal pro doktory, pro dálkové řízení operačních robotů - a 1gbps nestačil, muselo se používat více linek.
Killer vznikl jako herní karta - hráči vědí proč to chtějí. Každá milisekunda se počítá. Že máš zrovna ty pomalé připojení s vysokou latencí neznamená, že to tak mají všichni.
Ty latence na gigabitu mě zajímají. Odhaduji, že mluvíte o mechanismu "carrier extension".
http://www.cs.wustl.edu/~jain/cis788-97/ftp/gigabit_ethernet/#CAR
http://www.cisco.com/web/about/ac123/ac147/ac174/ac199/about_cisco_ipj_a...
Chcete říct, že se uplatňuje i na lince ve full-duplexním režimu = při vypnuté detekci kolizí? Toto jsem nenašel nikde vysvětleno na plnou hubu. Nějaké historické materiály zmiňují možnost provozu 1000/half, ale prakticky jsem gigový hub nikdy neviděl, znám to víceméně jako konfigurovatelnou možnost na gigových portech. Někde se lze dočíst ke "carrier extension" vysvětlivku, že je to kvůli jakési zpětné kompatidebilitě s 802.3 sítěmi (minimální délka rámce v čase) - uniká mi k čemu, když na kolizní doméně se nemohou potkávat různě rychlé síťovky (nebo snad mohou?) a skrz switch je to snad jedno, protože z pomalé sítě na rychlou stejně musí switch provádět striktně "store and forward".
Minimální velikost rámce na gigabitu je nějaké 4 kbps (oproti 512b na 10/100), to by na gigabitu dávalo cca 4 mikrosekundy minimální dobu přenosu. Což ještě není zdaleka celá latence průchodu switchem při dnes typickém režimu store and forward. Kromě toho 4 mikrosekundy jsou fakt málo - při gamesení by se to poznalo snad na LANce s jediným opravdu rychlým switchem, jak správně píšete může to být vidět pro nějaké HPC apod., snad ani ne databázoviny, a nejlíp třeba skrz několik switchů v řadě. Trochu mi vrtá hlavou, jak se přesně chová switch ve vztahu k "frame bursting" = jestli čeká na další frame, nebo odešle rovnou, doplní na minimální délku a další frame musí počkat na doodvysílání "extension" bitů apod., jaké z toho plynou "dodatečné" efekty na latence apod. Ale pořád je to v jednotkách mikrosekund per hop...
Při vypnuté detekci kolizí se CSMA/CD samozřejmě neuplatňuje, ale že tam ta možnost je, omezuje minimální velikost paketů - protože na sdíleném médiu by přenos malých paketů byl velmi neefektivní, po každém vyslaném paketu musí následovat náhodné zpoždění. Standard 1000BaseT byl tak kvůli kompatibilitě s 10/100 postižen většími latencemi než by bylo nutné, kdyby ta zpětná kompatibilita nebyla.
10G už tyto problémy nemá, protože si na CSMA/CD už nehraje. Latenci má asi 8x menší.
Je to samozřejmě hodně znát u moderních distribuovaných věcí a všude, kde se používají malé pakety, nejen v oblasti HPC.
Je to tam imho napisane dost jednoznacne:"For traditional Ethernet hub operation, in which only one station can transmit at a time (half-duplex), the basic CSMA/CD scheme has two enhancements" a
"With a LAN switch (full-duplex operation), which provides dedicated rather than shared access to the medium, the carrier extension and frame bursting features are not needed. They are unnecessary because data transmission and reception at a station can occur simultaneously without interference and with no contention for a shared medium. All the gigabit products on the market use a switching technique, and so do not implement the carrier extension and frame bursting."
Ani na to nejdem reagovat, motas nesuvisiace veci. Gbit ethernet je Xrokov stara technologia, nechapem, aky ma vyznam nariekat nad vecami, co su tam hlavne kvoli kompatibilite, realne nemaju vplyv na 99.99% instalacii.
Tym, ze spominas konvergovane adaptery v spojitosti s touto starou technologiou si ma akurat utvrdil, ze netusis, kolka bije a co si vyzaduje korektna podpora napr. FC.
A potom by si zase mal problem, ze FC je prilis pomale, cez ten 1 Gbit, to je mi uplne jasne.
Mimochodom si nenapadne odbocil od domacich kablovych rozvodov a hw, co nema 10Gbit onboard, k enterprise rieseniam a pouzivas argument, ze tam Gbit nestaci.
Pre mna za mna si doma kludne implementuj Unified Fabric ale netlac tu do ludi nezmysly, resp. FUD.
Ano, mam pomale pripojenie, zrejme sa budem na tu optiku 100/100 stazovat.
No pre bezneho domaceho uzivatela je to fakt asi jedno. Malo kto ma doma poskytovatela ktory dava 1GBit routre (myslene z hladiska rozhrania). Vecsinou co sa dodava ma max 100Mbit porty. A zasa ak uz niekto ma doma natahanu Gbit siet, tak asi vie co chce a vie si to aj poriesit.
Já mám od UPC Cisco s 1Gb ... i když mám jen 50Mb, ale nabízejí mi 130 ... (na co ?) . Víc než toto mě srdí, že běžné switche jsou ty 100Mb a za 8x1Gb zaplatím 2-3x víc než za ty 100Mb. Za ty roky by už 100Mb switch měl být vykopávkou. A o routerech ani nemluvím. Měl jsem TP-Link R600VPN V1.1 s vynikající propustností, ale odešel a tak jsem jej nahradil obyč. routerem s WiFi a je to "děs" . Latence se zhoršila o 10-15ms takže v on-linovkach mám z 20-22ms skoro 40ms. Na běžné hraní žádný rozdíl, ale je jasné, že dobrý router hráčúm nic neskazí :-).
Jinak na domácí použití považuji volbu síťovky jen za problém s ovladači. Jiné to je pro průmyslové nasazení, kde teaming je nevyhnutný (fault tolenace nebo load balancing). A tady preferuji Intel pro desktopy, pro servery je to také většinou brandovaný Intel .
Běžný domácí uživatel řeší dostupnost a rychlost domácí LAN, na které má NAS.. Gigabit na internet je nesmysl.
Jeste by si konecne mohli vytvorit nejaky modernejsi web stranky, to co tam maj ted, je uz asi od 90tych let.
Len to nie, potom tu bude mega super moderna stranka s milionom js, ktora bude neskutocne pomala. Kde kym sa preklikam ku konktretnemu ovladacu tak pridem o nervy.
Podla mna by support stranky mali byt len uplne jednoduche, a nie plna animacii a x-krat zadavat model.
Souhlasim. Zastaraly vzhled preziju, hlavne at to nezrasi.
Obecně nemám rád, když se pod jedním názvem produktu ukrývá X různých navzájem nekompatibilních čipů a když je pro provoz potřeba firmware z balíku firmware-linux-nonfree. Škraloup tedy mají u mě prakticky všichni výrobci, nejvíc neblahé vzopomínky mám na intel PRO/100 a e1000, u kterých člověk nikdy nevěděl, co dostane a jestli to pojede. Možná už se to zlepšilo, ale pokud je v konfiguraci serveru "(dual) Intel gigabit ethernet adapter", vždycky mírně znejistím. Takové "Realtek 8111" ve mě působí mírně vyšší jistotu, že to pojede.
preto už pozerám na čipsety a nie názov karty. rovnako ako vás ma štvalo, že 2 karty s rovnakým názvom používali rozdielne ovládače - e1000e, igb. mimochodom igb je konečne ovládač, ktorý je pre mňa 100% bezproblémový.
Huh, s e1000 jsem si také užil svoje. Stejně označené čipy, integrované na deskách, měly mnoho různých variant, byla to katastrofa.
Já to vnímám spíš tak, že v těchto slavných "rodinách" (e1000, e1000e, rtl8168) dochází v průběhu let trvale k určitému vývoji, přibývají nové modely čipů, a přestože změny mezi generacemi jsou obvykle nevelké, člověk prostě nemá čas hlídat, jestli má na boardu tentokrát i82573L nebo i82579, takže občas dojede na to, že jeho léty prověřený kernel najednou nezná PCI IDčka pro novou generaci síťových čipů... stalo se mi to konkrétně u Intelu i u Realteku. Že je to Intelka na PCI-e ještě neznamená, že to bude podporovat e1000e z doby před čtyřmi lety :-( Ony těm čipům reálně přibývají fičury a mění se drobnosti uvnitř... Evoluce je peklo. Po dvaceti letech je z toho člověk už trochu unavenej, někteří to vzdají a jdou radši šéfovat nebo prodávat - klobouk dolů před lidmi, kteří chtějí dál dělat "vlastníma rukama".
To uz nemozeme hadzat na Intel, ked si ludia nevyberu spravny adapter, ci nepreveria kompatibilitu :)
Nie je nic jednoduchsie, ako si pred kupou pozriet tabulku PHY na Intel site, maju to tam pekne popisane.
http://www.intel.com/content/dam/www/public/us/en/documents/brochures/in... a k tomu aspon nahliadnut do dokumentacie drivera.
Ale inak suhlasim, tych verzii je vela, ale je to "dan" za dobu, co je Intel na trhu a sirku ponuky.
Tak tak - to není nectnost konkrétního výrobce, to je zákonitost paralelního vývoje SW a HW :-)
Díky za ten seznam, tenhle jsem neznal... 40Gb Ethernet od Intelu :-) Ten čas letí...
Jinak podpora v driverech se týká spíš MAC než PHY (PCI rozhraní = IDčka nese MAC čip), a mým oblíbeným způsobem jak zjistit podporu v Linuxovém kernelu je mrknout do zdrojáku ovladače (dokumentace bývá pozadu a neúplná). Skrz git.kernel.org je to rychlejší než tahat a rozbalovat tarball, a zároveň se dá mrknout do changelogu pro konkrétní Cčkový zdroják, často je tam vidět, kdy přibyla podpora pro konkrétní generaci hardwaru (u věkovitých rodin čipů). Zjistit podporu v konkrétním distru znamená stáhnout zdrojáky dané verze kernelu (nebo najít distribuční GITové repo).
ID cko sa sice lahko "hackuje" do zdrojakov, ale kolkokrat ide aj o inu funkcionalitu. Ale skusit to treba.
Chvalabohu, Linux s tym uz problem nemava. Zato FBSD ... :)
Spomenul som dokumentaciu, lebo som chcel uviest zakladny postup pre standardneho uzivatela.
Samozrejme, ze grep -F -r "XXXX:YYYY" je rychlejsie. Na Git som prilis pohodlny asi :)
Ano, 40Gbit - je to neuveritelne. Intel je TOP nielen v procesoroch a to tu ide hlavne i ficury tych kariet, co su schopni implementovat, ani tak nie o rychlost.
Inak prave pred chvilou som dokoncil velky upgrade Cisco UCS blade platformy, tam je buducnost sietovych a storage datacentrovych technologii. Nie, ze sa tu natahujeme o 20rocnych technologiach :)
to moze len amater vyhlasit ze 99% uzivatelov nepozna rozdiel medzi integrovanou a dedikovanou zvukovkou...alebo clovek ktory nikdy nepocul zvuk z externej zvukovky
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.