Ethernet komunikace - PC UDP server problém

[Wolfik]

Je tu už ode mne měsíc staré vlákno se souvisejícím tématem, ale raději zakládám nový...

Krátký brýfýnk: mám vývojový kit s AD převodníkem a fpgačkem připojený k PC přes ethernet. Na PC chci posílat bursty dat - UDP pakety obsahující offset a vzorky z AD převodníku.
Do teď jsem blbnul na straně PC s Wiresharkem a utilitkou Packet sender a vše vypadalo ok.

Chtěl jsem si na straně PC udělat nějaké základní zpracování v Matlabu, tak jsem z dostupných materiálů (http://www.binarytides.com/udp-socket-programming-in-winsock/) na straně PC udělal přes widláckou knihovnu Winsock primitivní UDP server - v nekonečné smyčce přes recvfrom tahám data a ty chci ukládat do textového souboru, který pak sežere Matlab/Octave.

Problém je, že tahle jednoduchá aplikace nechytá všechny UDP datagramy. Počítal jsem s nějakou ztrátovostí, ale 50% je prostě moc. Nechápu proč třeba sniffer jako Wireshark mi pakety zachytí všechny - v nejhorším případě bych to mohlo logovat z něho a pak ten soubor přebastlit pro matlab, ale to je krapec na nic...

Částečným řešením je snížit datovou rychlost z kitu - dát zpoždění mezi odesíláním jednotlivých paketů. Potom server zachytí všechno.
Zatím nemám problém s dosažením požadované rychlosti - z principu funkce cílová aplikace potřebuje např navzorkovat 100-200ms každou sekundu, takže ve zbývajícím čase je dostatek času na nějaký výpočetní výkon...jen mě irituje proč ten Wireshark chytá vše (ještě s analýzou datagramu) a primitivní kód v Cčku inkrementující jen čítač zachycených udp paketů na určitém port mi zachytí cca polovinu paketů.

Tušíte někdo, čím by to mohlo být?

[mtajovsky]

Těžko hádat bez znalosti zdrojáku, ale obecně není dobré řešit komunikační věci ve stejném vlákně, ve kterém běží GUI. Vždycky jsem to dělal v samostatném vlákně a mezi nimi je komunikace přes frontu chráněnou kritickou sekcí (a případně doplněnou ještě semaforem jako čítačem zpráv ve frontě).

[mtajovsky]

Těžko hádat bez znalosti zdrojáku, ale obecně není dobré řešit komunikační věci ve stejném vlákně, ve kterém běží GUI. Vždycky jsem to dělal v samostatném vlákně a mezi nimi je komunikace přes frontu chráněnou kritickou sekcí (a případně doplněnou ještě semaforem jako čítačem zpráv ve frontě).

[Wolfik]

už jsem to částečně pořešil...podcenil jsem náročnost funkce printf, kde jsem si vypisoval hodnotu čítače přijatých paketů.

Na straně PC jsem jen upravoval zdroják pro Winsock odtud - http://www.binarytides.com/udp-socket-programming-in-winsock/

Potřeboval jsem to jen pro svoji potřebuju, pač cílovou aplikaci na PC bude později dělat někdo jiný.
Já jsem většinu Céčkovskej zdrojáků psal pro embedded zařízení, takže nějaké vícevláknové/procesové záležitosti jsou pro mě vyšší dívčí (pokud nepočítám FreeRTOS), ale tohle je jeden z případů, kdy narážím na nedostatek skillu napsat si něco jednoučelové v Javě/C++. Uvažuju, že místo učení C++/Javy se vrhnu spíš na Python - viděl jsem lidi, co dokázali bez předchozích znalostí po měsíci programovat vícevláknové síťové aplikace
v C++ jsem byl rád, když jsem zprovoznil pitomej GUI seriovej terminál v QT frameworku.

[mtajovsky]

Namísto funkce printf(), která se uvažuje jako jedna z nejkomplexnějších funkcí, stačí jednodušší

char * itoa ( int value, char * str, int base );

nebo použít C++ streamy.

Nicméně, jako největší brzdu vidím ne samotnou printf(), ale vlastní výpis na obrazovku ve Windows. On ten znakový výstup do konsole je de facto pořád grafický. Zkus to posílat do souboru pomocí fprintf(). Je to pak několikrát rychlejší.

[mtajovsky]

Namísto funkce printf(), která se uvažuje jako jedna z nejkomplexnějších funkcí, stačí jednodušší

char * itoa ( int value, char * str, int base );

nebo použít C++ streamy.

Nicméně, jako největší brzdu vidím ne samotnou printf(), ale vlastní výpis na obrazovku ve Windows. On ten znakový výstup do konsole je de facto pořád grafický. Zkus to posílat do souboru pomocí fprintf(). Je to pak několikrát rychlejší.

[Wolfik]

No nakonec opouštíme UDP komunikaci, protože pro cílovou aplikaci je nespolehlivá - jedna věc jsou ztráty paketů, druhá věc jsou duplikace, takže odhadovaná celková ztrátovost je nad limitem, co jsme si stanovili.

Než se drbat s aplikačním protokolem, co by realizoval na další UPD lince nějaké potvrzování přijatých bloků dat, tak se raději rovnou přesouváme k TCPčku

jen pro zajímavost o co jde:
jedná se o embedded zařízení využívající ARMovský procesor v FPGAčku.
Inženýři z Xilinxu v apliakční poznámce xap1026 zveřejnili měření přenosové rychlosti TCP komunikace na různých platformách. Když jsem to porovnával s tím, čeho jsem dosáhl UPDčkem, tak jsem si použitím UDP přilepšil o cca 10-20% rychlosti oproti TCP...