3000L problem przy wysyceniu

Przy pełnym wysyceniu sektora 170-180Mbit DL sztucznym ruchem TCP z wielu stacji mimo zastosowania QOS (który działa do pewnego momentu) następuje całkowite zerwanie transmisji 100% PING utraconych.

Ale tylko do stacji które NIE GENERUJĄ OBCIĄŻENIA i nie bardzo mogą się one już wbić.

Czyli ciężki użytkownik zawłaszcza tramsmisję ale tylko gdy dojdziemy do MAX limitu zdecydowanie nie tak powinno być ????

3000L

26 SM Elevate SXT/LHG

Wersja 4.4.3 

I have forwarded this to the support and development teams.

2jarek,
Możesz przysłać więcej szczegółów jakie zastosowałeś ustawienia QOS i jak dokładnie odbywa się testowanie? W zasadzie airferness powinien tu gwarantować zasoby każdemu SM, ale na e3kL nie działa jeszcze tak dobrze jak na e2k. W wersji firmware 4.5 (ten kwartał) spodziewamy się usprawnienia airferness dla platformy opartej na czipie AC.

1)Ruch w tym segmancie sieci jest znakowaany DSCP dzielony n 3 grupy na CCR (DSCP 60 to tylko poing VOIP gry, DSCP 10 to ciężki ruchh w tym sztuczcny test)

Następnie trafia bezpośrednio do 3000L w którego jest wpięte niemal 30 klientów.

2)Na klientaach na których mam bridge za nimi routery klienckie MT na których mogęodpalić bandwitch test do tego CCR36. BT 20 sesji TCP na 2 klientach eliminuje z ruchu inne stacje jeśli te akurat były nieaktywne (są podpięte ale transmisja nie przejdzie) A generujące tak duże obciążenie stacje nadal odpowiadają łądnie na PING można na nie się zalogować.

3) Takie same obciążenie generują np klienci korzystająący ze STEAM albo czasami nawet netflix przy video 4K

A byłaby szansa sprawdzić jak się system zachowa bez ustawień QoS na bazie?

Bez zmian wysycenie wywala stacje które nie generują obciążenia. Te na które idzie duży ruch ping i responsywność bardzo dobra. (Nadajnik nie był restartowany po zamianacch ale nie pokazywało by było to wymagane). Problem jest banalnie prosty do replikacji.

Ciekawostka gdy używam wbudowanego testu UDP który łączy się z AP i też wysyca link plus normalne obciążenie sektora żadnych problemów nie ma. A gdy przepuścić z zewnątrz test UDP przez AP stacje które nie generują obciążenia są identycznie jak poprzednio niemal rozłączane ping 2s itd.

Wygląda to troche jak na MT gdy na interface WIFI damy ogromny bufor.


@2jarek wrote:

Bez zmian wysycenie wywala stacje które nie generują obciążenia. Te na które idzie duży ruch ping i responsywność bardzo dobra. (Nadajnik nie był restartowany po zamianacch ale nie pokazywało by było to wymagane). Problem jest banalnie prosty do replikacji.


Dzięki za info. Być może problem daje się łatwo replikować z użyciem MT. W labie próbowaliśmy IPerfem "zarżnąć" ruchem TCP 2 jednostki, ale nie udało nam się uzyskać opisywanego efektu. Szukamy dalej.


@2jarek wrote:

Ciekawostka gdy używam wbudowanego testu UDP który łączy się z AP i też wysyca link plus normalne obciążenie sektora żadnych problemów nie ma. A gdy przepuścić z zewnątrz test UDP przez AP stacje które nie generują obciążenia są identycznie jak poprzednio niemal rozłączane ping 2s itd.

Wygląda to troche jak na MT gdy na interface WIFI damy ogromny bufor.


Wszystkie procesy w urządzeniu mają prioryted niższy niż obsługa ruchu klienckiego, dlatego w przypadku testu wewnętrznego efekt nie jest widoczny... Pracujemy nad tematem - uaktualnię wątek jak coś się wyjaśni.

A czy były to elevate i w trybie bridge…?


@2jarek wrote:
A czy były to elevate i w trybie bridge...?

Różne kombinacje urządzeń, włączając SXT Lite5 w trybie bridge... Spróbujemy z obciążeniem za pomocą MTków.

To może BT od miktorika przez UDP on nie obciąża tak procesora jeśli rb jest słaby.

--- Obiecane uaktualnienie wątku ---

Dzięki uprzejmości i zaangażowaniu @2jarek (jeszcze raz wielkie dzięki za dzisiejszą współpracę i za poświęcony czas), inżynierowie Cambium pracowali dziś nad tematem na "żywym organizmie". Stwierdzono, że maksymalne wysycenie bazy ruchem TCP przez dwie aktywne jednostki klienckie powoduje duże fluktuacje jittera na jednostkach o małej aktywności. Ta fluktuacja sięgała ponad 500ms (w momentach krytycznych zarejestrowano nawet 1500ms), co było interpretowane przez test Mikrotikowy jako utrata pakietu - choć w praktyce utrat nie stwierdzono. Odpowiednie statystyki zostały zebrane, wnioski wyciągnięte i w kolejnych wersjach firmware dla baz e3k / e3kL, funkcjonalność air-fairness będzie systematycznie poprawiana. Już w nadchodzącym release 4.5 powinna być widoczna znaczna poprawa działania tego mechanizmu.

2 Likes

Po tygodniowym testowaniu poprawionej wersji 4.4.3-test wydaje się, że problem jest rozwiązany. Ping / jitter pod obciążeniem jest niemal taki sam jak bez obciążęnia a paasmo dzielone jest sprawwiedliwiej. Dzięki za błyskaawiczną poprawkę.


@2jarek wrote:

Po tygodniowym testowaniu poprawionej wersji 4.4.3-test wydaje się, że problem jest rozwiązany. Ping / jitter pod obciążeniem jest niemal taki sam jak bez obciążęnia a paasmo dzielone jest sprawwiedliwiej. Dzięki za błyskaawiczną poprawkę.


Dzięki za info zwrotne i jeszcze raz za pomoc w namierzaniu problemu. Wersja 4.5 będzie zawierała te zmiany. Mam świeżo upieczoną betkę jakby co ;-)

1 Like