Hallo, welche Datenrate (Ethernet) bekommt ein AT91SAM9263 200MHz Prozessor (SDRAM 100MHz Anbindung für die weiteren Bearbeitungsschritte) ungefähr abgearbeitet? So dass man die Daten der UDP-Pkts auf Richtigkeit überprüfen kann + Weiterverarbeitung der Daten? Sind 350 Ethernet Packets pro Sekunde mit ca. 600 Byte zu viel des Guten? Die DMA wird damit keine Probleme haben... aber ist es realistisch, dass die Abarbeitungszeit (Software) lang genug ist (uiP etc. )? Gruß Bernd
Hallo Bernd, ich experimentiere gerade mit einem Luminary-Cortex mit 50Mhz rum. Bei einem 3.125kHz Timerinterrupt mit 55byte schaffe ich immerhin 30%-40% Prozessorauslastung. Alles UDP mit LWIP. Das ist allerdings nur senden, Empfang mache ich momentan auf der PC-Seite, da kommt auch alles an (ich habe nur einen Zähler inkrementiert und mit netcat das ganze angezeigt) Ich übetrage die Werte zwar im lesbaren Format, aber in HEX, da die Konvertierung von int nach HEX-String schneller ist. Der Test mit dem Empfang steht noch aus, da ich noch keinen loopback beim lwip hinbekommen habe. Den PC als Sender zu missbrauchen, scheitert an meinen TCPIP-Fähigkeiten bei der PC-Programmierung. Grüße Oliver
Zuerst hoert sich das mal nach gar nicht viel an, 350 Pakete pro Sekunde und 600 Byte, das das kommt immerhin auf eine Nettodatenrate von fast 2 Mbit/sec. Ist auf jeden Fall zu machen auch Ueberpruefung auf Richtigkeit und auch eine (un)gewissen Weiterverarbeitung, doch in der Weitervearbeitung liegt der Hund begraben. Ist das eine Routine die 100 Zyklen oder 1000 Zyklen oder nocvh mehr pro Datenpaket braucht? Bin ueberzeugt, Du weisst worauf ich raus will. Also die Weiterverarbeitung braucht noch eine genauere Definition. Grundsaetzlich geht's mit diesem Chip, der ist recht flott unterwegs. Gruss, Robert
>Ist das eine Routine die 100 Zyklen oder 1000 Zyklen oder nocvh mehr pro >Datenpaket braucht? Bin ueberzeugt, Du weisst worauf ich raus will. Allerdings, hab bereits ein paar Routinen gefunden, die sehr viel Zeit in Anspruch nehmen - z.B. die UDP Checksum Überprüfung für ankommende Pakete dauert bei mir ca. 700µs. Ohne dieser Überprüfung hab ich eine Verarbeitungsdauer von 550µs pro Paket. Kennt jmd eine schnelle UDP-Checksummenüberprüfung? Gruß Bernd
Schneller als was? Ausserdem ist sie optional: http://www.freesoft.org/CIE/RFC/1122/79.htm, wenn's also sehr darauf ankommt kann man sie abschaltbar gestalten.
Grob überschlagen: 100MHz mal 700µs durch 400 Worte (<1600 Bytes) ergibt für die Checksum-Routine 175 Takte pro Wort. Ist die in interpretiertem Basic programmiert? Voll durchoptimiert mit passendem Alignment sollten unter 3 Takte pro Wort drin sein, mit einfacher C Routine und fehlendem Alignment vielleicht das 3-4fache.
Hoppla, sind ja sogar 200MHz und nur 600 Bytes. Also 933 Takte pro Wort. Reife Leistung.
hab hier mal die Checksumm Berechnung.
1 | unsigned short udp_sum_calc(unsigned short len_udp, unsigned char src_addr[],unsigned char dest_addr[], |
2 | unsigned char padding, unsigned char buff[]) |
3 | {
|
4 | unsigned short prot_udp=17; |
5 | unsigned short padd=0; |
6 | unsigned short word16; |
7 | unsigned short sum, i; |
8 | |
9 | // Find out if the length of data is even or odd number. If odd,
|
10 | // add a padding byte = 0 at the end of packet
|
11 | if (padding&1==1){ |
12 | padd=1; |
13 | buff[len_udp]=0; |
14 | }
|
15 | |
16 | //initialize sum to zero
|
17 | sum=0; |
18 | |
19 | // make 16 bit words out of every two adjacent 8 bit words and
|
20 | // calculate the sum of all 16 vit words
|
21 | for (i=0;i<len_udp+padd;i=i+2){ |
22 | word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF); |
23 | sum = sum + (unsigned int)word16; |
24 | }
|
25 | // add the UDP pseudo header which contains the IP source and destinationn addresses
|
26 | for (i=0;i<4;i=i+2){ |
27 | word16 =((src_addr[i]<<8)&0xFF00)+(src_addr[i+1]&0xFF); |
28 | sum=sum+word16; |
29 | }
|
30 | for (i=0;i<4;i=i+2){ |
31 | word16 =((dest_addr[i]<<8)&0xFF00)+(dest_addr[i+1]&0xFF); |
32 | sum=sum+word16; |
33 | }
|
34 | // the protocol number and the length of the UDP packet
|
35 | sum = sum + prot_udp + len_udp; |
36 | |
37 | // keep only the last 16 bits of the 32 bit calculated sum and add the carries
|
38 | while (sum>>16) |
39 | sum = (sum & 0xFFFF)+(sum >> 16); |
40 | |
41 | // Take the one's complement of sum
|
42 | sum = ~sum; |
43 | |
44 | return ((unsigned short) sum); |
45 | }
|
Woher kommt dieser Code? Er sieht zwar ansatzweise wie der Standardcode aus, ist aber erstens hinsichtlich der verwendeten Datentypen auf möglich geringe Effizienz optimiert ("unsigned short" für alle Vars ist eher ungünstig) und zweitens aus dem gleiche Grund nicht korrekt. Denn wenn man diese Einerkomplement-Addition mangels Addition mit Übertrag in C 16bittig derchführt, dann darf die Summe "sum" nicht 16bittig sein. Was im Kommentar auch noch ausdrücklich drinsteht. Immerhin landen in der oberen Hälfte die fehlenden Überträge, die abschliessend reinaddiert werden. Und die dafür verwendete while-Schleife heisst hier tatsächlich while(0), was eigentlich auch schon der Compiler merken sollte. Aber so oder so, richtig oder falsch, optimiert oder nicht: Das kann bei 200MHz keine 700µs dauern. Nicht einmal ohne Compiler-Optimierung.
Wenn ein gerne weisst was du tust statt nur abzuschreiben und dafür bischen Futter für's Hirn suchst, lies mal http://wwwse.inf.tu-dresden.de/data/courses/SE1/exercises/se_ws0405_exercise8_tcp_checksum.pdf durch. Beschreibt zwar TCP, aber der Algorithmus ist der gleiche. Einerkomplement-Addition ist halt etwas ungewohnt.
vielen Dank für den Artikel - vom Prinzip her funktioniert der Algo in dieser Form.
1 | unsigned short prot_udp=17; |
2 | unsigned short padd=0; |
Diese beiden Variablen hab ich noch als unsigned char definiert. Und while(0) hab ich ebenfalls geschrieben. Gibt es sonst noch Möglichkeiten diesen Algorithmus zu verbessern? Gruß Bernd
Bernd Schuster schrieb: > Diese beiden Variablen hab ich noch als unsigned char definiert. Und > while(0) hab ich ebenfalls geschrieben. Sorry, entweder habe ich dich hier missverstanden, oder du hast absolut nichts von dem verstanden was ich schrieb und was diese Prüfsumme tut. Wieviel Ahnung hast du von C und von Programmierung generell? Bevor du an Optimierung gehst, krieg das erst einmal korrekt zustande. Es gibt genug korrekten Sample-Code. Vor allem solltest du verstehen wie diese Prüfsumme arbeitet. Sonst wird das mit einer Optimierung nichts und du programmierst bloss im Blindflug.
>Sorry, entweder habe ich dich hier missverstanden, oder du hast absolut >nichts von dem verstanden was ich schrieb und was diese Prüfsumme tut. Ich hab schon verstanden, dass die sum eigentlich unsigned int sein muss, allerdings sind bei mir die ankommenden Pkts und transmit pkts sehr identisch, und es gibt keinen Übertrag bei der Checksum-Bildung (auf den du mich hingewiesen hast) und als optimierung für dieses Bsp. hab ich dann die while() Schleife komplett rausgenommen. Bei while(0) ist diese vom Compiler ebenfalls natürlich nicht vorhanden. Gruß Bernd
Bernd Schuster schrieb: > sehr identisch, und es gibt keinen Übertrag bei der Checksum-Bildung > (auf den du mich hingewiesen hast) Den gibt es nur dann garantiert nicht, wenn der Inhalt durchweg 0 ist, oder sowas in der Art. Da der Header mit drin ist kann das aber schlecht sein.
Und zur Optimierung von Datentypen: Ein ARM rechnet wie alle 32bit RISCs in Registern mit 32bit insgesamt schneller als mit 8/16bit Datentypen.
>Und zur Optimierung von Datentypen: Ein ARM rechnet wie alle 32bit RISCs >in Registern mit 32bit insgesamt schneller als mit 8/16bit Datentypen. Verwendet ein ARM bei einer char / short Variable ebenfalls den Speicherplatz von 32Bit und fügt eine zusätzliche Operation hinzu beim Zugriff auf eine solcher Variable (Speicherbereich)? Gruß Bernd
Im Speicher nicht. Allerdings kann es alignmentbedingt Verschnitt geben. Und lokale Variablen und Parameter landen tendentiell eher in Registern. Auch im Speicher sind 32bit Vars in Laufzeit nicht teuerer als 8/16bit (x86: billiger).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.