Atlantis <m...@w...pl> 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.
> 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.

To by wskazywalo na zbyt male bufory/okno danych. Sprzet wyraznie
moze pracowac szybciej, ale kontrola przeplywu TCP mu nie pozwala.
Ja bym sprawdzil co sie dzieje jak wywalisz caly kod odpowiedzialny
za dzwiek i zostawisz tylko odbior strumienia, ale potwierdzajac
w takim tempie (w przyblizeniu) jak kodek by je odbieral.

Jeszcze moze glupie pytanie: w jakim tempie piszesz/czytasz ten
RAM SPI? DMA powinno przerzucac dane z maksymalna predkoscia
SPI, ale RAM moze miec porabany protokol a jak go obsluzysz
przez software to moga byc straty predkosci.

> 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.

Pytanie kiedy potwierdzasz odbior: przed czy po zapisie do SPI
RAM. Jesli po to potwierdzenie jest opoznione i efektywnie
zmniejsza dostepne okno.

> 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?
> bufor/okno odbiorcze) i dochodzi do retransmisji, kt?ra spowalnia realn?
> pr?dko?? przesy?u danych.

Pisales ze jest 6kB na bufory LWIP. To 4 pakiety maksymalnej
wielkosci. Jesli 1 to wlasnie odbierany pakiet (nie wiem
czy LWIP ma na niego oddzielny bufor) a 1 to pakiet ktory
przerabiasz to zostaja 2 pakiety na buforowanie. Zaleznie
od szybkosci to moze byc 250-150 ms buforowania. Niby moze
dzialac ale ma prawo sie rwac.

Piszesz o jakims "buforze audio". Nie wiem co to ma byc,
ale datasheet VS1003 mowi o przesylaniu bloku 32 bajtow,
czyli w zasadzie jesli jest portrzebny jakis bufor to
na poziomie max setek bajtow. Czyli pownny byc dziesiatki
kilobajtow wolnej pamieci: STM32F107 ma 64KB RAM.

Moim zdaniem rozsadny projekt przydzielilby duzy kawalek
pamieci dla LWIP. Tak na oko minimum 15KB (10 pakietow
maksymalnej wielkosci). Przy 64KB RAM powinno byc
mozliwe przydzielnie LWIP 40KB (zwykle przyjmuje sie ze
implementacja TCP potrzebuje minimalnie 40KB do pracy,
ty masz jeden strumien a LWIP powinien byc oszczedny,
wiec moze bedzie dzialalo z mniejsza iloscia).

Przeplyw danych powiniem byc nastepujacy:

ETH -> bufor LWIP -> VS1003

Ewentualnie buforek powiedzmy 256 bajtow dla DMA pomiedzy
STM a VS1003 (taki buforek, podzielony na polowki po 128
bajtow wystarcza zeby DMA pracowalo plynnie).

> I teraz mam kilka pyta? co do tego, jak w?a?ciwie dzia?a Ethernet w STM32:
> Samo pobieranie danych z sieci do bufora odbiorczego jest realizowane w
> tle przez sprz?t, czy te? p?tla g??wna programu musi regularnie
> wywo?ywa? jaki? sterownik? To znaczy je?li bufor odbiorczy jest
> dostatecznie du?y, to dane b?d? nadal dochodzi?y nawet wtedy, je?li
> p?tla g??wna b?dzie zaj?ta czym? innym?

Ethernet ma swoje DMA ktore wrzuca pakiet do pamieci. Jak sie
dzieje cos co wymaga uwagi procka to zglasza przerwania.
Ten interfejs moze wrzucic dane do listy buforow (nie trzeba
jednego ciaglego bufora). Czyli jak sa dostepne bufory
to jest minimalne obciazenie procka. Ale kluczem jest
dostepnosc buforow. Nie wiem jak to rozwiazuje LWIP.
Jedna mozliwosc to kolejka buforow uzupelniana przez
petle glowna, wtedy procedura obslugi przerwania pobiera
bufory z kolejki (o ile sa dostepne). Ale mozna to
robic inaczej.

Jeszcze jedna uwaga: w STM transmisje danych powinno
robic DMA. "Dogladac" DMA powinny procedury obsugi
przerwan. Normalny kod powinien sledzic stan polaczenia
TCP, przygotowywac pakiety potwierdzenia (to robi LWIP)
i robic zarzadanie "wysokopoziomowe". Wiekszosc
operacji "petli glownej" powinna byc malo krytyczna
czasowo. Najwiecej uwagi moim zdaniem wymaga generowanie
potwierdzen (czyli wywolanie 'tcp_recved'), tak zeby
miec wlasciwa wielkosc okna TCP.

--
Waldek Hebisch