On Sun, 2 Oct 2022 09:39:10 +0200, Atlantis wrote:
> Ok, dopisałem kilkanaście linijek kodu odpowiedzialnego za mierzenie
> ilości danych obieranych w serwera w ciągu sekundy. Po prostu sumuję
> każdą kolejną wartość p->tot_ten ze zmienną tymczasową, która co sekundę
> jest przepisywana do zmiennej trzymającej aktualną wartość pomiaru a
> potem zerowana.
>
> Przeprowadziłem dwa pomiary podczas odbierania streamu radiowej Jedynki.
> Pierwszy był przy zakomentowanych operacjach zapisy do pamięci SPI RAM.
> Wychodził transfer na poziomie 21-25 kB/s (czyli 168-200 kbps). Wartość
> zgodna z bitratem typowego strumienia audio.
> Natomiast po odkomentowaniu tych operacji wartość spada do 5-11 kB/s
> (40-88 kbps) co tłumaczy przerywany dźwięk.

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.

> Nie wiem na ile to ma znaczenie, ale dodatkowo widać, że w obydwu
> przypadkach na początku transmisja jest nieco szybsza i po kilku
> sekundach stabilizuje się wokół niższej wartości.

Ogolna zasada TCP - serwer wysyla na początku kilka pakietow danych,
dokladnie to TCP_window bajtow, a potem czeka na potwierdzenie
pierwszego.
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.

> Generalnie można już wyciągnąć kilka wniosków:
> 1. Można całkowicie odrzucić tezę, że winę za spowolnienia ponosi
> projekt płytki i gubienie pakietów z powodu błędów na warstwie
> sprzętowej (interfejs RMII). Gdyby tak było, to efekt byłby widoczny
> cały czas.
> 2. Operacja zapisu do pamięci SPI RAM ma wpływ na szybkość transferu
> danych. Jednak nie jest to raczej prosta zależność na zasadzie pamięci
> mającej niewystarczającą szybkość. Jak już mówiłem - ten bufor
> całkowicie normalnie działa z lokalnymi nośnikami, poza tym przy
> prędkości taktowania 18 MHz powinno być możliwe przesyłanie danych ze
> znacznie większą prędkością niż tych kilka kB/s. Poza tym problemy
> występowały też w przypadku stosowania (dużo mniejszego) bufora w
> normalnej pamięci.
>
> Na chwilę obecną stawiałbym raczej na moją oryginalną tezę: w czasie gdy
> program jest zajęty zapisywaniem oryginalnego pakietu, Ethernet nie jest
> w stanie odebrać następnej porcji danych (bo kończy mu się jakiś

Z grubsza mozliwe, ale patrz nizej.
A moze przerwania sa blokowane ?

> bufor/okno odbiorcze) i dochodzi do retransmisji, która spowalnia realną
> prędkość przesyłu danych.

Troche wątpie. Przy zgubieniu pakietu timeout sie wlacza, i to mogą
byc grube sekundy. Chyba bys nie uzyskal 5-11 kB/s.
No chyba, ze radio ma domyslnie jakies krotsze czasy.
Algorytm doboru timeoutu w TCP dosc skomplikowany ...
ale moze mozesz u siebie przetestowac - zasymuluj np zgubienie co
setnego pakietu.

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?

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 ?

Ba, bez zadnych retransmisji moga przyjsc pakiety w kolejnosci
1, 2, 3, 5, 4, 6, 8, 7, itp.

J.