Hallo allerseits,
ich habe vor ein kleines Projekt mit einem Controller durch zu führen.
Hauptbestandteil dabei ist viele Daten über einen UPD Socket zu
verschicken. Die einzelnen UDP Packete haben etwa eine größe von 50
Bytes. Der Controller soll es schaffen weit über 1000 Telegramm zu
empfangen zu bearbeiten und ca 50 Telegramm zu senden.
Jetzt habe ich schon ein Test mit Controller durch geführt und musste
natürlich fest stellen das dieser meinen Anforderungen nicht genügt.
Um nicht noch maßig Zeit und Controller zu verschwenden würde ich gerne
als nächstes einen Controller wählen der meinen Anforderungen genügt.
Derzeit überlege ich einen Dimm Pc mit ca 200 Mhz zu nehmen. Allerdings
habe ich nicht einen blassen schimmer ob der es bringt.
Welches OS ist für solch eine Aufgabe geeignet. Bremsen mich Os wie
yLinux oder WinCe 6.0 zu stark aus?.
Würde mich sehr über eure Antworten freuen.
Schöne Grüße
@ Tom (Gast)
>verschicken. Die einzelnen UDP Packete haben etwa eine größe von 50>Bytes. Der Controller soll es schaffen weit über 1000 Telegramm zu>empfangen zu bearbeiten und ca 50 Telegramm zu senden.
Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig?
>Derzeit überlege ich einen Dimm Pc mit ca 200 Mhz zu nehmen. Allerdings>habe ich nicht einen blassen schimmer ob der es bringt.
???
So eine DIMM Speicherriegel kann man nicht ohen weiteres an einen uC
anschliessen.
>Welches OS ist für solch eine Aufgabe geeignet. Bremsen mich Os wie>yLinux oder WinCe 6.0 zu stark aus?.
Naja, kommt drauf an was sonst noch gemacht werden soll.
MFg
Falk
Hallo,
wow das ging aber jetz mal schnell. Vielen Dank schonmal für die Antwort
-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig?
Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein!
mehr wäre mir aber lieber. Optimal wären 300KByte. Aber Achtung die
Datenrate hängt stark von der größe der UDP Telegramme ab! D.h ein
Controller der 1000KByte bei einer Datengröße von 1000 Byte schafft,
schafft bei einer größe von 50 Byte eine wesentlich geringere
Datenrate!!!
-So eine DIMM Speicherriegel kann man nicht ohen weiteres an einen uC
anschliessen.
Meinte keinen Speicher sonder einen Controller der auf eine Checkkarten
großen Karte sitzt und auf einen Dimm Sockel gesteckt werden kann
wie z.B
http://de.kontron.com/index.php?id=82&cat=34
-Naja, kommt drauf an was sonst noch gemacht werden soll.
Schätzungsweise
-10 Task
-10 Queus
-10 Semaphoren
-4 UARTs mit Treiber
-Webserver
-ftp Server
-logik
sollte also noch ein bisschen Platz sein.
Kennt jemand Performance Statistiken von senden und empfangen von UDP
Telegrammen? Wie berechnet man so etwas
Schöne Grüße
@ Andi (Gast)
>-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig?>Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein!
IN WELCHER ZEIT? 1 Sekunde oder eine Stunde?
>http://de.kontron.com/index.php?id=82&cat=34
Nett.
>Schätzungsweise>-10 Task>-10 Queus>-10 Semaphoren>-4 UARTs mit Treiber>-Webserver>-ftp Server>-logik
Was sollen den die Task machen? Und was soll mit den 50kB UDP Daten
passieren?
Ich würde mal schätzen, dass so ein 133MHz Mini-PC mit schlankem OS das
recht gut hinbekommen sollte.
MFG
Falk
>-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig?>Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein!
Hi,
>-Macht 50kB in RX Richtung. In welcher Zeit? Gleichzeitig?>Ja richtig. Dies muss aber nicht unbedingt gleichzeitig sein!
1 Sekunde. Sonst wäre es ja zu einfach
>Schätzungsweise>-10 Task>-10 Queus>-10 Semaphoren>-4 UARTs mit Treiber>-Webserver>-ftp Server>-logik
Was sollen den die Task machen? Und was soll mit den 50kB UDP Daten
passieren?
Task/Queus/Semaphoren sind für die UARTs und den eigentlichen Empfang
und senden von Daten.(und noch ein paar andere Kleinigkeiten).
Es werden Daten von UDP über die seriellen Schnittstellen und umgekehrt
gesendet. Dabei erfolgt noch ein bisschen Konvertierung der Daten mehr
aber nicht!!
ftp und web sind mehr zur Konfiguration!
Schöne Grüße
@ Andi (Gast)
>Task/Queus/Semaphoren sind für die UARTs und den eigentlichen Empfang>und senden von Daten.(und noch ein paar andere Kleinigkeiten).>Es werden Daten von UDP über die seriellen Schnittstellen und umgekehrt>gesendet. Dabei erfolgt noch ein bisschen Konvertierung der Daten mehr>aber nicht!!
Na wenn DAS ein 133 MHz Prozessor nicht gebacken kriegt dann weiss ich
es auch nicht. Das ist 1 Paket/ms. Das sind 133000 Takte! Die UARTs
sollten FIFOs haben, ist aber glaub ich heute selbstverständlich.
>ftp und web sind mehr zur Konfiguration!
Also Nebensache und kann eher langsam sein.
MFG
Falk
Hi,
mhh ja rein Gefühls mäßig hätte ich das auch gedacht. Aber zum Beispiel
der Beck IPC mit 96 Mhz
http://www.beck-ipc.com/de/products/sc2x/index.asp
schafft keine 1000 Telegramme pro Sekunde.
Das Probelm ist nun, bevor ich mir eine neue Plattform aussuche würde
ich mir gern recht sicher sein, dass es funktioniert.
Schöne Grüße
@ Andi (Gast)
>mhh ja rein Gefühls mäßig hätte ich das auch gedacht. Aber zum Beispiel>der Beck IPC mit 96 Mhz>http://www.beck-ipc.com/de/products/sc2x/index.asp>schafft keine 1000 Telegramme pro Sekunde.
Naja. Was ist das denn für ein Prozessor? AFAIK ein 386er im
Kleinformat. Kommt dann auch auf das OS und die restliche Software an,
und, was denn genau mit den Paketen gemacht werden muss (volle UPD
Verarbeitung, Prüfsummen etc.)
Naja, die frage ist nicht einfach zu beantworten.
>Das Probelm ist nun, bevor ich mir eine neue Plattform aussuche würde>ich mir gern recht sicher sein, dass es funktioniert.
Wenn es soooo einfach wäre . . .;-)
MFG
Falk
Na dann mach mal....
1000 Telegramme ist schon einiges,
aber die Kenndaten spielen ja auch noch mit:
Wie schnell ist denn Dein Ethernet ?
Wer ist noch auf dem Segment unterwegs ?
Wenn die Rahmenbedingungen nicht stimmen,
dann kannst Du nicht sicher sein, dass es überhaupt so
funktioniert.
Lass Dich aber nicht entmutigen, vielleicht geht es ja doch.
Hallo Falk,
du hast recht die Frage ist eben nicht ganz einfach zu beantworten!
Welche Prozessor im Beck Ipc enthalten ist weiß ich leider nicht!
Um das ganze mal ein bisschen einzuschränken. Sagen wir mal die CPU soll
nach empfang eines UDP Telegramms dieses koppieren und sofort wieder
über UDP verschicken.
Um das UDP Protokoll an sich möchte ich mich eigentlich nicht kümmern.
Das soll das OD machen. WinCE oder Linux.
Schöne Grüße
@ Andi (Gast)
>Um das UDP Protokoll an sich möchte ich mich eigentlich nicht kümmern.>Das soll das OD machen. WinCE oder Linux.
Dann hilft nur eins. System kaufen und messen.
MFg
Falk
Hallo,
du könntest einen ARM9 benutzen. z.B. die von ATMEL. Sind für solche
Spielereien auf alle Fälle ausreichend.
Hier gibt es fertige Boards:
http://www.taskit.de/produkte/portux/index.htm
Am besten suchst du mal nach AT91RM9200 und schaust ob z.b. Linux für
das Board portiert wurde.
es hängt auch viel von dem OS ab. Wenn man das umgeht und die Pakete
selber verschickt schafft man auch 2000 pro s auf einem 386er mit 25Mhz
(das sind die Eckdaten einer Customhardware die wir einsetzen). Mit
WindowsCE auf X86 Basis klappt das auch ganz gut, aber auch hier gehts
schneller wenn man nicht durch den OS IP Stack laufen muß.
Wenn man kleine Pakete hat die in einen Ethernetframe passen und man
sich nicht um Fragmentierung kümmern muß ist es auch nicht so schwierig
die UDP Datagramme selber zu bauen.
@ Andi (Gast)
>ja gut. Aber reicht nun Arm mit 200Mhz und Linux für die Anwendung???>Das ist meine Frage.
Die wird sie kaum jemand wirklich beantworten können.
MfG
Falk
Hallo JojoS,
intressant!!!! Vielen Dank schonmal für die Informationen vor weg. Ich
glaube das hat mir ganz schön geholgen: Dennoch habe ich nun einiege
Fragen.
-Was ist Fragmentierung
-Woher weißt Du das??
-Wenn Packete selber verschickt und erstellt, dann muss es doch das OS
auch unterstützen selber Packete zu verschicken uns zu senden oder?
Wie programmiert man so etwas. Kennst Du Beispiele für zum Beispiel
linux oder Win CE?
-Was macht das Os dann noch, dass das direkte schicken so viel schneller
ist
Vielen Dank schonmal für die Beantwortung der Fragen und Schöne Grüße
@ Andi (Gast)
>ja gut. Aber reicht nun Arm mit 200Mhz und Linux für die Anwendung???>Das ist meine Frage.
- 1000 x 50 Byte INPUT
- work
- 50 x 50 Byte OUTPUT
Was machst du mit den empfangenen Daten ? Wenn das nicht soo viel ist
reicht mit Sicherheit auch eine andere 32bit CPU mit weniger MHz. Du
solltest vorher noch abklären ob du Fließkomma-Berechnungen benutzt und
in welchem Umfang.
Hallo ARM,
Fließkomma benötiege ich nicht. Alles nur Bit und Byte Operationen.
Diese sollen wie schon gesagt im wesentlichen dann auf die UARTs
gesendet werden.
Was mich aber nun doch noch mehr intressiert ist die Wahl des OS.
Derzeit hatte ich vor ein recht gut ausgebautes Os zu nehmen wie Linux
oder WinCe. Damit mit ich zum Beispiel mit dem FTP bzw Web Server nicht
so viel ärger haben.
Warum ich immer noch ein bisschen zweifle ist wegen der BeckIpc
geschichte.
Wenn Jojos wirklich recht hat und durch das um gehen des Betriebssystems
wesentlich mehr UDP Telegramme gesendet/empfangen werden können
intressiert mich dies schon enorm. Die Frage ist nur wie macht man das?
Schöne Grüße und Vielen Dank für die guten und hilfreichen Antworten
Hallo,
ich habe keine guten Erfahrungen mit dem BeckPC. Die Programmierung war
damals sehr eigen. Man brauchte ein uralt BorlandC und der Netzwerktest
war dann auch nicht so berauschend (vor ~3Jahren).
Falls du Linux benutzen willst, schau ob es ein BSP (Board Support
Package) gibt und welche Anwendungen (ftp/www ...) schon mit bei sind.
Linux/Windows Entwicklungsumgebung/Compiler .... . Falls du alles selber
bauen musst, kann das sehr abendfuellend werden und ist einem Anfänger
nicht zu empfehlen ! Wenn deine Wahl auf WinCE fällt, kannst du dich
schonmal drauf einstellen für die Entwicklungsumgebung etwas Geld zu
bezahlen.
Nachtrag:
>Wenn Jojos wirklich recht hat und durch das um gehen des Betriebssystems>wesentlich mehr UDP Telegramme gesendet/empfangen werden können>intressiert mich dies schon enorm. Die Frage ist nur wie macht man das?
Das kann ich mir beim BeckIpc gut vorstellen.
das UDP ist z.B. im Wikipedia einfach beschrieben. Ist eben 'nur' eine
Struktur von Headerdaten die man richtig ausfüllen muß. Beim UDP gibt es
ja kein Handshake oder irgendeine Fehlerkontrolle. Man bekommt höchstens
auf IP Level eine Antwort das die Gegenstelle keine Daten auf Port xy
erwartet wenn man ein System anfunkt wo keiner auf dem Port lauscht.
Die Fragmentierung kann bei der Weiterleitung der Pakete entstehen, z.B.
ist bei IP über ein Analogmodem die MTU kleiner als bei Ethernet und die
grösseren Frames müssen dann in kleinere aufgeteilt werden. Aber bei
reiner Ethernet Verbindung dürfte das keine Rolle spielen.
Im OS steckt im IP Stack eine ganze Menge mehr, z.B. die Prüfung der
Felder auf gültige Daten. Früher wurde das weniger gecheckt bis dann die
ganzen berühmten 'Denial of Service' Attacken kamen die solche Lücken
ausgenutzt haben. Dann gehen die Pakete ja evtl. noch durch eine
Firewall, werden verschiedenen Protokollen angeboten, werden vielleicht
mehrfach umkopiert usw.
Hallo,
ich komme mit 64Mhz 32Bit CPU/100Mbit Netz bei einer TCP-Verbindung auf
über 1MByte/sek. . Aja, Linux-Kernel 2.4.XX. . Ich sehe nur Probleme bei
sehr wenig Speicher, schlechter Netzwerkhardwareanbindung oder einer
sehr sehr langsamen CPU.
Was willste denn von einem OS ? Es sind im Wesentlich nur I/O
operationen. Vorne an den UDP noch einen Header dranpfriemeln sollte
nicht so schwer sein. Sollte eigentlich mit einem 20MHz AVR machbar
sein. Der macht in einer milisekunde 20k operationen. Da sollte man doch
noch 2 packete zu je 50 bye herumschieben koennen.
Weil es den Anforderungen von Tom nicht genügt ?
> Was mich aber nun doch noch mehr intressiert ist die Wahl des OS.> Derzeit hatte ich vor ein recht gut ausgebautes Os zu nehmen wie Linux> oder WinCe. Damit mit ich zum Beispiel mit dem FTP bzw Web Server nicht> so viel ärger haben.
Hallo,
also vielen Dank für die vielen Antworten
@6623
-Ich werde auf alle Fälle ein Board mit fertigem OS nehmen, damit ich
wenig äger haben und Threads, Queues, Semaphoren, Web, Ftp, DHSP,
etc....
@Arm
-"ich komme mit 64Mhz 32Bit CPU/100Mbit Netz bei einer TCP-Verbindung
auf
über 1MByte/sek. . Aja, Linux-Kernel 2.4.XX. . Ich sehe nur Probleme bei
sehr wenig Speicher, schlechter Netzwerkhardwareanbindung oder einer
sehr sehr langsamen CPU."
Das schafft der Beck Ipc auch bei extrem großen Datenpacketen. Wie groß
sind Deine Packete die Du verschickst?
@JojoS
Ok verstanden habe ich das jetzt. Was mir noch nicht ganz klar ist wie
die Implementierung erfolgt. z.B. bei Linux oder Win Ce. Denn das Os
wird ja keine Funktion haben wie send_raw_ip_packet oder? Wie kommt man
also direkt an die Schnittstelle ran ohne über den TCP/IP Stack zu
gehen. Kannst Du mie zum Beispiel für Linux ein Beispiel
geben/Literatur/Web links
Vielen Dank schonmal für eure Antworten und Schöne Grüße
bei WindowsCE muß man sich da mit NDIS und Miniport Treibern
beschäftigen. Wir haben das von einer externen Firma entwickeln lassen
und ich kenne die Details auch nicht.
http://msdn2.microsoft.com/en-us/library/ms895493.aspx ist vielleicht
ein Anfang, aber die CE Entwicklung ist nicht ganz trivial und man
braucht ein Board Support Package vom HW Hersteller. Der sollte auch
Tipps in Richtung Entwicklungsresourcen geben können.
Mit Linux kenne ich mich so gut wie garnicht aus, da müssen dir andere
weiterhelfen.
Und es gibt noch Libpcap / Winpcap, das sind Paket Capture / Sende
Funktionen für Linux und XP. Mit der C# Variante sharp-pcap baue ich
gerade einen Analyzer für die schnelle zyklische Datenübertragung mit
UDP. In der WinPCap Variante ist auch ein Beispiel für das Senden von
UDP Daten.
