www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Webserver geschwindigkeit [AVR]


Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Artur Funk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Artur Funk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Artur Funk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Über meine HP kannst du unter AVR/ETH_M32_EX Projekte auf meinen AVR 
Webserver zugreifen.

Gruß
Uli

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@ 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).

Autor: 3456 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Radig bei google hätte gereicht ;-)

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/studi...

Gruß
Ulrich

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: 3456 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Speicher ? Ein Atmel dataflash kann man mit dem vollen SPI 
Clockspeed auslesen. Ob man ein FAT braucht ist eine Frage.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was dagegen spricht? Die Größe des SRAMS und der komplexe Aufwand des 
ganzen. Evt. ob der Programmspeicher dafür reicht??

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich ein Dataflash als Speicher benutze brauche ich kein FAT!

Autor: Artur Funk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 3456 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Artur Funk :
Zeig doch mal die langsame 9kByte Seite.

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@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 ?

Autor: Ulrich Radig (radiguli) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Holger,

Habe ich nicht! ;-) Bei dir habe ich noch nicht mal Probleme wenn du den 
Code auf deiner Homepage stellst.

Gruß
Uli

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Omega G. (omega) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank an Ulrich und Holger!

In zwei Wochen habe ich wieder Zeit mich darum zu kümmern!

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LOL
Also was ist nun ne realistische FTP datenrate von einer SDkarte auf 
netzwerk?

30kb/s?

Gruß Jens

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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" ;-)))

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.