UDP adatküldés sorrend vagy késleltetési / adattömbösítési probléma lehetséges Windowson?

Nem én írom a Windowsos programot, de ezek kb. 1 kB-os csomagok és 16 körül van belőle (+2 kisebb).

Annyira nem tűnik sok adatnak még úgy sem, ha másodpercenként 20 képet küldenénk is, viszont ritkább adatküldés esetén átmegy hiba nélkül.

Ergo az adat belefér a bufferbe, azt viszont kifejezetten nem várnám, hogy csináljon rá a rendszer mondjuk egy 100 ms-os időzítést és aggregálva küldje ki az adott csomagokat.
...ahogy azt sem, hogy valami oknál fogva más sorrendben indítsa.

Azt nem tudom persze, hogy pontosan mi történik, csak gyanú részemről, de kb. 10 FPS-ig működik is a lassabb gépen.

Nem írtam, hogy static wait-ek vannak benne.

Csinál az a program mást is, csak a kijelző felé is küld bizonyos adatokat adott időközönként.

Igen, adott esetben a helyszínen meg lehet próbálni.

Egyébként én arra gondoltam, hogy a kijelző elektronika helyére tennék egy gépet és azon hallgatok, majd utána azt elemzem... de messze van tőlem most és lassabb küldéssel amúgy működik, csak izgatna azért, mi történik valójában a háttérben (alapjában véve elégedettek a mostani működéssel is).

Ezért gondoltam, hogy esetleg, ha létezik valamiféle beállítás Windowson belül erre vonatkozóan, azzal még lehetne tenni egy kört egyszerűbben, vagy más tapasztalata alapján előbbre jutok vele, de lehet, előbb lesz kipróbálva a másik protokollal, ahol x,y koordináták is szerepelnek az adatcsomagban mint eljutnánk oda, hogy fizikailag is elemezve legyen a forgalom.

Nem garantálja.

Sőt, egy nagyobb hálózaton könnyen előfordul az is, hogy több valid útvonal létezik, és két, egymást követően indított csomag más útvonalon megy keresztül, végül a később elküldött csomag érkezik meg valamivel korábban.

Ebből még nem következik az, hogy adott gépen belül késleltetni kellene vagy összevárni csomagokat, ahogy Linux alól nem tapasztaltam és a gyorsabb gépen sem volt vele gond.

Tulajdonképpen helyi hálózaton belül, annak egy helyi szegmensén nem szabadna lennie különösebb adatvesztésnek sem, és nincs indoka sorrendcserének (ha ez a gond egyáltalán).

Nem én találtam ki, hogy UDP kapcsolat legyen, csak leprogramoztam a kontrolleren.
Ettől függetlenül nem kellene, hogy ilyen körülmények között gond legyen vele.

Használtam UDP adatküldést korábban, ahol az volt a fontos, hogy a mérési adatok a lehető legkisebb késleltetéssel érkezzenek meg a kontrollerről egy Linuxos kisgépre, ott pl. sohasem volt sorrendcsere és adatvesztés sem fordult elő.
Az Ethernet hálózat bonyolultsága gyakorlatilag azonos mindkét esetben.

Ismerem az UDP jellegzetességeit, ettől függetlenül értetlenül állok a jelenség előtt egy ilyen egyszerű hálózaton.

Ha a sorrendiség jelent gondot, arra van megoldás a rendszerben, csak használni kell - ettől még furcsa maga a jelenség.

Jó kérdés, az SO_SNDBUF mire van állítva, de amúgy a küldeni szándékozott adatok mérete <MTU.

Elméletileg UDP socketnél nem igazán szabadna összevárni csomagokat szerintem, mint ahogy szeletelgetni sem nagyon kellene (most MTU-nál kisebb esetre gondolok).
...mármint több üzenetből nem csinálhat egyet, de éppen küldheti őket adagonként, elrontva az időzítést.

Tulajdonképpen a gyorsabb, szerintem Windows 10-es gépen is egészen jól ment, a lassabb gépen Windows 7 dolgozott.

Ebben az üzemmódban valóban nincs megoldva a sorrendcsere vagy adatvesztés problémája, de ne felejtsük el, hogy nem internetes kommunikációra lett tervezve, hanem helyi hálózaton, helyiségen belüli megjelenítésre.

Az UDP nem végez különösebb hibakezelést saját maga, de viszonylag kis késleltetéseket tud cserébe.
...ahogy probléma is leginkább akkor lesz vele, amikor több hálózaton kell átjutnia.

...no de, hogy helyi hálózaton, gyakorlatilag 0 valós hibaforrás mellett is ennyire össze lehet kuszálni, azt nem gondoltam.

Szerk.: Itt egyébként azzal kezelhető a helyzet, ha olyan üzemmódban kap adatot, ahol maga a csomag tartalmazza a kezdőkoordinátát (van adatvizsgálat is amúgy), és egyébként a képadat következő újraküldésével van némi esély arra, hogy az előzőleg nem célba ért adat is megérkezzen - ez gyakorlatilag elfedi a dolgot.
Ugye a képfrissítést a kontroller végzi (folyamatosan dolgoznia kell vele), jelenleg csak az adatfrissítésről írtam, ami egy belső buffert tölt és Windows alól mintha némileg megbízhatatlanabb volna a dolog...

Mire gondolsz?

LAN-vezérlő driverénél lévő beállításokra?