Protokół TCP/IP - duże czasy odpowiedzi ACK

Witam serdecznie forumowiczów!

Borykam się z problemem dość wolnej transmisji pomiędzy komputerem z systemem Linux a mikrokontrolerem Cortex-M3 gdzie zaimplementowane jest oprogramowanie pisane przeze mnie od zera.
Poniżej przedstawiam ramki z Wireshark, gdzie 2 z zawartością:

Ramka 280

Ramka 281

Potwierdzenie ACK z komputera często dochodzi po 40ms i tak plik ważący 1MB, przesyła się w nieskończoność...

Wcześniej miałem ten sam problem(ze strony elektroniki), ale przypadkowo zmniejszenie wysyłanych danych do ok 500B poprawiło sytuację(ok 2MB/s), lecz znów transfer spadł do ok 12,5KB/s (mierzone programem wget).
Podejrzewam, że "moje" ramki coś nie pasują komputerom(to samo na systemie Windows na innym komputerze).
Początkowo transmisja jest w setkach KB/s, po chwili stabilizuje się na 12,5KB/s przy wielkości pakietu ok 0,5KB i 25,6KB/s przy wielkości pakietu ok 1KB.
Na podglądzie widać że to nie problem z moją interpretacją TCP/IP, wysyłaniem i odbieraniem pakietów, lecz może coś pomijam i komputery trochę się fochają :(

Gdzie poszukiwać błąd? Co może być nie tak? Nie ma żadnych retransmisji, wszystko wygląda OK.

Znalazłem informacje, że jest to spowodowane poprzez "TCP delayed acknowledgment".
Ta metoda nie jest mi na rękę w prostej implementacji stosu TCP/IP. Musiałbym ją mocno rozbudować, gdzie nie jest to konieczne.
Czy jest możliwość wyłączenia tej opcji? Oczywiście odpada konfigurowanie systemu, nikomu z buta do domu wchodzić nie będę, aby przestawić opcje w systemie.
Może ustawienie innej wersji protokołu/flagi w wysyłanych ramkach?
Przeszukuję dalej internet... może ktoś coś na ten temat wie i pomoże mi z optymalizacją czasu spędzonego na poszukiwaniach....

Nie wiem czy o to Ci chodziło bo nie znam Twojej implementacji stosu ani co tam masz :-)
http://packetlife.net/blog/2011/mar/2/tcp-flags-psh-and-urg/

na SO piszą, że

so napisał(a)

Since Windows Vista, TCP_NODELAY option must be set prior to calling connect, or (on the server) prior to calling listen. If you set TCP_NODELAY after calling connect, it will not actually disable Nagle algorithm, yet GetSocketOption will state that Nagle has been disabled! This all appears to be undocumented, and contradicts what many tutorials/articles on the subject teach.

With Nagle actually disabled, TCP delayed acknowledgements no longer cause latency.

Co do URG, czytałem że to jest takie rozwiązanie na granicy, ale jeszcze poczytam :) dzięki za podpowiedź :)

Dzięki abrakadaber, ale u mnie nie ma szans z tym pokombinować, na ARM'ie stoi serwer www ze stroną w flash która waży ok 300KB, a ładuje się ponad 40s.
Wchodząc przez przeglądarki, niestety mam opóźnione ACK w komunikacji, niezależnie od wielkości pakietów.

Początkowo testując przez przeglądarkę FF i Linuxa, nie widziałem żadnych problemów, strona ładowała się poniżej 0.5s.
Po skończeniu pisania i testując na innych systemach wyskoczyły takie cyrki. Pozostaje mi jakiś trik, albo cofnięcie się i przebudowanie stosu, dla działania tych kilku marnych KB...

Ja przed wysuwaniem jakichkolwiek wniosków przeprowadziłbym następujace testy:

1. Spiąć uC z PC-tem kablem LAN. Sprawdzić latency z ping-a (tutaj w ogóle omijamy warstwy od transportowej w górę). Jeśli wszystko OK sprawdzić latency z tcptraceroute (test warstwy transportowej a więc de facto TCP). Dodatkowo sprawdzić bandwidth narzędziami iperf.

2. Powtórzyć testy z pkt. 1 ale już w normalnej konfiguracji sieci.

Powyższe testy odpowiedzą ci na pytanie czy coś złego dzieje się w warstwie aplikacji czy może niżej.

Projekt stoi w miejscu, pingi mam na poziomie <1ms przy bezpośrednim połączeniu i przez sieć domową. Jest to na pewno sprawa techniki opóźnień ACK.
Początkowo pakiety dostają natychmiastowo odpowiedź, ale po pewnym czasie(plik jest duży), ACK trafia z opóźnieniem.
Tą samą sytuację widzę, gdy zrobię symulację pomiędzy 2 np. Linuksami, z tym że po tym pewnym czasie, wysyłane są po 2 pakiety a następnie przychodzi ACK.
Gdzieś widziałem opis tej techniki opóźnień, obliczane są czasy pomiędzy wymianą pakietów i na tej podstawie jest konfigurowany timer do odpowiedzi ACK.
Ta technika rodzi wiele pytań, co jeśli źle obliczę, co jeśli wyślę te 2 pakiety a w między czasie przyjdzie ACK z potwierdzeniem jednego pakietu, wg. mnie to taka ruletka, bardziej pojawia się w takiej komunikacji prawdopodobieństwo(i musi pojawić się retransmisja) niż logika. Przekopię źródła kernela linuxa to zrozumiem bardziej ten mechanizm, albo znajdę jakieś obejście.
Z braku czasu niestety projekt stoi.