kriZb <k...@n...no> writes:

> Dla mnie to stare, a jednak nawet xeona nie ma. PentiumD DualCore.

To nie takie znowu stare. Jakby to bylo np. 68000 (np. 68360) to moznaby
powiedziec ze rzeczywiscie stare. Nie wiem co ta maszyna ma robic, ale
do "obsluzenia" na pusto np. 100 Mb/s to kazdy P4+ jest za szybki.

> Ale wynik co widzialem w granicach 40-70mbit juz podoba mi sie. I jest
> dobrze.

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.
--
Krzysztof Halasa

do góry

Krzysztof Halasa napisał(a), dnia pięknego 2010-01-14 18:27:
> kriZb <k...@n...no> writes:
>
>> Dla mnie to stare, a jednak nawet xeona nie ma. PentiumD DualCore.
>
> To nie takie znowu stare. Jakby to bylo np. 68000 (np. 68360) to moznaby
> powiedziec ze rzeczywiscie stare. Nie wiem co ta maszyna ma robic, ale
> do "obsluzenia" na pusto np. 100 Mb/s to kazdy P4+ jest za szybki.

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. Poza tym, zebrałem
sobie lspci i ... Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8169 Gigabit Ethernet. 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 wynik co widzialem w granicach 40-70mbit juz podoba mi sie. I jest
>> dobrze.
>
> 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.

do góry

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.

> 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.

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).

>> 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.
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.

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

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.
--
Krzysztof Halasa

do góry

Krzysztof Halasa pisze:

>
> 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).

Pentium 166 przy pppoe kernel mode na 2.4 wprawdzie przy kartach intela
przy 100Mbitach miał 40% proca zajęte.
Takie robiłem testy kilka lat temu. Koncentratory stawiałem na 133/166
dla 30-50 userów ...

Heh to były czasy :)

paweł

do góry

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 ;)

do góry

Paweł Rohde napisał(a), dnia pięknego 2010-01-14 21:32:
> Krzysztof Halasa pisze:
>
>>
>> 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).
>
> Pentium 166 przy pppoe kernel mode na 2.4 wprawdzie przy kartach intela
> przy 100Mbitach miał 40% proca zajęte.
> Takie robiłem testy kilka lat temu. Koncentratory stawiałem na 133/166
> dla 30-50 userów ...
>
> Heh to były czasy :)
>
> paweł
Kernel 2.6.26-7 ... intrux.
na teraz ->
ifconfig |grep ppp|wc -l
236

Nie twierdze, ze nie da rady. Ale uwazam, ze rozbijanie uslug na maszyny
w przypadku softowych rozwiazan to podstawa. Maszyna robiaca
wszystko-w-jednym wirespeed jednak kosztuje pare groszy i ma w sobie
odpowiednie ASICi

do góry

kriZb <k...@n...no> writes:

> 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.

Ale co ma kontroler Ethernet do routingu? On ma odbierac i wysylac ramki
najlepiej wirespeed, najlepiej bez jakiegos wielkiego obciazania CPU
i szyny. Przy < 100 Mb/s roznice miedzy scalakami GbE sa nieistotne
(tzn. nie uzywalem oczywiscie wszystkich, ale przynajmniej wsrod tych,
ktorych uzywalem, wlaczajac RTL*).

Mozna miec zbyt wolny procesor do obslugi wszystkiego razem (wlaczajac
np. wiele peerow BGP), ale to nie ma zwiazku z samym scalakiem robiacym
Ethernet.

> 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.

Nie Mbit/s ani Gbit/s, to sa megabajty/gigabajty /s.

Typowe PCI 32/33 = 133 MB/s (nie Mb/s), PCI 32/66 (raczej maszynki
serwerowe i specjalne) = 266 MB/s, PCI 64/66 (stare Alphy) oraz PCI-X
64/66 = 532 MB/s. PCI-X 64/133 = 1064 MB/s. Z szybszymi sie nie
spotkalem. Nalezy pamietac ze PCI i PCI-X to sa szyny half-duplex,
w przypadku symetrycznego obciazenia RX + TX ich efektywnosc spada
~ dwukrotnie.

PCIe 1 lane = 250 MB/s (w praktyce ponad 2x wiecej od PCI 32/33)
4x = 1 GB/s (wiecej niz PCI-X 64/133 mimo nominalnie mniejszej
przepustowosci), 16x to raczej tylko dyski i grafika.
PCIe 2.0 1 lane = 500 MB/s, nie wiem czy sa jakies Ethernety na tym.

Trzeba pamietac ze PCIe to full duplex. Dodatkowo PCIe jest punkt-punkt,
nie ma tego problemu jak w przypadku kilku kart PCI-X i PCI, ktore
musza dzielic miedzy siebie cala przepustowosc szyny.

PCIe to nowsza technologia, mniejsze karty, mniejsze ceny. Ja raczej
wole PCIe niz PCI-X.
Np. sa zupelnie niedrogie (w porownaniu do PCI-X przynajmniej) karty
PCIe 4x dual 1000BASE-T na intelach. Inna sprawa ze mam wrazenie ze PCIe
1x tez do tego wystarczy w typowych warunkach. Z drugiej strony, jesli
ktos potrzebuje 10Gb/s, to chyba nie ma takich kart PCI-X.

Ale to wszystko ma znaczenie przy ruchu wiekszym niz 100 Mb/s. Do
kilkudziesieciu Mb/s spokojnie wystarczaja stare Intele np. 82559/551,
albo np. uzywane przeze mnie 10+ lat temu karty na DECchipach 21140,
21143. Wszystko na PCI 32/33.

> 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 ;)

Przy TCP? Dosc ciekawe zjawisko, margines na takie zachowanie jest
bardzo waski. Zwykle albo to dziala (z bledami < 0.X%) albo nie dziala
w ogole.

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

iperf to inna sprawa, ale generalnie UDP nie musi wcale wyjsc gorzej.
TCP jest bardziej ogolnym, zlozonym protokolem, na UDP mozna zrobic
specjalizowana usluge bardziej efektywnie, zwlaszcza w nietypowych
warunkach (jak takie z kablem, ktory ubija np. co 10 pakiet). Z tym, ze
ta usluga bedzie bardzo nieefektywna po zmianie warunkow, TCP potrafi
sie dostosowac do warunkow dosc dobrze. Oczywiscie w granicznym
przypadku mozna zrobic TCP over UDP.

> 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.

Innymi slowy, glownie to ostatnie. Podejrzewam ze wiekszosc testujacych
testowala swoje waskie gardla :-)
Oczywiscie trzeba zapewne brac takze pod uwage, ze 1 Gb/s nie jest
dedykowany dla tej maszyny, ani pewnie tez dla iperfa na niej.

> 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.

To jest pomiar szacunkowy. Trzeba miec swiadomosc warunkow, w ktorych
jest wykonywany. Lepiej przeprowadzac test taki, jak zastosowanie linku.
Np. jesli potrzebujemy robic 3-godzinne backupy przez pol Polski o 4
w nocy, to zapuszczamy 3-godzinny test TCP przez wlasnie ta polowe
Polski o tej 4 w nocy. Jesli potrzebujemy dostarczyc Internet ilus tam
klientom, to po prostu im dostarczamy, zbierajac wyniki w czasie pracy.
--
Krzysztof Halasa

do góry

kriZb <k...@n...no> writes:

> Nie twierdze, ze nie da rady. Ale uwazam, ze rozbijanie uslug na maszyny
> w przypadku softowych rozwiazan to podstawa.

Jasne w przypadku serwerow. W przypadku routingu (i zwiazanych z nim
rzeczy), pecet jest w stanie bez problemu obsluzyc naprawde spory ruch.
Mozna (i w wiekszych zastosowaniach trzeba) robic redundancje.

> Maszyna robiaca
> wszystko-w-jednym wirespeed jednak kosztuje pare groszy i ma w sobie
> odpowiednie ASICi

Owszem. Ale to ma znaczenie w takich warunkach, ktore sa poza zasiegiem
pecetow. Obecnie pecety zblizyly sie (przekroczyly?) do granicy robienia
routingu 10 Gb/s. W kazdym razie kilka Gb/s to nie jest problem nawet
dla starszego sprzetu, kosztuje to niewiele, i dziala bez specjalnych
problemow.

Po prostu pecet, jako rozwiazanie masowe, jest tani, i roznice
w specjalizowanych scalakach mozna pokonac uzywajac po prostu brutalnej
sily np. CPU :-)
--
Krzysztof Halasa

do góry