na úgy döntöttem nem szívatom tovább magam mindenféle lommal a céges szerverben, és inkább veszek magamtól bele egy rendes hálókártyát. sajnos ilyesmi erre felénk ritka madár, épphogy találtam árlistn egy intel pro/1000 pt-t és egy gt-t (ami még nem jelenti azt, hogy vannak is...) komolyabbat nem akarok, mivel saját pénzből lesz...
a kérdésem az, hogy ilyen pt-s, pci expresses kártyát "régebbi" kernellel (2.6.20-17), ubuntu 7.04 32bit alatt használt-e már valaki, mennyire megbízható a kártya? kicsit félek a pci-e miatt...
a másik meg az, hogy a gt-ről nem derül ki, hogy pontosan milyen fajta, de mintha ebből csak pci-x verzió lenne és egy vagy több portos is. nincs esetleg pci-os gt? vagy egyéb pci-os gigabit az intelnek van, ami jó?
- 4016 megtekintés
Hozzászólások
Hello!
Használok ilyet (mármint PT-t és GT-t is), Debian Etch 2.6.18 alatt az e1000 modul tökéletesen viszi mindkettőt.
Amúgy a típusszámozás:
Intel Pro/1000 GT = 1 portos gigabit desktop adapter, PCI
Intel Pro/1000 PT = 1 portos gigabit desktop adapter, PCI-Express 1x
a teljes választék pedig itt: http://www.intel.com/network/connectivity/products/server_adapters.htm
Petya
- A hozzászóláshoz be kell jelentkezni
na igen, ezt én is néztem, de a linken nincs olyan, hogy gt és sima pci-os, csak pci-x-es
közben kérdeztem a boltot is, természetesen nincsen nekik (akkor minek rakják árlistára?!), csak rendelésre, és a csávó szerint is van 1000gt sima pci-osban... viszont pci-e -s pt-t nem tud szerezni sem.
akkor most kinek higyjek?
illetve lenne még egy ilyen: planet enw-9700, ez valamilyen marvell yukon chipes, pci-e cucc, elég olcsó és marvell is, tehát félek tőle... erről infó esetleg?
- A hozzászóláshoz be kell jelentkezni
Yukon kártyát használtam már szerverben. A tapasztalatom a következő:
88E8001, ez egy PCI32-es vezérlő, ehhez van elég jó stabil driver a kernelben, úgy hívják, hogy skge (SysKonnect Gigabit Ethernet, ezt vette meg ugyanis a marvell). A kártya teljesítménye amúgy csapnivaló, kb. 560 mbit/s-re tudja kihajtani. Összehasonlítás képpen egy Intel PCI32-es E1000-es kártya kb 860 mbit/s-et tudott ugyanabban a gépben ugyanazon a pci buszon.
88E8056, ez PCIe-s, ehhez elvileg van 'stabil' driver, úgy hívják, hogy sky2 (SysKonnect Yukon II.). Ezt a stabilt tényleg idézőjelben kell érteni, mert minden csak nem az. Legalábbis az RHEL5 2.6.18-as kernelében még nagyon bugos volt, folyamatosan szemetelte tele a kernel logot ilyen hibaüzentekkel:
sky2 eth2: rx error, status 0x7ffc0001 length 1148 és ennek hatása teljesítményben is érezhető volt. Újabb kernellel (talán 2.6.24-es volt) a hibák száma jelentősen csökkent, a kernel logba már nem szemetel egyáltalán, de az ifconfig statisztikában azért látható, hogy az RX errorok száma nem nulla, maxra terhelés esetén másodpercenként kb 1 errorral emelkedik. Teljesítményben ennek a hatása már nem mutatható ki, asszem 910 mbit/s volt a max, amit ezzel mértem, tehát az elvi maximumot amennyire csak lehet megközelíti.
Gyanús, hogy az újabb kernel mellett jelentkező hibákról már nem a driver tehet, hanem a vas lehet gyenge, a driver forrásban legalábbis vannak utalások a kis on-chip pufferek miatti workaroundokra. De régebbi driverrel jobb, ha nem próbálkozol, mert szívni fogsz vele.
Amúgy egyik kártya sem tud jumbo frame-eket, meg semmi extrát, szóval éles, nagy terhelést vivő környezetben szerintem nem érdemes kisérletezni velük.
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
Centos 5.0-t telepítve beállítottam a hálókártyákat. P5BV-C Asus alaplap 2 db Marvell 88E8056-al. Majd yum update -el frissítettem 5.2-re és utána nem látja a hálókártyákat.
Guglizva a következő megoldásra leltem:
# modprobe sky2
# echo "11ab 4364" > /sys/bus/pci/drivers/sky2/new_id
így most megy, de éles környezetben ez megoldás?
jobb, időtállóbb nincs? Hogyan tovább?
- A hozzászóláshoz be kell jelentkezni
de a linken nincs olyan, hogy gt és sima pci-os, csak pci-x-es
az legyen neked mindegy. ha fizikailag el fog férni a kártya (ha pci-x-es, akkor jó esélyed van rá, hogy 64bites, márpedig egyes gépekben képesek úgy berakni a 32bites slotot, hogy a 64bites kártya extra csatlakozója nem fér el), akkor 99.99%, hogy menni is fog.
- A hozzászóláshoz be kell jelentkezni
De most gigabites hálókártyát milyen megfontolásból akarnál sima pci foglalatba dugni?
Nem baj, hogy közel sem fog gigabitet kipréselni magából, mert a pci bus szűk keresztmetszet?
Ha van a szerveredbe PCI-X akkor legyen az (szerintem a gt ilyen egyébként, szerver körökben ezt híják pci -nek), ha nincs, akkor pedig PCIe
- A hozzászóláshoz be kell jelentkezni
ez a "szerver" gyakorlatilag egy sima mezei pc. nem a pci a szűk keresztmetszet, hanem a vinyó. amúgy nem "sima" pci, hanem 66mhz-es, azon azért már nem okvetlen a pci a szűk keresztmetszet.
jelenleg ftp-vel ~40Mb/s-t tudok hozni, sambával meg ~25-öt, és ez messze van a vinyó sebességétől is meg a pci sebességétől is, mert egyszerűen ilyen szar a kártyák drivere.
ha egy "rendes" gigabites kártáyval elérem a 40mb/s-t sambával (mint otthon is, pedig az csak egy rtl8169c), akkor már tapsikolni fogok, több ide nem kell. úgyhogy felőlem lehet pci (nem pci-x!) vagy pci-e, nem érdekel, csak legyen stabil.
- A hozzászóláshoz be kell jelentkezni
Sima pc-ben hogy hajtod ki 66MHz-re? Szerintem az csak 33MHz-en megy, bár tény, hogy a gigabites hálókártyák többsége tud 66MHz-en menni, ha olyan alaplapba kerül.
A samba teljesítményével meg az a bökkenő, hogy az egész smb protokoll nagyon latency érzékeny, vagyis nem szabad csodákra számítani. Az elvileg elérhető sávszélességet tudod javítani azzal, hogy jobb kártyát és jobb buszt raksz alá, de a latency nem fog lényegesen javulni, csak akkor, ha jó switchet használsz, illetve ha eleve kiveszed a switchet és csak crossover kábellel nyomod. Gondolom az utóbbi nem igazán opció nálad.
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
hát én nem tudom, de ez 66mhz-en megy a bios szerintmeg még mintha a dmesg-ben is ez lenne de erre már nem veszek mérget. de ha nekem a 33mhz-es sávszélességet hozná úgy-ahogy valami, már annak is tudnék nagyon örülni, mert jelenleg 400mbit-et súrolom épphogy, az meg azért sovány. ha már a pci busz lenne a szűk keresztmetszet, az már haladás lenne :)
tudom, hogy a samba lassú(bb mint pl ftp), ilyen latency-t nem tudom, hogy érted, ezekhez nem értek... viszont otthon egy nf2-es alplapban egy sempron2300-as (socketa) lappal és ddr rammal és 1 szem ide vinyóval simán tudom hozni a vinyó sebességét gigabiten, switchen keresztül, mindezt egy noname reltek 8169c-vel. sambával meg 40mb/s, amit én már jónak tartanék a céges szservernél is.
- A hozzászóláshoz be kell jelentkezni
A céges szerver az milyen alaplap? Mintha feljebb azt modtad volna, hogy sima pc az is. 66mhz-es vagy annál gyorsabb PCI csak drága szerver vagy munkaállomás alaplapokon van.
ilyen latency-t nem tudom, hogy érted, ezekhez nem értek...
Két baj van vele, ennek főleg történelmi okai vannak.
Eredetileg az SMB és Netbios protokollokat nemcsak TCP/IP felett használták, hanem IPX/SPX meg NetBeui felett is. Emiatt eléggé úgy működik, mintha csak egy datagram szolgáltatásra lenne ráépítve, csomagkezelést feltételez, de nem tételezi fel, hogy az alatta lévő protokollstack hosszú adatfolyamokat is értelmesen tud kezelni. Bele lett építve valami saját adatfolyam szegmentáló és forgalomszabályozó algoritmus. Ez teljesen jó volt, amíg netbeui-val nyers ethernet keretek felett ment. Csakhogy a TCP saját maga is tartalmaz forgalomszabályozást és a két algoritmus nagyon szerencsétlenül keresztbe tudja szivatni egymást. Emiatt elég feketemágia tuningolni az oprendszer TCP stacket és a sambát jó teljesítményre, emiatt van egy rahedli teljesítménybeállító opciója a sambának.
A másik baj, hogy 10mbit-es hálózatok voltak, amikor az SMB-t kitalálták. Egy gigabites hálózat esetén a jel ugyanolyan gyorsan terjed a vezetékben, mint a 10mbit-es esetén, viszont az adatáteresztő képessége 100 szoros. A jelterjedési idő, amit eleinte el lehetett hanyagolni, most egyre inkább problémát okoz. Egy forgalomszabályozó algoritmus ami jó 10mbit-re, biztos hogy ugyanazokkal a beállításokkal nem működik jól 1000mbit-en.
Első körben én azt mondanám, hogy kicsit próbálj játszogatni a samba beállításaival és a linux tcp paramétereivel. Olvass el 1-2 howto-t hozzá, akkor talán tisztább lesz a kép. De arra ne számíts, hogy ugyanolyan gyors lesz, mint az ftp, ami gyakorlatilag 1 tcp adatfolyamon nyomja keresztül a fájlt, minden egyéb körítés nélkül.
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
bocs az előző hozzászólást erre akartam válaszul, de félrenyomhattam.
mindenesetre köszönöm a felvilágosítást! :) majd utánaolvasgatok, hátha meg is értem egyszer a dolgot! :)
már számtalan samba és tcp stack howto-t elolvastam, viszont ezek is tök ellentmondásosak sokszor, úgyhogy maradt a howto-k alapján a próbálkozásos módszer.
tapasztalatom szerint a samba beállításai nem túl sokat számítanak sebességben. hasonlóképpen, jumbo frame-mel sem értem el semmi gyakorlati eredményt (na jó, talán egy picit, ezért úgy hagytam, 4k-s frame-mel megy most a háló). viszont a tcp beállítások sokat számítottak, csak éppen nem jöttem rá, mik az összefüggések. így most egy "véletlenül" kikísérletezett beállítást használok, amivel igen jól megy a rendszer. már legalábbis otthon, de a cégnél az istennek nem akarja az igazat. ezért gondoltam, hogy itt már akkor hálókártya driver a gond vagy akár maga a kártya, és ezért akarok valami jót. példul nem szimpatikus, hogy tegnap 1 óra alatt szép csendben 24 megát loggolt a cucc a syslogba, "kernel assertion" meg ilyenek... ma ugyanez, csak most már figyeltem, és 3 mega loggolás után "rajtakaptam"... nem bírja a fiú a nagy terhelést, na! :)
egy szó, mint száz, majd újítok egy pci-e-s 1000pt-t és megnézzük az megoldja-e a nyűgömet!
- A hozzászóláshoz be kell jelentkezni
viszont ezek is tök ellentmondásosak sokszor, úgyhogy maradt a howto-k alapján a próbálkozásos módszer.
Na ettől "feketemágia" a dolog. :)
hasonlóképpen, jumbo frame-mel sem értem el semmi gyakorlati eredményt
Talán mert lehet, hogy valójában nem is működik. Én pl jártam úgy, hogy egy switchről tudtam, hogy a jumbo frame-ek nem mennek át rajta. Több hálókártya közül csak az intel e1000-es esetén állt meg a forgalom a jumbo frame-ek bekapcsolásakor, a többi fajtával vígan ment tovább. Vajon miért?!
példul nem szimpatikus, hogy tegnap 1 óra alatt szép csendben 24 megát loggolt a cucc a syslogba
No igen, hát ha csomagvesztés van az ótvar hálókártya vas/driver miatt, akkor semmi csoda nem segít, mert a TCP windowing minden elvesztett csomagnál vissza fogja léptetni a sebességet. A folyamatos logba írás overheadje sem fogja elősegíteni a gyors működést.
---
Linux is bad juju.
- A hozzászóláshoz be kell jelentkezni
hát a jumbo frame elvileg működik, legalábbis pinggel tesztelve, 4k-ig nem fragmentál...
csomagvesztés az nincs, csak ilyen krenel assertion. de az is úgy, hogy simán meg egész nap, aztán egy erősebb terhelésnél bekattan és elkezdi fosni ki a logba ezt a hibát, de ettől még nincs csomagvesztés meg semmi, a hálózat továbbra is ugyanúgy meg...
mindenesetre most raktam be egy 1000pt-t, pci-e -st... :)
mondjuk eddig nem estem hanyatt, picit jobb csak. de ez már akkor lehet, hogy a másik oldali csatolón múlik akkor.
még a jumbo frame-nek nem olvastam utána intelnél, egyenlőre 4k-n hagytam (egy az egyben az előző kártya beállításaival megy minden, csak iftabban átírtam a mac címet és kész.)
de gondolom a 4k-t csak tudja már egy ilyen kártya?
mindenesetre most elkezdem nyúzni szegényt :)
- A hozzászóláshoz be kell jelentkezni
én úgy tudom, a pci2.2 az tud 66mhz-et de csak 32 bites, a pci-x meg tud 66mhz-et és 64bites, ez van szerver lapokon.
ez csak egy sima gigabyte lap, valamilyen nforce chipsettel, most meg nem omndom milyennel.
- A hozzászóláshoz be kell jelentkezni
Azert a sima PCI-os gigas halokartyabol is ki lehet hozni 20GB/s felett, ami azert erezhetoen tobb, mint amit egy 100-as kartya tud.
- A hozzászóláshoz be kell jelentkezni
"a sima PCI-os gigas halokartyabol is ki lehet hozni 20GB/s felett" ???
Ez gondolom 20 MB/s akart lenni.
Azért aba is érdemes belegondolni, hogy a pci buszt nem csak a hálókártya fogja használni...
Szvsz esélytelen, hogy Samba-val elérd a 40MB/s -t pci hálókártyával.
Nekem van egy kis "szerverem", RAID 5-ben vannak a lemezek benne, próbaképp kipróbáltam egyszer egy pci -os Linksys kártyával, és olyan 13-22 MB/s között ingadozott a SAmba sebessége.
Az integrált valamilyen alaplapi Intel chippel ki tudok tolni a SAmba-n 80-90 MB/s-t, ami gyakorlatilag a gigabites lan felső határa.
Op. rendszer Ubuntu.
- A hozzászóláshoz be kell jelentkezni
:-) MB/s
de 10MB/s -hez kepest a 20MB/s is 100% tobblet, szoval azert akar lehet is ertelme a sima PCI-os gigas kartyanak is, ha nincs jobb megoldas, csak ezt akartam irni, ennyit meg ki lehet hozni egy destktop intel gigas kartyabol is gond nelkul
- A hozzászóláshoz be kell jelentkezni
"Szvsz esélytelen, hogy Samba-val elérd a 40MB/s -t pci hálókártyával."
simán. lásd fentebb.
- A hozzászóláshoz be kell jelentkezni
van egy eladó vadi új pro 1000 GT-m, ha érdekel valakit...
- A hozzászóláshoz be kell jelentkezni
nekem is van pár eladó low-profile 1000 pt-m eladósorban.
-------------------------------------------------------------------------------
Az életben csak egy dolog a szép, de az épp nem jut eszembe.
Slackware Linux 12.1 | 2.6.26.7-janos
- A hozzászóláshoz be kell jelentkezni
oké, megvan az pci-e-s pt verzió, be is raktam a gépbe, megy is.
viszont a teljes hálózat 4k jumbo frame-re lett állítva az előző kártyával és most nincs kedvem visszaállítani mindent 1500-ra... egyszerűbb nekem, ha a szervert állítom csak át 4k-ra. az e1000 modullal viszont nem tud jumbo frame-et a kártya úgy látom.
leszedtem egy 2008 márciusi drivert az inteltől, be is forgattam az e1000e modult, az már tudja a jumbo frame-et és direkt pci-e hez van a driver.
valakinek van ezzel tapasztalata? stabil, gyors, stb?
- A hozzászóláshoz be kell jelentkezni
Ennek a kártyának nagyon gyorsnak kéne lennie, alapbeállításokkal is.
Írd már le légyszi a "szerver" főbb komponenseit, konfigurációit, különös tekintettel az alaplapra, alaplapi chipkészletre, merevlemezekre, azok csatlakozási módjára, raid beállításokra, fájlrendszerre!
Pl. xfs és raid esetén külön fel kell paraméterezni az mkxfs -t, hogy a meta-adait úgy rendezgesse, hogy elosztva kerüljenek a merevlemezre...
- A hozzászóláshoz be kell jelentkezni