On Fri, 7 Oct 2022 20:40:36 +0200, Atlantis wrote:
> On 6.10.2022 17:18, J.F wrote:
>> Ciekawe co na to serwer - nie moze ci wyslac danych odpowiednio
>> szybko, buforowac tez nie moze w nieskonczonosc - powinien gdzies u
>> siebie przeskakiwac na aktualne dane.
>
> I wszystko wskazuje na to, że tak to właśnie działa. Przynajmniej
> odnoszę wrażenie, że dźwięki które słyszę z przerwami nie są kolejnymi
> fragmentami tego samego strumienia audio, ale raczej "okienkami" które
> aktualnie udaje się odebrać.
>
>> W przypadku radia moze byc inaczej, jesli nie ma u siebie bufora
>> danych. No ale nawet wtedy te ~20kB/s szybko uzbiera, a Ty nie
>> nadążasz odebrac.
>
> Tak. Pytanie tylko dlaczego nie nadążam tego odebrać. Można było
> teoretyzować o niskiej przepustowości pamięci SPI RAM (co i tak było
> wątpliwe, bo 18 MHz to naprawdę szybka transmisja) ale ta teoria padła w
> momencie, gdy identyczny problem udało się stwierdzić także w przypadku
> zastosowania bufora cyklicznego w RAM-ie.
>
>> Z grubsza mozliwe, ale patrz nizej.
>> A moze przerwania sa blokowane ?
>
> Jakie przerwania? W moim kodzie w ogóle nie używam przerwań związanych z
> Ethernetem. Używam gotowych sterowników dostarczanych przez producenta
> mikrokontrolera oraz gotowego stosu (lwIP). W rozsądnym projekcie
> użytkownik nie powinien w ogóle przejmować się przerwaniami - powinny
> one w tle ładować dane do jakiegoś FIFO. Zresztą nigdzie w dokumentacji
> nie znalazłem ani jednej wzmianki o przerwaniach.
> O ile informacje na jakie udało mi się trafić w Internecie są poprawne,
> to procedura odbioru jest następująca:
> - Stos wywołuje zarejestrowana wcześniej funkcję obsługi callbacku
> odbiorczego.
> - Do tej funkcji przekazywany jest wskaźnik na struct pbuf. Struktura
> zawiera dynamicznie alokowany bufor na payload. Może też zawierać
> wskaźniki do kolejnych struktur tego samego typu.

Zeby wywolac funkcje i przekazac bufor, to musi wiedziec, ze jakies
dane przyszly. Czyli przerwanie.

A jak funkcja dlugo obsluguje ... moze przerwania sa wyłączone, dopóki
nie skonczy.

> - Z jednej lub kilku struktur trzeba pobrać dane i gdzieś je zapisać.
> - Jeśli już skończyliśmy tę operację, wywołujemy pbuf_free() aby zwolnić
> pamięć oraz tcp_recved() aby zwiększyć rozmiar okna (poinformować
> serwer, że może przesłać więcej).
>
> U mnie może się zdarzyć sytuacja, że otrzymanych danych będzie więcej
> niż miejsca w buforze. Wtedy nie mogę ich odebrać od razu - muszę się z
> tym wstrzymać do czasu, aż dekoder MP3 wyjmie z bufora odpowiednią ilość
> danych. Wtedy odbiór tej konkretnej paczki jest opóźniony i odbywa się w
> pętli głównej.

I tu masz pare ryzyk:
a) przy niewielkim buforze opoznienie w wyslaniu potwierdzenia moze
skutkowac za duzym spowolnieniem transmisji,

b) bufory ci sie przepelniają, bo parametr TCP_window jest za duzy,
i serwer na poczatku przysyla ci za duzo danych,

> W żadnym miejscu nie mam do czynienia z przerwaniami.

Dekoder karmiony w petli glownej?
A moze tam sie zdarzaja duze opoznienia na inne akcje ?

>> Troche wątpie. Przy zgubieniu pakietu timeout sie wlacza, i to mogą
>> byc grube sekundy. Chyba bys nie uzyskal 5-11 kB/s.
>
> Kiedy transmisja zaczyna mulić to nie jest 5-11 kB/s, a 0-2kB/s.

A to juz moze byc, szczegolnie jesli widzisz, ze dociera kilka
pakietow, a potem dluga przerwa ..

>> Raczej bym sie spodziewal problemu w jakims opoznieniu w wyslaniu
>> potwierdzenia. Ale zeby az tak to SPI zwalniało? 18MHz wydaje sie
>> sporo ... a ogladales oscyloskopem? Albo czy mierzyles
>> przepustowosc/czas zapisu pakietu?
>
> Nie, bo wydawało mi się to nie mieć sensu. Udało mi się ustalić, że wina
> nie leży po stronie pamięci SPI. Przemawiają za tym dwa argumenty:
> - Pamięć SPI doskonale sprawdza się przy buforowaniu streama z karty SD.
> - Ten sam problem występuje, jeśli dane przychodzące przez TCP próbuję
> zapisywać do bufora cyklicznego ulokowanego w zwykłym RAM-ie.

To drugie w zasadzie wyjasnia, ale oscyloskop i tak moze pomoc.
Tu nawet nie oscyloskop, ale analizator logiczny za kilkadziesiąt zl.

>> A w ogole ... masz tam jakies zabezpieczenie kolejnosci w tej
>> bibliotece? Bo powiedzmy przychodzą pakiety nr 1, 2, 3, a nr 4 nie
>> przychodzi. Ale przychodzi nr 5, 6, 7 ... i co wtedy - nie dostaniesz
>> callbacka z nr 5, a bufory 5, 6, 7 zostaną skasowane ?
>
> Wydaje mi się, że przecież chyba TCP ogarnia kwestię pakietów
> przychodzących w złej kolejności i użytkownik nie musi się przejmować tą
> kwestią podczas pisania aplikacji.

TCP tak, pytanie, czy masz pelne TCP ..


> Ten problem pojawia się dopiero w
> przypadku zastosowania UDP.
> Tak czy inaczej lwIP ma opcję związana właśnie z tą kwestią. Jeśli
> dobrze rozumiem to można wybrać jak ma się zachować stos. W przypadku
> zgubienia któregoś z pakietów w sekwencji można albo trzymać nadmiarowe
> do momentu otrzymania brakującego, albo poprosić jeszcze raz o wysłanie
> całej sekwencji licząc, że tym razem przyjdą wszystkie i po kolei.
> Próbowałem obydwu ustawień.

Tak ogolnie TCP dziala tak, ze jak znikl jeden pakiet, to trzeba go
retransmitowac. A po nim wysylane sa ponownie wszystkie nastepne.

Po otrzymaniu pakietu "niekolejnego", stos odbiorczy byc moze moze
chwile poczekac - moze akurat "kolejny" przyjdzie, a nastepny juz
czeka w buforze.
Przy czym raczej nie podejrzewam, zeby niekolejne byly twoim
problemem.

> Swoją drogą, czy ktoś może mi wyjaśnić w jaki sposób skonfigurować lwIP,
> żeby mieć dostatecznie duży bufor odbiorczy? W stosie od Microchipa po
> prostu ustawiało się wielkość bufora nadawczego i odbiorczego dla
> konkretnego gniazda. Tutaj cała masa opcji, które nic mi wprost nie mówią...
>
> https://github.com/marekw1986/InternetRadioSTM32/blo
b/main/code/LWIP/Target/lwipopts.h

Nie znam, nie poradze.

J.