Przerwy w wysyłaniu danych po socket WiFi

Mam taki problem, ktoś to napisał a ja poprawiam a nie mam na kogo zepchnać :D

• Koncepcja zakładała wysłanie z urządzenia embedded Linux do telefonu obrazy, obraz ma wymiary 128x256 px (dane sa 8 bitowe) , 20fps , połączenie z pomocą WiFi, Access Point na urządzeniu embedded

Testy połączenia za pomocą niezależnego narzędzia iperf3 ,
z mojego puntu widzenia zapas jest bo 20 fps * 32KB = 5242880b/s (+ narzut protokołu z zapasem 25% to i tak będzie poniżej minimum wykresu )

Ale potem przy wysyłaniu coś się przytyka i są przerwy w wysyłaniu danych , zrobiłem sobie w SVG prosty wykres co tam się dzieje w środku serwera który wysyla dane
jedna kreska to 32KB , oś X = czas
dane wysylaja się pomiedzy s_LV_FrameLinesSendBegin a s_LV_FrameLinesSendEnd i jedyne co tam jest to wpisywanie danych do socket , nic ponad to

Trochę brak mi pomysłu co mogę jeszcze zrobić , może to jakieś wąskie gardło w hardware ? Tylko dziwne że na iperf3 są dość wysokie transfery

Na zwykłej sieci LAN wszystko działa OK,

ktoś może zasugerować jakieś pomysły, bo może po wifi trzeba coś więcej poustawiać dla socket-u ?

Może masz problem z konfiguracją interfejsu sieciowego w linuxie?

Porównaj sobie wartości TX i RX interfejsu WIFI z interfejsem LAN.
https://www.itechlounge.net/2015/05/linux-how-to-tune-up-receive-tx-and-transmit-rx-buffers-on-network-interface/

Wrzuć sobie plik na próbę i zobacz jak się zachowuje.

Kolorystyka wykresu zabija moje oczy o_*

"Zatyka się na wysyłaniu", czyli z userspace będziesz widział, że wisi na jakimś send(), write() czy innym wywołaniu systemowym i to trwa X czasu.
Z perspektywy aplikacji nie dowiesz się dlaczego. Moim zdaniem powinieneś spojrzeć na to co dzieje się w kernelu.

Na serwerze najprościej próbkować stack trace procesu:cat /proc/<pid>/stack i na podstawie tego obrać kierunek dalszej analizy.

Musisz zaobserwować co się dzieje na poziomie pakietów TCP. Czyli sprawdź jaką mają długość, jak często są wysyłane, jak szybko są potwierdzane, ile z nich ginie, jak często są powtarzane itp.

https://www.download.net.pl/jak-zmienic-kanal-sieci-wi-fi-na-routerze-i-wzmocnic-sygnal/n/2877/

@yarel zastanawiam się czy profiler mi coś podpowie ale nie zaszkodzi sprawdzić , dwa rdzenie (z dwóch) używają po 70% do swoich obliczeń , a watek wysyłanie danych TCP to ledwo 1.0%
z profilerów to mam zbudowany na ten komputer ARM valgrind widzę też że można ograniczyć profilowanie do jednej funkcji ,
proponowany "oprofile" sie stawia podczas cross compilacji (brak libiberty.a)

alternatywne programy do sprawdzenia https://en.wikipedia.org/wiki/List_of_performance_analysis_tools

@P2420 mogę w sumie porównać jak pakiety wysyła iperf3 vs moja aplikacja może to coś natchnie

Nie napisałeś jakie to urządzenie, jaki linux oraz nie podałeś kodu.
Media staraj się wysyłać poprzez UDP.

Jedyne co mi przychodzi do głowy na podstawie tego co podałeś, to przełączanie wątków (nie wiem z jaką wartością masz skompilowany system).
Jeśli możesz ustaw maksymalny możliwy priorytet dla tego procesu i zobacz czy problem nadal występuje (dodatkowo możesz jeszcze zmniejszyć pozostałe z kernela jeśli to nie spowoduje problemów z działaniem).

Zamiast coś porównywać uruchom np. program Wireshark i zobacz jak przebiega transmisja.

Adamek Adam napisał(a):

• Koncepcja zakładała wysłanie z urządzenia embedded Linux do telefonu obrazy, obraz ma wymiary 128x256 px (dane sa 8 bitowe) , 20fps , połączenie z pomocą WiFi, Access Point na urządzeniu embedded

Co to za urządzenie? Jakieś Arduino?

@Adamek Adam: To "70% CPU do swoich obliczeń", to application time czy system/wait time? Kolejna sprawa, masz pewność, że problem jest z serwerem, a nie klientem? Wówczas te 70% serwera, to mogłyby być waity właśnie na recv() na kliencie.. Na serwerze można by to poprawić przez zwiększenie send buffer, ale to szukanie w ciemno.

Skoro 1% idzie na TCP i są przerwy, to co w tym czasie robi kernel i aplikacja? Niestety nie wiem jak w systemach embedded można zbierać stosy wywołań kernela i aplikacji (wspomniany brak /proc/<*>/stack)

Jak długie czasowo są te opóźnienia? Mikrosekundy czy milisekundy? Zastanowiłbym się czy to nie CSMA/Cx (Cx bo nie pamiętam czy to był CA czy CD) albo czy nie przepełniasz kolejek TCP/UDP po stronie nadawczej albo odbiorczej.