Krzysztof Halasa napisał(a), dnia pięknego 2010-01-14 20:20:
> kriZb <k...@n...no> writes:
>
>> Wiesz, to jakas tam sieć typu u&*^a. Taki DIY wszystkowjednym, pusto nie
>> jest bo IOki pewnie wykorzystane ile się da (sesje pppoe, apache, jakieś
>> SFQ czy jak to tam było). Także wydaje mi się, że dla tak uniwersalnego
>> bóg-jeden-wie-czego to i tak będzie niezły wynik.
>
> Kilkadziesiat Mb/s? Taki sobie. Jaki tam jest uplink?
>
>> Poza tym, zebrałem
>> sobie lspci i ... Ethernet controller: Realtek Semiconductor Co., Ltd.
>> RTL-8169 Gigabit Ethernet.
>
> Kilkaset Mb/s bez wiekszego problemu obsluguje chyba? Sprawdzilbym
> dokladniej (lspci -vv) co to za scalak.
>
Hm, w polaczeniach ptp czy bridgowaniu - tak. Zauwazylem na labie
ogromna degradacje przeplywnosci przy uzyciu protokolow dynamicznego
routingu (nie testowalem RIP/RIP2). Uwazam, ze RTL8169 jest przeznaczony
dla rynku SOHO a nie potrzebujacego wydajnosci Enterprise/carrier.

>> Nie sprawdzałem, bo mi się po prostu nei
>> chciało czy toto jeszcze nie ma ip/xtables.
>> To chyba rzutuje na wynik w jakimś stopniu. Jak sobie jakiś nibyISP robi
>> wszystko na linux'ie najtańszym kosztem, to potem się zaczyna ;)
>>
>> Nie powiem, moje BGP też stoi na linuxie, ale karty na PCI-X (ten
>> starszy XEON, ale 2cpu 2rdzenie) z offloadem intela + irqbalancing) i
>> jakoś się chyba kula. Chyba, bo eksperymentalnie (działa to nie
>> zmieniam) jadę na FIB_TRIE.
>
> Ale mowimy o kilkudziesieciu Mb/s. Stary Xeon (P4) jednordzeniowy (wtedy
> nie bylo jeszcze x2) z kartami 133/64 (ale to bez znaczenia przy < 100
> Mb/s) obrabia pare Gb/s.
>

U mnie wali 2,5g w przelaczaniu - fakt, ze narazie tylko dwa pelne feedy
- i daje rade. Jeszcze. Zaprzyjaznieni OIDK maja po prostu 0.0.0.0/0 via
x.x.x.x

> Nawet stary 82541 w PCI 33/32 bez mrugniecia okiem obrobi 100 Mb/s (przy
> samym routingu i ew. PPPoE itp. nawet na maszynie klasy Pentium 100 MHz,
> aczkolwiek teoretycznie, bo praktycznie testowalem z innymi, starszymi
> kartami).
>

PCI33 da rade na 100, specyfikacja PCI 2.0 standaryzuje polaczenie na
133Mbit przy 33MHz, 2.1-2.3 to 528Mbit, ale przy 66MHz. Szyna PCI-X 1.0
oferuje juz 1066MHz. PCI-e 4x to 1Gbitps. Moze i jestem odmiencem, ale
wole PCI-X.

BTW to gdzie testowane to realteki lowlevel PCI33, z tego co lspci wywala.

>>> Inna sprawa ze iperf to specyficzny test i lepiej nie traktowac tych
>>> wynikow jako ogolnego wskaznika. Ew. mozna brac najwieksza wartosc,
>>> jesli to musi byc iperf.
>> Uwzględniam średnią, wyszło OIDP 63Mbit.
>
> Lepiej chyba max.

Zawsze najlepiej przyjac maksimum, jesli ma sie cos do
udowodnienia/zarzucenia. Do obiektywnego i miarodajnego testu nalezy
przyjac srednia odrzucajac bledy pomiaru (np. widoczne testy z xDSL TP,
czy widoczne pasma ponizej powiedzmy 15Mbit). Wtedy wykluczymy dupne
linki np. -> Tier2.

> Zaleznie od testu, przy TCP sprawdzamy po prostu wydajnosc pojedynczego
> TCP, to jest czesto duzo mniej niz wydajnosc linkow/routerow itd.
> (np. przy load balancingu per-flow wynik nie bedzie wyzszy niz dla
> pojedynczego linku). To ma sens jesli chcemy oszacowac czas transferu
> przy robieniu np. backupu.
>
W takim ukladzie proponowalbym zapuszczenie np. 20 iperfow w danym
kierunku. Daje 20polaczen*NMbit co w chwile mozna zsumowac i porownac do
pojedynczego polaczenia. Oczywiscie mozna tez OIDP wywolac pktgen, ktory
wywola symulacyjna transmisje. W koncu w typowych zastosowaniach,
niewazne czy malego czy duzego czy dominujacego operatora mamy do
czynienia z roznymi wielkosciami pakietow, roznymi trasami i roznymi
dostepnosciami. W polaczeniach L3, gdzie wykupujemy odpowiednia
przeplywnosc, wiadome jest, ze via PL-IX bede mial wiecej niz via TPnet
od ktorego biore powiedzmy TPNET.pl o przeplywnosci powiedzmy 80Mbit.
Kazdy z nas ma prawo takze narzucac prio/ACL/preferencje na dane gniazda.
W L2 po prostu zapinam 1G FDX to mam 1G FDX, o ile oczywiscie
matryca/cpu pozwoli. Chociaz mialem kiedys kabel z uwalaniem pasma,
chinszczyzna stalowa powlekana miedzia, l1 ladnie pokazywalo polaczenie
100FDX, ale nie dalo rady wyssac wiecej niz powiedzmy 4Mbit. Kryzys
dobija chinoli tez ;)

> Mam wrazenie ze test UDP iperfa byl jeszcze mniej miarodajny, ale nie
> pamietam juz szczegolow.
>

Kazdy test UDP wyjdzie gorzej. Po raz jest bezpolaczeniowy, po dwa jak
kojarze to iperf w UDP wali mniejszym pakietem.

> Oczywiscie testy sprawdzaja wydajnosc najwezszego gardla (oraz takie
> rzeczy jak np. RTT i packet loss), wiec jesli ktos ma wezsze gardlo niz
> to testowane (np. < 100 Mb/s), to robienie testu pozbawione jest
> jakiegokolwiek sensu.

Link teoretyczny u nich, up/downstream, to 1G - nalezy oczywiscie brac
pod uwage trase po ktorej latamy, jak i tez up/downlink skad wykonywany
jest test.
Wracajac do testu - uwazam, ze standardowy 10sekundowy test jest na tyle
malo miarodajny, ze daje jedynie pogladowa sytuacje w przeciagu
krotkeigo czasu - narzuca nam to naprawde spory blad pomiaru. Prawdziwym
pomiarem byloby mierzenie dlugookresowe (np. 24h) polaczone z
porownaniem nie tylko mierzonego urzadzenia/serwera ale tazke gniazdek
miedzyoperatorskich np. via PL-IX, PIX, WIX, AC-X czy pojedyncze peeringi.

Krzycz na mnie jak sie myle ;)