Hallo Leute, Ich wollte mal fragen wie "schnell" eurere RTL8019AS WebserveR sind? Dass FAT16 nicht gerade schnell auf nem AVR arbeitet weiß ich,aber ich glaub das liegt auch schon teilweise an dem C Code,aber auch an dem kleinen S-ram. Nun frag ich mich ob es nicht sinnvoller wäre das ganze in ASM zu machen, so en bissle selbstmassakrierung wie damals die Gameentwickler um 1993. Sodenn, der erste teil wäre softwaretechnisch 64K Sram einzubinden (hab noch welche aus der 486 prozessorzeit ;) Das wären wohl dann 2*32kbit*8 oder?Dann würde FAT oder ext2 besser funktionieren, da endlich genug Cache dawär. Würde man vll 40kb/s hinbekommen? Gruß Jens
Wie schnell muss er denn sein ? Was soll denn zur Verfuegung stellen ? Ich hab'n Webserver geschrieben, der haengt an der seriellen mit 9600. Fuer den passenden Einsatzzweck genuegend.
>Dass FAT16 nicht gerade schnell auf nem AVR arbeitet weiß ich,aber ich Das kommt auf deine FAT Routinen an. >Nun frag ich mich ob es nicht sinnvoller wäre das ganze in ASM zu >machen, >Würde man vll 40kb/s hinbekommen? Mit ner schnellen Karte kommt man in C auf >400kB/s.
Aber nie mit nem billigen 8bit rumpel"avr" Ja routinen scheinen langsam echt alles zu sein, gut dass man einige einfach downloaden kann...vorhin ne gute asm source gefunden die die netzwerkkarte RTL8019 verwursten kann Was brauch ich noch das ganze IPv4 gemöller meine kleine memoryerweiterung und noch en FAT in asm gruß jens
doppeltpost... sry der scherz ist hald dass ich asm einigermaßen kann... aber na ja C is für mich ein grauß wenn ich ganze zeit alles verklammern muss.. immer auffer großtaste und so bei asm meint man zu wissen was man tut und kann auch drauflosschreiben
Moderne Compiler optimieren ja bekanntlich recht gut, also liegt sowieso nur wenig Optimierungspotential drin. Einen kompletten Webserver in Assembler zu schreiben, darum würde ich einen weiten Bogen machen. Man denke nur an das Debuggen.
@ Jens (Gast) >Aber nie mit nem billigen 8bit rumpel"avr" Dieser "Rumpel" AVR macht mit SPI auch locker 8 Mbit/s, und die hält er auch ganz gut über einen Sektor durch. Macht 1 Mbyte/s. Dann muss ein neuer Sektor addressiert werden, schon klar. Aber 400 kB/s klingen realistisch. >das ganze IPv4 gemöller Hat mit der SC/MMC nix zu tun. >meine kleine memoryerweiterung Klemm einfach einen SRAM an den AVR, den können einige Typen direkt und fix ansteuern (Mega8515 etc.). >und noch en FAT in asm Käse. Die 5% Geschwindigkeitsvorteil sind akademisch. Der Aufwand dagegen riesig. MfG Falk
Und wie steht das von dir gesagte im Zusammenhang mit WebserveR? Ich weiß schon wie schnell SPI ist :) Ich will Daten von einer SD-Karte per FTP über ne NE2000 kompatible jagen. Sozusagen 128MB Filehoster im LAN (aber auch im I-net) Da DSL3000 so übern Daumen 45kb/s up macht wärs schon schön auch so schnell da runterladen zu können, aber auch über FTP daten auf den Server schreibe, dafür brächt man vll mal ein Filesystem. Gruß Jens
>Aber nie mit nem billigen 8bit rumpel"avr" Natürlich nicht mit einem ATMega16 und 1kB RAM. Da muss ein teurer 8bit rumpel"avr" ala ATMega644 her. Der hat 4kB RAM. Dann kann man sich einen Sektorcache und einen Fatcache leisten. Die MTU Size auf 1500 stellen und man ist glücklich. ATMega32 ist dafür schon wieder zu klein. Externes RAM wird es nicht bringen. Das interne RAM ist schneller. Die größte Bremse ist auch nicht das FAT sondern der Webserver. Da müssen Checksummen über die kompletten Blöcke gebildet werden, es gibt unvermeidbare delays zwischen den Blöcken vom Server zum Client usw. >und noch en FAT in asm Also wenn schon ASM dann den Webserver. Aber auch das ist Unsinn.
Dann macht der auch nur Unsinn? http://www.vfx.hu/ Ach ich komm mit dem ganzen C Style einfach nicht zu recht, ich mach alles lieber noch per fuß, dann weiß ich wenigstens was ich mach Sich durch des ganze C tut durchzuarbeiten und irgendwie mit klarzukommen grenzt schon an ein wunder.... Gruß Jens
Das größte Problem, dass es überhaupt gibt bei derartigen Dingen, ist das der dämliche Windows-TCP/IP Stack nur mit delayed ACK's läuft. Der Linux Stack scheint da besser zu sein und diese Funktionalität bei Nichtunterstützung abzuschalten. Windows wartet nämlich nach jedem Datenpaket um die 200 (oder länger?) Millisekunden, bevor es ein ACK über die empfangenen Daten losschickt. Allerdings haben alle AVR-TCP-Stacks keinen gegenspielenden Mechanismus für diesen Delayed ACK, sodass sie erst das nächste Paket losschicken, wenn das ACK für das letzte Paket angekommen ist. Somit limitiert sich die Bandbreite mit Windows-Clients um einiges. PS: Was ich immer wieder sehe (und am Anfang auch so gehandhabt habe) ist, dass viele Leute die "8-Bit rumpel AVRs" um einiges Unterschätzen. Mit der 8MBit SPI und einem ENC28J60, sowie einem schön schnellen TCP-Stack kann man so einiges an Bandbreite herausholen. (Also 50kiB/s würde ich schon sagen, abhängig von der jewiligen TCP Anwendung. Ich beziehe mich mal auf einen kleinen Webserver mit einer statischen Webseite aus dem PROGMEM)
> Windows wartet nämlich nach jedem Datenpaket um die 200 (oder länger?) > Millisekunden, bevor es ein ACK über die empfangenen Daten losschickt. Kaum. Ansonsten könnte man Echtzeit-Spiele über LAN und Internet vergessen, also dürfen es allerhöchstens einige dutzend Milisekunden sein.
mr.chip wrote: >> Windows wartet nämlich nach jedem Datenpaket um die 200 (oder länger?) >> Millisekunden, bevor es ein ACK über die empfangenen Daten losschickt. > > Kaum. Ansonsten könnte man Echtzeit-Spiele über LAN und Internet > vergessen, also dürfen es allerhöchstens einige dutzend Milisekunden > sein. Nö, das ist Quatsch. Es sorgt ja für keine Datenverzögerung. Es sammelt nur hereinkommende Datenpakete und schickt nach 200ms (weiß ich nicht genau) dann ein ACK los, was sämtliche in dieser Zeit empfangenen Daten ACK'd. Zur Trafficminimierung btw.
Meiner Meinung nach ist ein Webserver nur auf einem ARM oder einem PIC18 sinnvoll, guck dir Ethernut3 an. Wenn es jedoch darum geht UDP Pakete zu verarbeiten (reines Protokoll mit Steuerdaten, ohne Webinterface), reicht da auch ein AVR, wobei dir 40kb/s auf jeden Fall drin wären. Aber das Ganze in ASM zu programmieren ist doch widerlich oder? >>der scherz ist hald dass ich asm einigermaßen kann... aber na ja C is >>für mich ein grauß wenn ich ganze zeit alles verklammern muss.. Redest du von ewigen if else oder switch abfragen? Das hängt auch vom Programmierstil ab, man kann sowas auch anders lösen z.B. mit Pointern auf Funktionen etc.
Artur Funk wrote: > Meiner Meinung nach ist ein Webserver nur auf einem ARM oder einem PIC18 Naja, ein PIC18 ist wohl kaum (viel) schneller als ein AVR. Da muss man schon zu den 16bit PICs gehen, damit man einen deutlichen Unterschied merkt.
>Naja, ein PIC18 ist wohl kaum (viel) schneller als ein AVR. Da muss man >schon zu den 16bit PICs gehen, damit man einen deutlichen Unterschied >merkt. PIC18 sind deutlich langsamer als AVR. Meine Versuche in C habens jedenfalls so ergeben. Mag auch am Compiler liegen. War der von Mchip.
>Meiner Meinung nach ist ein Webserver nur auf einem ARM oder einem PIC18 >sinnvoll... Zuerst sollte man man definieren was den zu servern ist. Nicht alle Anwendungen verlangen hoechste Bandbreite.
>Zuerst sollte man man definieren was den zu servern ist. Nicht alle >Anwendungen verlangen hoechste Bandbreite. Naja ein Seitenaufbau wie zu den 28K Modemzeiten ist mehr als nur ekelhaft. Wie gesagt: UDP/TCP ja, HTTP -> eher nicht. Aber darüber kann man lange streiten, das ist halt meine Meinung. Viele hören nur AVR+WEBServer und träumen sofort über ein super Webinterface. Die Realität ist da leider anders.
Artur Funk wrote: >>Zuerst sollte man man definieren was den zu servern ist. Nicht alle >>Anwendungen verlangen hoechste Bandbreite. > > Naja ein Seitenaufbau wie zu den 28K Modemzeiten ist mehr als nur > ekelhaft. > Wie gesagt: UDP/TCP ja, HTTP -> eher nicht. Quark. Um ne Seite mit Wetterinformationen anzuzeigen reicht die Geschwindigkeit vom AVR DICKE! Wie schon weiter oben angemerkt ist der Flaschenhals nicht der "popelige schrott 8-bit avr, der echt total langsam ist und nix kann", sondern der Windows-Client. > Aber darüber kann man lange streiten, das ist halt meine Meinung. Viele > hören nur AVR+WEBServer und träumen sofort über ein super Webinterface. > Die Realität ist da leider anders. Wasn Quatsch. Mit einem AVR-Webserver kann man prinzipiell genauso schöne Webinterfaces basteln wie mit "richtigen" Webservern.
Das ist nicht ganz richtig. Wenn man die Seiten auch selbst macht hat man in der Hand welche Bandbreite benoetigt wird. Mit Javascript kann dem PC satt Arbeit anhaengen. Wi haben Webseiten um Geraete zu bedienen, die laufen auch mit 9600 Baud flott. Wenn man sich etwas mit der Materie befasst kann man mit 10kbyte schon sehr komplexe Dinge erledigen. CSS draengt sich auf, und irgendwelche flashplayer - und Frontpage Schwarten mit zwei duzend Fonts in einer Zeile gehoeren natuerlich in die Tonne. Wir reden von Funktionalitaet und nicht von Artistenorgien.
@ Jens (Gast) >Ach ich komm mit dem ganzen C Style einfach nicht zu recht, ich mach Dann werd erwachsen und lerne C. Ist einfacher als man denkt. JAAAA, auch C hat genügend dämlich Stolperfallen, aber der Compiler nimmt einem schon MASSIV Verwaltungsarbeit ab, die bei komplexeren Sachen schlicht nicht mehr sinnvoll manuell handhabbar sind. >alles lieber noch per fuß, dann weiß ich wenigstens was ich mach Ja, du erfindest das Rad neu und musst dich um jeden Krümelkram selber kümmern. Und hast am Ende bestenfalls 5% schnelleren Code. Merke: "90% der Rechenzeit werden in 10% des Programms verbraucht". Eben diese 10% müssen gefunden und optimiert werden. Der Rest muss nur gut geschrieben sein, das reicht im allgemeinen. >Sich durch des ganze C tut durchzuarbeiten und irgendwie mit >klarzukommen grenzt schon an ein wunder.... Nöööö, wenn man das Prinzip der Abstaktion von fertigen Bibliotheken/Softwaremodulen erstmal gefressen hat. MfG Falk
@ 1234: Ein Pessimist ist ein Optimist mit Erfahrung, bei solchen Sachen
wird ein Workaround schnell zu einer Bastellösung und am Ende fragt
man sich, wieso man nicht ein paar Euro mehr für eine schnellere CPU
ausgegeben hat.
Genug fertige IP Stacks gibt es ja schon, da bleibt einem Ingenieur noch
viel Freiheit so einen "schnellen" Webserver durch seine super
Programmierung lahm zu programmieren.
>Wi haben Webseiten um Geraete zu bedienen, die laufen auch mit 9600 Baud flott.
Kannst du mir von dem Webinterface einen Screeshot machen und sagen, wie
lange der Seitenaufbau ca. dauert?
Hallo Über meine HP kannst du unter AVR/ETH_M32_EX Projekte auf meinen AVR Webserver zugreifen. Gruß Uli
>@ 1234: Ein Pessimist ist ein Optimist mit Erfahrung, bei solchen Sachen >wird ein Workaround schnell zu einer Bastellösung und am Ende fragt >man sich, wieso man nicht ein paar Euro mehr für eine schnellere CPU >ausgegeben hat. Ich habe Ulrich Radigs neuesten Webserver teilweise auf ARM7 LPC2138 zum laufen bekommen. Laden der Seiten von MMC/SD. Eine AVR Version habe ich natürlich auch zum vergleichen. Der ARM läuft mit 60MHz und SPI mit 15MHz. Es geht ETWAS schneller, aber mit Sicherheit nicht DOPPELT so schnell. Mehr CPU Power ist nicht immer die Lösung. Da hapert es oft an anderer Stelle (Client).
@ Arthur Funk: Eine schnellere CPU kostet mehr, zieht mehr Strom, benoetigt mehr Leiterplatte. usw. Und wenn die Funktionalitaet zur Konfigurierung eines Geraetes zwei Mal im Jahr/Monat/Tag benoetigt wird, waere alles Groessere als ein Mega32 Overkill. Um die Funktionalitaet einer Steuerung abzubilden und zu Konfigurieren benotigt man nicht so viel. Bei uns mit seriellem Interface. Den TCP/IP Stack braucht's so nicht.
Ulrich Radig wrote: > Über meine HP kannst du unter AVR/ETH_M32_EX Projekte auf meinen AVR > Webserver zugreifen. Ein Link wäre nicht schlecht. So bekannt wie Google bist du noch nicht ;-) http://www.ulrichradig.de/ MfG Falk
@ holger (Gast) >Der ARM läuft mit 60MHz und SPI mit 15MHz. Es geht ETWAS >schneller, aber mit Sicherheit nicht DOPPELT so schnell. >Mehr CPU Power ist nicht immer die Lösung. Da hapert es oft >an anderer Stelle (Client). Meine Rede. Ehe man gross rumphilosophiert muss man erstmal den Flaschenhals finden. Dann kann man über Lösungen nachdenken. MfG Falk
Ja der Flaschenhals ist der Speicher. Ich muß halt wenn ich schnell sein will, mehrere Packete hintereinander weg schicken ohne auf das ACK vom Client zu warten. Muß aber immernoch ein Retransmisson ausführen können wenn dann doch kein ACK kommt. Wer Informationen darüber haben will: (Seite 63 5.2) http://www.uni-koblenz.de/~physik/informatik/studienarbeiten/thowil.pdf Gruß Ulrich
@ Ulrich Radig (radiguli) >Ja der Flaschenhals ist der Speicher. Ich muß halt wenn ich schnelle >sein will, mehrere Packete hintereinander weg schicken ohne auf das ACK >vom Client zu warten. Muß aber immernoch ein Retransmisson ausführen >können wenn dann doch kein ACK kommt. Was dafür spricht, dann doch eher exteren SRAM an den AVR zu schmieden. Und damit gegen > holger (Gast) wrote: >Natürlich nicht mit einem ATMega16 und 1kB RAM. >Da muss ein teurer 8bit rumpel"avr" ala ATMega644 her. >Der hat 4kB RAM. Dann kann man sich einen Sektorcache und >einen Fatcache leisten. Die MTU Size auf 1500 stellen >und man ist glücklich. ATMega32 ist dafür schon wieder zu klein. >Externes RAM wird es nicht bringen. Das interne RAM >ist schneller. MfG Falk
Der Speicher ? Ein Atmel dataflash kann man mit dem vollen SPI Clockspeed auslesen. Ob man ein FAT braucht ist eine Frage.
Was dagegen spricht? Die Größe des SRAMS und der komplexe Aufwand des ganzen. Evt. ob der Programmspeicher dafür reicht??
@holger: du schreibst du hast den neusten Webserver von Uli auf dem LPC2138 zum laufen bekommen. Würdest du mir deinen angepassten Quelltext zukommen lassen wollen? Ich bastel nämlich an einer Anpassung für den LPC2103 und da ich momentan wenig Zeit habe wäre das 'ne riesen Hilfe für mich! Meine E-mail Adresse bitte aus dem Thread nehmen: Beitrag "[S] Suche ein oder mehere WIZ810MJ Module" (ganz unten) Danke! Mit freundlichen Grüßen, Omega. P.S.: Mit meinem momentanen, schlecht, implementiertem UDP schaffe ich auf meinem LPC2103 ca. 500kb/s! Übrigens kann man über den SSP Bus halben CPU Takt als Takt verwenden! Das macht bei 60 MHz 30 MHz, aber das ist für den ENC28J60 leider zu viel!
Wenn ich ein Dataflash als Speicher benutze brauche ich kein FAT!
Der Webserver von Ulrich ist schon fein, der Seiten Aufbau dauer aber schon eine gewisse Zeit und das bei einer Dateigröße von ca 9Kb. Wenn ich da an Gerätesteuerungen denke mit komplizierten Menüs und aufwändigen Ausgaben, dann bin ich immer noch der Meinung, dass ein AVR da fehl am Platz ist (ja, schlagt mich). Wenn es jedoch darum geht paar Relais zu schalten reicht die Version von Ulrich sicherlich aus.
@Artur Funk, Der Webserver läuft hier aber auch noch nicht auf voller Geschwindigkeit! Ca. um die hälfte langsamer. Desweiteren habe ich nur DSL 1000 und teile mit meinem Webserver die Bandbreite.
>@holger: >du schreibst du hast den neusten Webserver von Uli auf dem LPC2138 zum >laufen bekommen. Würdest du mir deinen angepassten Quelltext zukommen >lassen wollen? Ich frag lieber erstmal mal ganz brav ob Ulrich was dagegen hat. Hallo Ulrich, hast du was dagegen wenn ich eine nicht komplette ARM7 Version (1.041) deines Webservers weitergebe ?
Hallo Holger, Habe ich nicht! ;-) Bei dir habe ich noch nicht mal Probleme wenn du den Code auf deiner Homepage stellst. Gruß Uli
Danke Ulrich. So hier der ARM Code. Ist aber wie gesagt noch nicht voll funktionsfähig. httpd,ntp,timer, uart1 laufen. Eingaben über uart sind noch nicht dabei und telnet geht auch noch nicht. Viel Spaß damit holger
Vielen Dank an Ulrich und Holger! In zwei Wochen habe ich wieder Zeit mich darum zu kümmern!
LOL Also was ist nun ne realistische FTP datenrate von einer SDkarte auf netzwerk? 30kb/s? Gruß Jens
@ Jens >Also was ist nun ne realistische FTP datenrate von einer SDkarte auf >netzwerk? >30kb/s? Ja, das ist realistisch. Meine Testseite lädt 10 Bilder mit insgesamt 514kB von SD/MMC. Die Zeiten hab ich mehrfach ausgezählt aber nicht wirklich gemessen. Also wenigstens plus/minus 1-2s bei den längeren Zeiten. Ulrichs AVR Webserver (1.054) Ubuntu Linux mit Firefox 5s XP mit IE 7s XP mit Firefox 13s Meine ARM7 Version von Ulrichs Webserver (1.041) Ubuntu Linux mit Firefox 3s XP mit IE 6s XP mit Firefox 12s Der billige 8bit rumpel"avr" gibt aber ganz schön Gas ! Der ARM7 rennt ihm nicht unbedingt weg. Obwohl fast 4 fache CPU und 2 fache SPI Frequenz. Gründe: 1. Die MMC/SD Karte will einfach nicht schneller werden. 2. Der Client will nicht schneller abholen. Die Frage ob es sich lohnt FAT oder Webserver in ASM zu programmieren dürfte damit geklärt sein. Eine fette CPU dranhängen bringt es auch nicht. Grüße an alle Beteiligten holger
Artur Funk wrote: > Der Webserver von Ulrich ist schon fein, der Seiten Aufbau dauer aber > schon eine gewisse Zeit und das bei einer Dateigröße von ca 9Kb. Du hast sicherlich Windows. Und die Sache mit dem Delayed ACK hast du dir sicher auch nicht durchgelesen. Ach Leute, was solls. Ich klink mich dann aus. Man redet hier gegen Wände. Das einzige was zurückkommt ist "WIR BRAUCHEN MEHR PROZESSORLEISTUNG" und "WIR BRAUCHEN MEHR SPEICHER" von selbsternannten Profis, die eigentlich keinerlei Ahnung davon haben. (Und das, ohne mich jetzt sonderlich professionell hinzustellen) PS: Ich sehe schon holger hat über mir ein paar Facts geliefert. Super! :-) PPS: Achso, wenn man unbedingt einen komplexeren Webserver möchte, der auch durchaus schneller sein kann, kann man sich mal den Light-weight-ip-stack "lwip" von Adam Dunkels anschauen. Ist aber eher für größere Mikroprozessoren geeignet.
@ Simon K. (simon) >Wände. Das einzige was zurückkommt ist "WIR BRAUCHEN MEHR >PROZESSORLEISTUNG" und "WIR BRAUCHEN MEHR SPEICHER" Das Vaterunser aller Wannabe-Profis ;-) MfG Falk P.S. Schöne Signatur, hab ich mal gelesen "Sachkunde kann jeder lebhaften Diskussion nur schaden" ;-)))
Also erstmal: ich hab noch keine Webserver Erfahrung, hab mir jetzt Simons µWebServer platine besorgt und bestelle die tage das zeug bei CSD, aber es sollte dann schneller werden wenn man genug speicher zur verfügung hat, um genug Pakete zwischenzuspeichern, um dann bei fehlendem ACK neu senden zu können. Dann dürfte es schneller sein (aber auch viel aufwändiger). Auch wenn der externe Speicher langsamer ist (ist aber auch nur nen Takt) Meine Überlegung: Bei komplett Statischen inhalten sollte man doch einfach Pointer Auf anfang und ende des Inhalts setzen können und im Fehlerfall dieses Paket erneut zusammenstellen und übertragen könnte. Aber wie gesagt, ich hab mich noch nicht reingearbeitet und nur so hier im Forum etwas mitgelesen in den Webserverthreads. Das Problem dürfte eher bei Dynamischen Inhalten sein: man müsste irgendwie die Dynamischen Inhalte im zustand gespeichert werden in dem sie waren, als das Paket das erste mal zusammen gestellt wurde. Ok bei Temperaturen sollte es nicht schlimm sein, ob sie jetzt 200ms später oder früher gemessen werden, aber es gibt sicher irgend welche Daten, die sich in der Zeit ändern können. Eine möglichkeit wäre noch, bei dynamischen Paketen auf ein ACK zu warten, bei statischen jedoch nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.