modified on 10 sty 2008 at 10:27 ••• 14 303 views

Ping na wagę złota

Z MikroTik Wiki

Przeniesione z Forum OSBRIDGE.pl

Panie i Panowie

Myślę że sytuacja dojrzała już do tego aby przedyskutować na tym forum "PROBLEM DŁUGIEGO PINGA". Otóż blisko połowa nowo podłączanych do sieci abonentów robi to głównie w nadziei korzystania z tanich rozmów za pośrednictwem "komunikatorów głosowych" (Skype;Tlen;GG;Net2Phone;etc.) oraz jeśli chodzi o młodszych to jak wiadomo "gier online". Jak również wiadomo mniej i bardziej doświadczonym twórcom bezprzewodowych sieci ,wszystkie w/w przeze mnie usługi wymagają nie tyle gigantycznych przepustowości co w skrócie mówiąc "Krótkiego Pinga", i TU JEST PIES POGRZEBANY ! Rozumiem znużenie Znawców tematu pytaniami o proste problemy konfiguracyjne eMTeka, ale problem ,o którym wspomniałem (przynajmniej w moim rozumieniu ) nie jest problemem nic nie znaczącym, a nie jednemu spędza sen z powiek (zarówno administratorowi jak i abonentowi) .Rozmiar problemu administratora takiej sieci jest wprost proporcjonalny do ilości jej użytkowników/abonentów.

Czy zatem Ktoś z bywalców tego forum ominął już ten problem ? Będę wdzięczny za jakiekolwiek sugestie ! Pozdrawiam B.A.D.L.U.X.


hmmm faktycznie trzeba sporo łącza, żeby każdy miał eleganckie pingi, jeżeli chce grac, rozmawiać itp. wg mnie trzeba mieć po prostu gwarantowane pasmo dla siebie, może to być nawet 115kbps, byleby było gwarantowane 115, co za tym idzie, trzeba mieć sporo łącza, w malej sieci np 512kbps - jeżeli podłączymy 15 useerow na 115/64, zakładając ze naraz 10ciu nie rzuci sie na kazee - to ping będzie elegancki. Jeżeli użytkownik ma pasmo 115 i odpali np eMule to cale to 115kbps jest zapchane (mimo ze mul pobiera mu np 5kb/s), wiec od tego 512 pozostaje oddajac 115 .. itd Nie wiem czy dobrze rozumuje, ale testowałem to u siebie, i chyba faktycznie tak jest.

Witam kolegów Mam całkiem udane doświadczenia z pakowaniem pakietów w locie czyli /ip packing W przypadku połączenie bridge<->client np epio działa to rewelacyjnie niestety kosztem wydajnych maszyn ( min PIII 800 ) Wbrew temu co sugeruje manual wielkość "złożonego" pakietu ustawiłem na 1400 bajtów , przy tej wielkości uzyskałem kompromis pomiędzy wydajnością a czasem reakcji sieci Przy większych pakietach np 4000 bajtów np. strony www ładowały sie b.szybko ALE czas oczekiwania na daną stronę był zbyt długi ( pow 5 sekund ) Mam pakowanie pakietów włączona na 10km/5ghz linku ( z jednej strony 120 klientów )

hmmm ale ip packing to tylko miedzy mikrotik - mikrotik chyba? a nie mikrotik - klient (karta, ap itp) ? czy sie mylę?::>

na początek sugeruje wyodrębnić porty na których te cuda działają i nadanie im wyższych priorytetów Pozdrawiam Gularz_pl


Pomysł zapewne nie głupi... jednak miło byłoby dowiedzieć się od kolegi gularza jak to dokładnie zrobić...

Jeśli chodzi o mnie to powiem tylko ze nie mam klientów bezprzewodowych ponieważ MT wykorzystuję głównie do budowy mostów EOiP i właśnie na nich mam spore problemy.


PO CO TO KOMU Ano radyjka zdychają głównie z powodu nadmiernej ilości pakietów a nie z powodu ilości danych. 1000 pakietów po 40 bajtów to nie to samo co 40 pakietów po 1000 bajtów. Jak to sprawdzić / polecam bandwidth-test przy rożnych wielkościach pakietów np 100 bajtów i 1500 bajtów. Cóż / Król jest nagi..... Więc ktoś wpadł na pomysł ( i nie był to Mikrotik ) aby spakować małe pakiety w jeden duży PRZED wysłaniem je przez medium ( niekoniecznie radio )

TEORIA I KONFIGURACJA Generalnie ip packing możliwe jest tylko pomiędzy dwoma interfesami wysyłającymi pakiety MIĘDZY sobą ( są dla siebie wzajemnie docelowe ). Ponieważ eoip TAk właśnie działa ( kapsułkowanie dowolnych rame ethernet w pakiet TCP/IP ) to ip packing nadaje sie do tego typu połączenia doskonale

Jak to załączyć ? Po pierwsze na interfejsach które mają być użyte do pakowania pakietów MUSI być włączona opcja /ip neighbor discovery po obu stronach połączenia np.

MT_1

ip neighbor discovery> set wlan1 discover=on

MT_2

ip neighbor discovery> set wlan1 discover=on

następnie definiujemy sposób pakowania pakietów: dostępne są 3 rodzaje pakowania

simple - łączenie drobnych pakietów w jeden duży ( bardzo podobne do fast-frames tyle że na poziomie softu ) compress-header - łączenie drobnych pakietów jeden duży i dodatkowo kompresja nagłówków pakietów ( tali ZIP dla nagłówków ) compress-all - łączenie i kompresja nagłowków i danych pakietów

można wybrać odrębny algorytm pakowania dla pakietów przychodzących a inny dla wychodzących używając polecenia:

np MT_1

/ ip packing set wlan1 packing=siple unpacking-compress-all

i jeszcze jedna ważna rzecz a mianowicie wielkość w bajtach tak utworzonego pakietu:

/ ip packing> set wlan1 aggregated-size=1400

oczywiście w/w ustawienia należy wykonać po OBU stronach linku.

OPTYMALIZACJA. Mikrotik obiecuje przy zastosowaniu ip packing nawet czterokrotne zwiększenie przepustowości sieci. Mało tego , wręcz sugeruje że jest to panaceum na pakiety typu VoIP ( czyli sztorm małych pakietów ). Aby było jeszcze ciekawiej , MT twierdzi że wielkość pakietu może być znacznie większa od MTU interfejsu.

W zastosowaniach WiFi do redystrybucji zasobów internetu mamy do czynienia ze zjawiskiem dużej ilości małych pakietów od klientów do internetu ( pakiety nawiązujące połączenia / pakiety arp / broadcast / wszelakiego typu śmieci generowanie przez wirusy / pakiety UDP itp. ) a relatywnie mniejsza ilością dużych pakietów z internetu do klientów. Mają to na uwadze sugerowałbym niesymetryczną konfigurację czyli pakiety wychodzące od klientów do internetu algorytm compress-all a pakiety przychodzące z internetu algorytm simple. Wielkość pakietu ( niestety jednakowa dla pakietów przychodzących i wychodzących ) należy dobrać eksperymentalnie do konkretnego połączenia. Generalnie im mniejszy pakiet , tym reakcja sieci szybsza ale stopień kompresji a tym samym przepustowość połączenia mniejsza W moim przypadku przy linku 10km/5Ghz wielkość pakietu to 1400 bajtów ale na innym sprzęcie , czy w innych warunkach , ta wielkość może być inna / ( polecam eksperymenty )

To tak z grubsza by było / jak sie pomyliłem to sorry Pozdrowienia dla Poszukiwaczy.......

Muszę dodać ,że przy wstępnych testach i ustawieniach takich jak kolega peter2 podał ping wypuszczony z serwera do klienta wzrósł z 1.20-1,40ms do około 20-30ms .dodam że ustawiałem wielkość pakietu na poziomach 200,500,800,1000,1300,1500,1600 bytes

Zmieniłem później ustawienia na "simple,simple" i nic się nie zmieniło.

zastanawiam się zatem czy sprzęt do tego nie jest aby za słaby ? z jednej strony mam PII 350 , a z drugiej pII450MHz może to zbyt mało ?

dodam jeszcze że testy te robiłem o drugiej w nocy gdzie tylko dwóch użytkowników tego mostu korzystało z sieci na poziomie 80-100 kbit

jakieś sugestie ?

no i chciałbym ponownie napomknąć o wątku priorytetyzacji usług Rolling Eyes

chm......ja uważam ze tylko rozsądek pomoże zapobiec takich "tłokom" w sieci. Jak to zrobiłem ja...przede wszystkim uświadomienie klienta, ze pewne usługi mają ograniczenia (p2p), po drugie (jak to za pewne kilka firm u mnie w mieście robi)mając dsl 2 MB nie daje sie dla klienta 1024/1024...bo jak to możliwe ??? Najniższy pakiet akurat u mnie to 64/128, i nikomu uploadu większego jak 64 jeszcze nie dałem, do tego max 40 użyszkodników na AP, izolacja p2p na 32up/64down, max liczba połączeń 25/s dla IP, do tego 2xproxy (web-proxy transparent, drugi Slackware parent Squid).priorytety na http i pocztę,no i na koniec żeby mi jakiś ciul za free sie nie wpinał to pppoe.......i tak to wygląda...i zdaje egzamin, mam w domku 64/128 i aktualnie ping mam nie większy jak 18ms.

zrobiłem to co kolega piter sugerował i powiem iz działa tyle ze po obu stronach mam pIII 1,5 ghz 256 ramu. Wzrostu pinga nie zauważyłem. A pakuje ładnie Pozdrawiam Gularz_pl

Kilka słów wyjaśnienia na temat niepowodzenia testu kolegi B.A.D.L.U.X W ip packing niestety wymagane są szybkie maszyny i PIII350 niestety do tego sie nie nadają

Przeprowadzałem test na: WRAP PC-ENGINES 266Mhz WRAK wykopał sobie dół / następnie sie zasypał , postawił sobie krzyż i UMARŁ / po prostu odpadł

ROUTERBOARD 532 / proc MIPS-333 było znacznie lepiej ale b.częste zwisy / też odpadł

PC CELERON 600 działało stabilnie ale przy transferze 4MB proca na 90-100%

PC PIII 850 Mhz / działa stabilnie i szybko / procesor na 50 %


Teraz trochę o specyfice ip packing W dużym skrócie to im gorzej tym lepiej

W przypadku dużego obciążenia sieci działa to wyśmienicie i różnicę w pracy pomiędzy wyłączonym ip packing a włączonym widać b.wyraźnie. Ale co sie dzieje jak ruch w sieci zamiera ( przypadek testu B.A.D.L.U.X ) Dokumentacja MT mówi że: JEŻELI ILOŚĆ PAKIETÓW JEST NIEWYSTARCZAJĄCA DO ZBUDOWANIA PAKIETU O ZADANYM ROZMIARZE AGREGACJI TO TAKI PAKIET ZOSTANIE WYSŁANY NAJPÓŹNIEJ W CIĄGU 15ms (+/- 5 ms)

Wynika z tego że przy małym ruchu czas pingu BĘDZIE SIE ZWIĘKSZAŁ czyli ( jak wspomniałem im gorzej ( większy ruch ) tym lepiej ( większa efektywność ip packing )

To chyba tłumaczy niepowodzenia B.A.D.L.U.X-a

odnośnie tego długiego pinga, to zauważyłem to kiedyś u siebie na TSUNAMI Proxima, a jakiś tydzień temu również na OSBRIDGE 5Gi, bez obciążenia pingi dochodziły na tych zestawach nawet do 500 ms, zachodziłem w głowę o co biega bo po obciążeniu pingi spadły do jednocyfrowych Wink, teraz zamierzam włączyć agregację w MTekach, ale to co napisaliście odnośnie sprzętu trochę mnie przeraża bo ja nigdzie nie mam procka powyżej 500 MHz, ale testowo włączyłem na kilku i fakt ilość p/s spadła, przepustowość bez zmian, ale czy mam to włączyć tylko na interfejsach 5GHz czy na bridge i EoIP też? Proszę o odpowiedź Wink

No to teraz moje spostrzeżenia , albo coś źle robię albo mam za mało pakietów w sieci żeby pakować.

1.) Maszyny : najmniejsza MMX 200, największa PIII 600

2.) CPU Load po włączeniu IP Packing bez zmian max 20%

3.) nie zauważyłem różnicy w pingu, ani w przepustowości.

albo nie włączyłem wszystkiego co trzeba, albo ilość pakietów bez pakowania jest tak mała że różnica jest niezauważalna, u mnei w sieci średnia przepustowość to 4.0 Mbps upload i tak samo download.