Moin!
08/15 hat folgendes geschrieben: |
Ich messe zur Zeit beim raussenden auf meinem chip 1190 CPU ticks was 1,19 sec entspricht. Bei 120000 / 1190 komme ich au 100,8 kB/s ... schaffen sollte das Protokoll laut hersteller in idealer Testumgebung aber 1085 kB/s. Das das nicht ganz zu erreichen ist erscheint mir logisch aber 10% von diesem Richtwert ist mir zu wenig  |
Ist das so ein embedded-device-server? Die sind nicht immer sooo schnell... Sicher, dass du die Doku korrekt verstanden hast (da die Werte ca. eine 10er-Potenz auseinanderliegen)?

(nicht aufregen bitte, wer nicht schonmal auf rtfm reingefallen ist, werfe den ersten Stein... ich hab hier nur Sand...

)
08/15 hat folgendes geschrieben: |
| Wo verursach ich meine Wartezeit? Hab ich etwas nicht bedacht? |
Das AsyncSelect der WSA, was hinter den Ereignissen steckt, ist jetzt nicht gerade der Turbo... allerdings Faktor 10 Verlust wäre jetzt schon etwas sehr viel...
08/15 hat folgendes geschrieben: |
| Wichtig ist auch das komplett alle Daten ankommen. Also fand ich TCP eher geeignet als wenn ich UDP nutze. |
Hm, bei Bildern müssen wirklich immer alle Zeilen ankommen?

Wenn du Einfluss auf das Protokoll hast, hätte ich sonst mal folgendes vorgeschlagen:
- nimm UDP (z.B. TUdpSockUtil

)
- Bau die Pakete so auf: AppID | PictureID | LineNo | Data, also praktisch immer eine Image-Zeile pro UDP-Paket
- Rest (reassembling usw.) machste im Empfänger (Delphi)
- wenn was nicht angekommen sein sollte (kannste ja über die IDs rausfinden), forderst du diese Zeilen nochmal an
Zumindest einen Test wert, oder?
08/15 hat folgendes geschrieben: |
Delphi scheint die 8192 als Standardwert irgendwo integriert zu haben wie mir scheint  |
Nicht Delphi, die WSA.
cu
Narses
There are 10 types of people - those who understand binary and those who don´t.