Gigabit ethernet: 2000Mbps full duplex

Hálózatok általános

Elméletileg 250 MB adatmennyiséget lehet továbbítani rajta másodpercenként. Gyakorlatilag mennyit?

Vagy esetleg van olyan, hogy két kábelen menjenek az adatok, megduplázva az adatmennyiséget?

  • 3077 megtekintés

( elod v | 2008. 01. 02., sze – 00:25 )

Mióta 2GB az 1GB? Tx 1GB és RX 1GB. Egy irányba 1GB-nál többet nem tudsz vinni. Tx egy pár drót, Rx másik pár drót (1000base-Tx). Nincs mit, és nincs hogy duplázni a drótokon. Csak egy hálózatikártyád van.

Írtam is egy másik témában (tárolótömb), hogy én is kíváncsi voltam, hogy mennyi is az az annyi. Két marvell kártya közt (alaplapi, tehát nem pci-33-as kártya), crossoveren, mindkettőn live cd-ről indítva (egyik Suse 10.3, a másik valami 5-ös Knoppix volt). Azt hiszem a Knoppix-on volt egy jó nagy ramdiszk, oda pakoltam az adatokat (tehát memóriából memóriába történt a másolás, netcat-el, tcp-n). Az eredmény nem lőtte túl az 50MB-ot. Ha a lemez is beszámított, kicsit több volt mint 30MB (most már nem tudom biztosan, mert nem jegyeztem le, de lehet, hogy egyik gépben a Barracuda V-ösre másoltam).

Érdekes, hogy UDP-n nem volt hajlandó másolni a netcat, illetve nagyon lassú volt.

Ki fogom próbálni a napokban két másik géppel is. Nektek milyen eredményeitek vannak gigabittel?

( csardij v | 2008. 01. 02., sze – 09:13 )

ha van a szvics támogatja a 308.3ad-t, akkor osszefoghatsz tobb linket, amik virtuálisan egyek lesznek. (annyit amenynit a szvics támogat, egy kozepkategorias 3com pl 2-t tud, igaz, ezeke ugyis csak két giga port van)

Én is igy használom, megy faszán.

tesztek szerint ki is hozza a 2*2*2 gigát (full duplex ugye), igaz, izzott a szvics. (ugy teszteltem, hogy csináltam egy jóó nagy fájlt (60 gigásat) és azt torrenten szétlőttem a belső hálon, igy jol meg lehet fingatni a hálozatot, tesztnek sem utolso)

igaz, rendes szerver, integrált intel gigalannal.

Köszönöm!!! Valami ilyesmit vártam :) örülök, hogy működik a gyakorlatban is :)
Már csak az a kérdés, hogy milyen kártyát és svicset vegyek. Bár igazából nincs is szükség szvicsre se, elég a közvetlen kapcsolat két gép között.

Kártyából pl. ez megfelelne? 80-150 MB/s adatátvitelt szeretnék elérni.

"amin van 8 gigás port (gerincnek), "

kétlem, hogy erre szüksége lenne a kérdezőnek, link aggregate-hez pedig biztosan nem kell.

Mindenesetre én erre gondoltam: http://www.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=U…

Ez 96 gbps-es belül, tehát ez is viszi minden portján egyszerre is a gbit-et.

( Imo | 2008. 01. 02., sze – 09:20 )

A 2 kártya/kábel dolog létezik, úgy hivják hogy link aggregation és nem csak 2-vel működik, hanem akárhánnyal, viszont fontos, hogy ugyanolyan kártyák legyenek. Alapesetben a link aggregation mikor driver szinten van megoldva, akkor úgy működik, hogy csak az aggregált géptől kifelé menő forgalom sávszélességge növekszik, azaz két gép felé tud mondjuk file-t küldeni 1-1 gbps-el, a befelé jövő forgalom beesik mindkét hálókártyára, mert a switch nem tudja eldönteni melyik portján is figyel az adott MAC address. Ha komolyabb switch-ed van (én linksys sw2048-al használok ilyet) akkor un. switch assisted link aggreation-t is tudsz csinálni, ilyenkor a switchen port szinten tudod definiálni, hogy hova van kötve a LA-es hálókártya igy a bejövő forgalom se esik be minden hálókártyára, hanem round robinnal szétosztva.

1 kártyával/kábellel nekem is 50mb környékét sikerült elérjek wines gépek között, ill az egész fenti történetet én winen használom, de nyilván megy akármin, ha van driver támogatása.

akkor próbáld ki egy LA-t nem tudó switchel és meglátod :)
Nem kell itt túl nagy technikai mélységekbe lemenni, elég ha arra gondolsz, hogy a switch arp táblájába mindkét portján bekerül ugyanaz az IP, ezt azzal hálálja meg, hogy mindkét portjára kiküldi a forgalmat, mivel fogalma sincs melyik éppen a nyerő. Visszafelé nincs gond, mert ott a driver elintézi, hogy melyik kártyán menjen ki, ezért növekszik kifelé a sávszél LA-s switch nélkül is. A round robin is itt állitható, semmi szükség source/dest mac address alapján osztani a forgalmat, ha akarod ugyanannak a hostnak is kimehet két egymáutáni packet más-más porton, itt csak arra kell figyelni, hogy megborulhat a packet beérkezési sorrendje, ami gondot okozhat bizonyos protokolloknál.

van fogalmad arrol mekkora hulyesegeket beszelsz amugy ?

1) a MAC tablaba nem kerul semmifele IP, szerintem arra gondolsz, mert ARP tabla egy L2 switchen nehezen van (max. a managementhez)
2) lehet, hogy van olyan "switch", ami mindket portra kikuldi a forgalmat (en meg nem lattam), de az biztos, hogy nem olyan minosegu, hogy azon olyan forgalmat szeretnel bonyolitanu, ami igenyli a trunkinget. A legvaloszinubb, hogy mindig azon a porton fogja kikuldeni a csomagot, amin legutoljara vett az adott MAC addresstol, es az is konnyen elkepzelheto, hogy a teljesitmenynek nem fog jot tenni, ha packetonkent valtozik a MAC tabla. De barmilyen egyeb problema elkepzelheto, NEM normalis mukodes az, hogy tobb porton jelentkezik ugyanaz a MAC address (kiveve ha STP - de az most nem ide tartozik), ha a switch nem tud trunkinget
3) ha L2 szinten felcserelod a packetek sorrendje, az nem "bizonyos protokolloknal" okozhat problemakat, hanem konkretan mindig, ezert a round-robin felejtos - azaz nem felejtos, de a switchben megvalositani egy ilyen utemezest bonyolultabb, mint amennyit az egesz er. Viszont valahogy szet kell osztani a forgalmat, ezert kivalaszthato, hogy milyen algoritmus alapjan tortenjen. Pl.:
van egy halozat, ahol egy adott trunkon kapcsolodo szerver a forgalma 99% -at egy adott gateway-en keresztul bonyolitja (tipikus eset pl. szerver kozpontokban). Itt a switchen a szerver fele source IP alapjan torteno hash-elest kell beallitani, mivel a dest. IP, source es dest. MAC is ugyanaz. Ha a gateway is trunk-olt kapcsolaton van, afele destination IP alapjan celszeru. De ha pl. LAN-on belul kommunikalnak jellemzoen akkor source/dest MAC address alapjan tokeletesen megfelelo. Igy egy adott IP kapcsolat csomagjai garantaltan megfelelo sorrendben maradnak, megis lesz terheles megosztas.

hülyeségek... lássuk:

1. " ARP tabla egy L2 switchen nehezen van (max. a managementhez)"

tudsz mutatni nem menedzselt LA-t tudó switche-t? Mindben van, de a konkrét esetben MAC táblára gondoltam

2. "NEM normalis mukodes az, hogy tobb porton jelentkezik ugyanaz a MAC address "

LA-nál teljesen normális működés, ha nem támogatja a switch. Persze te biztos jobban tudod, majd ha van időd hivd fel mondjuk HP-t, hogy tiltsák már le a nem switch assisted LA-t a driverükben, merthogy ez ott külön feature és bizony ugyanaz a mac mindkét kártyán és meg is duplázza kifelé a sávszélt LA-t nem tudó switchen. (LA-t tudó switch esetén külön be lehet állitani, hogy úgy működjön)

3. "ezert a round-robin felejtos"

szintén javasolnám a körülnézést a létező eszközökön, mert bizony a round-robin választható funkció és vicces módon pontosan ezt irja mellé a help, hogy bizonyos esetekben gondot okozhat a packet order.

" ha L2 szinten felcserelod a packetek sorrendje, az nem "bizonyos protokolloknal" okozhat problemakat, hanem konkretan mindig"

ez a nap vicce :))
TCP-ről hallottál már? Tudod mire jó a sequence number és miért kell buffer az implementációhoz? Ehh...

"De ha pl. LAN-on belul kommunikalnak jellemzoen akkor source/dest MAC address alapjan tokeletesen megfelelo. "

szintén csak telefonálást tudok javasolni, megint jobban tudod mint az eszközgyártók, ezzel én nem tudok vitatkozni, de azért jó lenne, ha majd egyszer élesben is látnál link aggregate-et :))

"tudsz mutatni nem menedzselt LA-t tudó switche-t? Mindben van, de a konkrét esetben MAC táblára gondoltam"

Akkor miert irtal ARP tablat es IP cimet?

"LA-nál teljesen normális működés, ha nem támogatja a switch. Persze te biztos jobban tudod, majd ha van időd hivd fel mondjuk HP-t, hogy tiltsák már le a nem switch assisted LA-t a driverükben, merthogy ez ott külön feature és bizony ugyanaz a mac mindkét kártyán és meg is duplázza kifelé a sávszélt LA-t"

"Every team member with the highest speed in the team transmits (using its unique hardware address) while the
current primary member receives. If the "receiving" member fails, another member takes over the MAC address of the failed receiving member in order not to confuse the switch."

"szintén javasolnám a körülnézést a létező eszközökön, mert bizony a round-robin választható funkció és vicces módon pontosan ezt irja mellé a help, hogy bizonyos esetekben gondot okozhat a packet order."

Az, hogy van olyan eszkoz vagy szoftver, amin ilyet be lehet allitani, nem jelenti azt, hogy erdemes.

"TCP-ről hallottál már? Tudod mire jó a sequence number és miért kell buffer az implementációhoz? Ehh..."

Van egy rakas dolog, nevezhetjuk akar kiegeszitesnek (sack, delayed ack, slowstart stb) amik megbonyolitjak a helyzetet. Tobbek kozott lehetove teszik, hogy N megabittel toltsel le TCP-n monjduk a youtube-rol akkor is, ha a savszelesseg ugyan rendelkezesre all, de a kesleltetes olyan nagy, hogy amugy soha nem jonne at TCP-n olyan sebesseggel. Ha kozvetlenul egy ilyen, nagy forgalmu szerver elotti switchben osszekevered a packetok sorrendjet (mondjuk egy round-robin policy-s trunkkel, amit ciscoban amugy meg nem lattam, van egyaltalan benne ilyen?), akkor pont ezek az.. optimalizaciok fognak eloszor megbolondulni. Nyilvan ez sem tunt fel, amikor a (lasd foljebb) 100 ezer Ft-os, 96gbit/sec sebessegu (lol) switchedre rakototted a nyilvan terabites forgalmat generalo szerverparkodat.

"Akkor miert irtal ARP tablat es IP cimet?"

Talán mert elírtam? De te ahelyett, hogy simán kijavitottad volna, lökted itt nagy pofával a hülyeséget. Szánalom.

"Every team member with the highest speed in the team transmits (using its unique hardware address) while the
current primary member receives. "

Hát ez a gyakorlatban nem igy működik switch és gép között, ugyanis a kliens hanyattdobná magát, ha két mac address-t kapna ugyanarra az ip-re (fogadó és küldő oldal). Ugyanis ezt hivják IP ütközésnek. Talán switchek között mehet ez igy.

"Az, hogy van olyan eszkoz vagy szoftver, amin ilyet be lehet allitani, nem jelenti azt, hogy erdemes."

ja, hogy most már csak nem érdemes? Hát azt talán majd a KONKRÉT KÖRNYEZET KONKRÉT FORGALMA alapján el lehet dönteni, hogy jó-e vagy sem. De még szerencse, hogy semmilyen erre vonatkozó információ nem hangzott el a kérdezőtől, de te azért jól meg mondtad, okos vagy, leülhetsz.

"Van egy rakas dolog, nevezhetjuk akar kiegeszitesnek (sack, delayed ack, slowstart stb) amik megbonyolitjak a helyzetet. "

jaj ekkora bullshitet régen hallottam már. Az előbb még nagyban fröcsögtél, hogy minden esetben megboritja a kommunikációt a nem sorrendben érkező packet, miközben a tcp egyik alapköve a nem sorrendben érkező packetek sorrendbe rakása. Jóvicc...

"Nyilvan ez sem tunt fel, amikor a (lasd foljebb) 100 ezer Ft-os, 96gbit/sec sebessegu (lol) switchedre rakototted a nyilvan terabites forgalmat generalo szerverparkodat."

bogárvirág én legalább használtam már ilyet élőben is nem szakmai blődségekkel dobálózok és igen, semmi gond nem volt sem a dupla mac-ből, sem a round robinból, ugyanúgy hozta 2x1 gbit-es sebességet, csak switch assist nélkül asszimetrikus volt a sávszél.

Na további szép napot...

"Hát ez a gyakorlatban nem igy működik switch és gép között, ugyanis a kliens hanyattdobná magát, ha két mac address-t kapna ugyanarra az ip-re (fogadó és küldő oldal). Ugyanis ezt hivják IP ütközésnek. Talán switchek között mehet ez igy."

Ez a gyakorlatban igy mukodik, mert az ARP keresre csak az aktiv fogado interfesz valaszol, tehat nincs semmilyen "IP utkozes". Sot azt is meg lehet csinalni, hogy mas-mas ARP keresekre mas-mas interfeszrol menjen a valasz, igy lehet fogadasi iranyban is egyszeru load balancingot csinalni etherchannelt nem tamogato switch-el.

De en ezekrol tenyleg csak elmeletben vitatkozom, igazad van, bar egyszer mar lattam egy Cisco switch web feluletet, es a kollegam megigerte, hogy a laptopomra segit feltenni az Ubuntu Linuxot, majd azon kiprobaljuk.

;)

( PMC | 2008. 01. 02., sze – 15:24 )

Én ezt 119.2 MB/s -nek számolom elméletileg is.

( skynetpro | 2008. 01. 02., sze – 15:47 )

régen hallottam olyanról hogy multilink, az nem arra jó, hogy két gépet 2*2 hálókártyával összeköss és gépenként csak egy interface van?