SAM9263 Ethernet Performance

[Bernd S. (mms)]

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

[OR (Gast)]

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

[Robert T. (robertteufel)]

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

[Bernd S. (mms)]

>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

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Hoppla, sind ja sogar 200MHz und nur 600 Bytes. Also 933 Takte pro Wort. 
Reife Leistung.

[Bernd S. (mms)]

hab hier mal die Checksumm Berechnung.

unsigned short udp_sum_calc(unsigned short len_udp, unsigned char src_addr[],unsigned char dest_addr[], 
                unsigned char padding, unsigned char buff[])
{
  unsigned short prot_udp=17;
  unsigned short padd=0;
  unsigned short word16;
  unsigned short sum, i;  
  
  // Find out if the length of data is even or odd number. If odd,
  // add a padding byte = 0 at the end of packet
  if (padding&1==1){
    padd=1;
    buff[len_udp]=0;
  }
  
  //initialize sum to zero
  sum=0;
  
  // make 16 bit words out of every two adjacent 8 bit words and 
  // calculate the sum of all 16 vit words
  for (i=0;i<len_udp+padd;i=i+2){
    word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF);
    sum = sum + (unsigned int)word16;
  }  
  // add the UDP pseudo header which contains the IP source and destinationn addresses
  for (i=0;i<4;i=i+2){
    word16 =((src_addr[i]<<8)&0xFF00)+(src_addr[i+1]&0xFF);
    sum=sum+word16;  
  }
  for (i=0;i<4;i=i+2){
    word16 =((dest_addr[i]<<8)&0xFF00)+(dest_addr[i+1]&0xFF);
    sum=sum+word16;   
  }
  // the protocol number and the length of the UDP packet
  sum = sum + prot_udp + len_udp;

  // keep only the last 16 bits of the 32 bit calculated sum and add the carries
    while (sum>>16)
    sum = (sum & 0xFFFF)+(sum >> 16);
    
  // Take the one's complement of sum
  sum = ~sum;

return ((unsigned short) sum);
}

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Bernd S. (mms)]

vielen Dank für den Artikel - vom Prinzip her funktioniert der Algo in 
dieser Form.

unsigned short prot_udp=17;
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

[(prx) A. K. (prx)]

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.

[Bernd S. (mms)]

>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

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Und zur Optimierung von Datentypen: Ein ARM rechnet wie alle 32bit RISCs 
in Registern mit 32bit insgesamt schneller als mit 8/16bit Datentypen.

[Bernd S. (mms)]

>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

[(prx) A. K. (prx)]

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).