Hallo, der Titel des Threads sagt es eigentlich schon, was ich tun möchte. Der Grund dafür ist der folgende: Zwar findet man im Netz sehr viele TCP-Stacks, doch möchte man etwas funktionierendes, kommt man nicht umhin, lwip oder uIP zu benutzen. Beide gefallen mir nicht, weil ich sie sehr unübersichtlich programmiert finde. Des weiteren könnte man in lwip noch einiges Verbessern. Der Code unterstützt z.B. theoretisch mehrere Netzwerk-Interfaces. Doch wer hat schon mehr als eine LAN-Schnittstelle an seinem Mikrocontrollerboard? Das gibt also einen unnötigen Software-Overhead. uIP wiederum ist optimiert auf 8 Bit-Architekturen, und kann so einiges nicht. Hier ist man dann wieder zu eingeschränkt. Mein Wunsch-Stack sieht so aus: - IP - UDP - SNTP - ist mit einem RTOS (z.B. uC/OS) benutzbar Dabei möchte ich die Standards so weit es nur irgend möglich ist vollständig einhalten. Jetzt die Frage: 1. Gibt es Leute, die Lust hätten, an dem Projekt mit zu arbeiten? 2. Wenn nicht: kann mir einer einen Anhaltspunkt geben, wo man am besten anfängt? ich habe schon so einiges gecodet auf meinem LPC2468 Board, aber so richtig zufrieden bin ich noch immer nicht damit. 3. Gibt es das, was ich mir wünsche, etwa schon? Bitte bitte nicht lwip und nicht uip. Die zwei kenne ich, und ich finde sie unschön :-(
Ohne TCP ist das ganze doch primitiv und nichts mehr als Auffüllen der Ethernet-IP-UDP Header und Berechnen der IP-Checksumme. Dafür brauche ich keinen Stack, das ist mit etwas Nachdenken an einem Nachmittag erledigt. Auch BOOTP/DHCP Client, TFTP, ARP und ICMP Echo sind eigentlich primitiv. TCP ist das, wo die Komplexität drinsteckt und was Speicher braucht, und hier entscheidet sich die Qualität eines Stacks. fchk
>1. Gibt es Leute, die Lust hätten, an dem Projekt mit zu arbeiten?
Buhahaha.
Frank, naja, als so trivial würde ich es doch nicht erachten. Schliesslich möchte ich mich schon an das OSI-Modell halten und die entsprechenden Teile genau so unterteilen, wie es eigentlich vorgeschrieben wäre. Wie wird z.B. ein IP-Paket reassembliert? Wie realisiert man den Datenaustausch zwischen dem Stack und den einzelnen Tasks des OS? So einfach finde ich das gar nicht mal. Du kannst mir aber gerne einen Anhaltspunkt geben.
Tobias schrieb: > Schliesslich > möchte ich mich schon an das OSI-Modell halten und die entsprechenden > Teile genau so unterteilen, wie es eigentlich vorgeschrieben wäre. Das OSI-/Referenz/-Modell ist keine Vorschrift, man nimmt sich heraus, was man braucht. > Wie > wird z.B. ein IP-Paket reassembliert? Ist 'reassembliert' hier wirklich die richtige Vokabel?
Tobias schrieb: > Schliesslich möchte ich mich schon an das OSI-Modell halten Das ist eine blöde Idee, weil die Internet-Protokolle mit dem OSI-Stack nicht allzuviel gemein haben. Tatsächlich bilden sie eine ganz eigene Schichtenarchitektur, die oft als "Internet Architecture" bezeichnet wird. Die Abbildung auf OSI, die man öfter sieht, ist nur in allererster Näherung möglich.
ikarus, im englischen heisst es reassemble (ich weiss nicht mehr, in welchem RFC es auftaucht, vielleicht RFC791 oder so...). Ich hab das einfach eingedeutscht ;) Ich sehe schon: hier scheint kein grosses Interesse an dem Vorhaben zu bestehen. Ich finde das eigentlich schade, denn heute tendieren die Leute immer mehr dazu, zu sagen "ach, das hat ja schon mal einer implementiert", dann wird als erstes gegoogelt, und der erstbeste Code genommen, der halbwegs läuft. Selber was zu machen hat offenbar niemand mehr Lust zu? Da ist es ja kein Wunder, ist heute niemand mehr innovativ. Ich meine: schaut euch doch mal die Elektronikindustrie an. Die Geräte (egal welche Geräte) werdem immer schneller, kleiner und stromsparender, aber wirkliche Innovationen gibt es gar nicht mehr. Aber vielleicht könnte man diesen lwip noch ein bisschen besser machen, als er schon ist? Ich wundere mich, dass ich der einzige bin, der sich an diesem furchtbaren Programmierstil, der da gepflegt wird, ärgert.
Tobias schrieb: > Frank, > naja, als so trivial würde ich es doch nicht erachten. Schliesslich > möchte ich mich schon an das OSI-Modell halten und die entsprechenden > Teile genau so unterteilen, wie es eigentlich vorgeschrieben wäre. IP wurde nicht mit Blick auf OSI entwickelt und hält sich selber auch nicht dran. Also brauchst Du es auch nicht zu tun. > Wie > wird z.B. ein IP-Paket reassembliert? Meep. Falsche Frage. Fragmentierte IP-Pakete willst Du nicht haben. Die ganzen Standardprotokolle wie DNS und DHCP sind so gebaut, dass garantiert ist, dass sie nicht fragmentieren, denn es ist vorgeschrieben, dass die MTU mindestens 576 ist. Bei Deinen eigenen UDP-Protokollen setzt Du einfach das DF-Bit. Wenn Du dann ein ICMP-Paket mit Typ 3 (destination unreachable) und Code 4 (fragmentation required but don’t fragment bit set) bekommst, weißt Du, dass Du Deine MTU reduzieren musst. IPV6 fragmentiert ohnehin nicht mehr. > Wie realisiert man den > Datenaustausch zwischen dem Stack und den einzelnen Tasks des OS? Das darfst Du mit Dir selber ausmachen. > So einfach finde ich das gar nicht mal. Du kannst mir aber gerne einen > Anhaltspunkt geben. Dein erster Anhaltspunkt sind die RFCs. Das sind die bindenden Dokumente. fchk
Hallo Frank, schön, dass wenigstens du konstruktive Beiträge lieferst ;) Ich mache das bei meinem Stack so: Beim Initialisieren des Ethernet-Drivers wird ein Semaphor kreiert, welcher den Wert 0 hat. Beim Eintreffen eines Pakets wird dieser Semaphor jeweils um 1 inkrementiert. Mein Netzwerk-Task pollt nun diesen Semaphor, und wenn Pakete vorhanden sind (solange Semaphor > 0 ist), wird der netstack_process aufgerufen. Dieser kreiert einen Buffer, wo das empfangene Paket rein kopiert wird. Anschliessend wird mittels switc-case Konstrukten entschieden, ob das Paket dem IP- oder ARP-Modul übergeben werden soll. Soweit so gut. Was hältst du von dem Konzept? Der Vorteil ist, dass, solange keine Pakete eintreffen, der Netzwerk-Task suspended ist, weil er ja auf den Semaphor wartet. Und wenn während der Bearbeitung eines Pakets weitere Pakete eintreffen, dann ist so sichergestellt, dass nichts verloren geht. ARP habe ich schon implementiert und mich dabei streng an RFC826 gehalten. Doch bin ich mir bei IP nicht mehr so sicher, wie ich genau vorgehen muss, wenn ein Paket eintrifft. Leider schweigen sich die RFCs darüber aus, in welcher Reihenfolge man was tun muss. Gibts da vielleicht so eine Art PAP oder so, wo das verdeutlicht wird? Oder implementiert das einfach jeder nach gutdünken?
Tobias, sind die Ergebnisse Deiner Recherchen wirklich nur uip und lwip? Was ist mit: avrETH1 by Simon Schulz avrfreaks by Jesper Hansen AVRnet etherrape by fd0 aka Alexander Neumann ethersex by stesi mega-eth by Roland Riegel MicroWebServer by Simon Küppers OpenMCP by Dirk Broßwick aka sharandac Ulrich Radig tuxgraphics by Guido Socher Ich habe mir alle angeschaut. Fast alles deutsche Projekte, weil ich ausgehend von diesem Forum mit Fokus auf AVR gesucht habe. Die Welt wird noch ein paar mehr bieten. Bei anderen Architekturen kann man ja auch noch schauen. Was wäre, wenn kompetente Mitarbeiter Deinen Programmierstil genausowenig mögen, wie Du den von Xip nicht? Will sagen, Du musst Dich den Gepflogenheiten eines Projektes auch unterordnen. Ansonsten fügen wir der Liste noch einen hinzu... Womit ich sagen will: Nach meiner Meinung ist bereits zuviel Hirnschmalz redundant verschwendet worden, anstatt sich auf zwei, drei gute Stacks zu konzentrieren. Anstatt den n-ten Stack zu entwickeln habe ich mich für einen aktiven entschieden und unterstütze diesen so gut ich das kann. Deine km-Leistung mag anders sein :-) Viel Erfolg!
Ich sagte ja bereits, dass es eine grosse Anzahl von Stacks gibt. Doch habe ich mein ganzes Leben lang einen AVR noch nicht mal angefasst, ich kann daher die Funktionsweise von diesen ganzen AVR-Geschichten teilweise nur erahnen. Was meinst du mit km-Leistung? Denkst du denn, es ist gar nicht möglich, einen eigenen Stack zu bauen?
Tobias, mein Standpunkt ist, dass ich gerne auf einem AVR programmiere, jedoch nicht alles. Einen eth-Stack möchte ich als Modul benutzen, in der Liste finde ich jedoch 10. Zehn fähige Köpfe, die Header aneinanderfügen, Checksummen berechnen und letzten Endes das Gleiche tun: Ein Netzwerkpaket auf die Reise schicken. Die Motivation für eine eigene Entwicklung statt Mitarbeit an bestehenden Projekten wird von Entwicklern meist beantwortet mit: Weil man dadurch mehr lernt. Richtig! Und man macht auch mehr Fehler... Womit der Anwender = ich sich dann herumschlagen darf. Aus diesem Blickwinkel sind zehn verschiedene Stacks für mich verschwendete Ressourcen. Sicher kannst Du Dich in diesen Entwickler-Reigen einfügen und Deinen eigenen Stack bauen. Die anderen sind auch ins Ziel gekommen, zum Teil ebenfalls als Einzelkämpfer. Allerdings verlängert Deine fehlende AVR Erfahrung die Lernkurve wesentlich. Viel Erfolg! PS: Die km Leistung ist der Versuch einer Eindeutschung von: Your mileage may vary. Sinngemäss: Du magst unterschiedlich weit kommen, auch und weil Du evtl. einen anderen Weg wählst.
Tobias schrieb: > wird der netstack_process aufgerufen. Dieser kreiert einen Buffer, wo > das empfangene Paket rein kopiert wird. Anschliessend wird mittels > switc-case Konstrukten entschieden, ob das Paket dem IP- oder ARP-Modul > übergeben werden soll. Kopieren ist doof, weil das CPU-Zeit kostet. Gute Stacks kopieren nicht, sondern halten Empfangspuffer vor, in die der Ethernettreiber die empfangenen Pakete reinschreibt. Wenn Du nur auf ankommende Pakete reagierst, brauchst Du keine ARP-Requests, denn die MAC-Adresse bekommst Du ja geliefert, und dann reicht es, einfach im MAC- und IP-Header Empfänger und Absender zu tauschen. > er ja auf den Semaphor wartet. Und wenn während der Bearbeitung eines > Pakets weitere Pakete eintreffen, dann ist so sichergestellt, dass > nichts verloren geht. Das ist schön, aber der Standard erlaubt Paketverluste. > ARP habe ich schon implementiert und mich dabei streng an RFC826 > gehalten. Doch bin ich mir bei IP nicht mehr so sicher, wie ich genau > vorgehen muss, wenn ein Paket eintrifft. Leider schweigen sich die RFCs > darüber aus, in welcher Reihenfolge man was tun muss. Gibts da > vielleicht so eine Art PAP oder so, wo das verdeutlicht wird? Oder > implementiert das einfach jeder nach gutdünken? Du darfst die Freiräume, die die RFCs Dir lassen, nutzen. Entscheidend ist, was hinten rauskommt. Und: Die Anforderungen haben sich in den letzten Jahren geändert. Einiges wie Type Of Service oder auch Fragmentierung wird heute fast nicht mehr gebraucht, weil es bessere Mechanismen (802.1p/q und Path MTU Discovery) gibt. fchk
in welchem RFC steht denn, dass man Pakete verlieren darf? und ist es gemäss RFCs auch zulässig, fragmentierte IP-Pakete zu verwerfen?
Ich habe für meinen Webserver auch erst angedacht einen TCP/IP Stack zu schreiben. Und zwar wesentlich modularer, aber gleichzeitig viel besser geordnet als der uip (Alls in eine Datei gequetscht, goto's usw.). Dabei muss man nicht unbedingt die hohe Performance verwerfen, nur wenn man keine goto's benutzen will. Es gibt auch noch Sachen wie static-inline und gute Compileroptimierungen, sodass (Flag-)Variablen rausoptimiert werden. Allerdings habe ich schnell die Lust dran verloren, denn: * TCP/IP (also TCP über IP) ist erst undurchsichtig und nachher sieht man dann, dass es sehr viele Spezialfälle gibt, wann vorläufige ACKs gesendet werden etc. Und wenn man wirklich den kompletten Stack einbauen will, braucht man eben massig Speicher. TCP/IP ist ja auch eher auf große Systeme heute angewendet. PCs mit Gigabytes an RAM. Bestimmte neue Features, die Paketprioritäten regeln. Die Liste geht ohne Probleme noch weiter. All das muss man sich durchlesen und u.U. sogar implementieren. * Die RFCs sind schön und gut. Aber es gibt ziemlich viele, bzw. sie sind auch teilweise ziemlich lang, wenn man bloß die Grundfähigkeiten wie TCP, UDP, IP, MAC, ICMP einbauen möchte. * Angenommen man hätte es geschafft alles zu integrieren, dann muss anschließend der ganze (mittlerweile verworrene Code) erst mal wieder aufgeräumt werden. U.U. Rewrite. * Dann unter Umständen noch abstrahiert werden (mit defines). Also verschiedene Compile-Zeit Optionen einbauen. * Das Alles dann noch mit jeder möglichen Option durchtesten. * Und dann hat man nachher immernoch irgendwo einen kleinen Bug drin, der nur selten auffällt und schwer auszumachen ist (Fehler bei ACK/SEQ Nummern Berechnung, der nur auftritt, falls der Host mal ein "Bitte Warten mit weiteren Daten" (TCP mit Windowsize = 0, glaube ich) schickt, was eben nicht oft vorkommen wird). Und noch ein paar Punkte mehr, sodass es sich einfach nicht lohnt noch mal etwas selber aufzusetzen. Da steckt schon eine große Zeit dahinter, bis sowas mal gescheit läuft. Selbst der Windows-XP Stack ist ja nicht ganz standardkonform. Wie es mittlerweile bei Windows 7 aussieht, weiß ich nicht.
Simon, ja ich merke auch, dass es ein schwieriges Unterfangen ist. Dennoch möchte ich es gerne versuchen. Bei einigen Dingen, die z.B. in lwip sehr umständlich und unschön gelöst sind, fällt es mir sofort auf, wie man es besser machen könnte. Bei anderen Sachen wiederum hapert es. Was mich beim lwip am meisten stört: der Quelltext ist enorm schwer lesbar, und die vielen gotos sind ziemlich unschön. Mein Ziel ist es eigentlich, einen Stack zu bauen, der sich nicht nur durch eine gute Lesbarkeit auszeichnet, sondern ich möchte auch noch eine Doku dazu schreiben, damit auch ein Aussenstehender diesen ganzen TCP-Krempel verstehen kann. Doch wie gesagt, vorerst ist noch gar nicht an TCP zu denken! erst müssen die ganzen anderen Schichten des Stacks Stück für Stück aufgebaut werden. Ich glaube mittlerweile, dass die eigentliche Schwierigkeit nicht in der Komplexität der ganzen Protokolle liegt, sondern eher in der Menge an Informationen, die man verarbeiten und lesen muss. Die ganzen RFCs, verstreut über hunderte von Dokumenten usw. Dann noch die Frage, womit man überhaupt anfangen soll. Dass das ganze massig Speicher braucht, ist mir klar, aber daran soll es nicht scheitern, denn ich habe genug Memory auf meinem Eigenbau-Board. Frank, dass Kopieren doof ist, sehe ich genauso :) nur geht es manchmal nicht anders. Beim LPC2468 gibt es einen Memory-Bereich, auf welchen per DMA zugegriffen werden kann. Der Ethernet-MAC platziert dann empfangene Frames automatisch dort hin. Da ich im Voraus nicht wissen kann, zu welchem Protokoll bzw. zu welchem Task ein empfangener Frame gehört, kann ich dem Ethernet-MAC auch nicht den Buffer angeben, wo er den Frame rein legen soll. Also wird erst mal alles in ein einziges grosses Memory platziert. Dieses Memory präsentiert sich der Anwendung dann als ein grosses Array von empfangenen Paketen, und mittels einer Zugriffsfunktion wird ein Frame nach dem anderen aus diesem Puffer geholt (natürlich über Pointer, um das Kopieren zu sparen).
Tobias schrieb: > in welchem RFC steht denn, dass man Pakete verlieren darf? RFC791, Abschnitt 1.4: The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control. > und ist es gemäss RFCs auch zulässig, fragmentierte IP-Pakete zu > verwerfen? (a) siehe oben (b) Geht auch nur ein Fragment verloren, muss der Sender alle Fragmente neu absenden. Das ist ein Grund, Fragmente nicht zu benutzen. Zu der Zeit, als das RFC geschrieben wurde, gab es viele verschiedene Netzwerktechniken (X.25 via X.21, Token Ring, später FDDI, Arcnet,...) mit unterschiedlichen Paketgrößen, d.h. damals war Fragmentierung technisch notwendig. Heutzutage ist davon praktisch nur noch Ethernet übriggeblieben, und da braucht man nicht mehr zu fragmentieren. Ausnahme: PPPOE mit dem 8 Byte Header (Idioten, hätten die nicht einfach die Pakete wie bei 802.1pq um 8 Bytes größer machen können?) (c) nur fragmentierte Pakete zu verwerfen ist sicher nicht im Sinne des Erfinders, aber Du kannst ja Deine Randbedingungen so wählen, dass sie eben nicht auftritt. fchk
Hallo, sorry dass meine Antwort so lange auf sich hat warten lassen. Ich habe den Abschnitt auch grade gelesen. Nun weiss ich aber immer noch nicht, was ich tun soll, wenn ich ein Paket erhalte, wo das More Fragments-Flag gesetzt ist ;) am einfachsten wäre es schon, die Sache zu verwerfen. Dann würde sich der IP-Layer relativ einfach gestelten. Bei Erhalt eines Pakets Empfängeradresse, Checksum und IP-Version prüfen, und anhand der Protokollnummer an den nächst höheren Layer weiterleiten. So langsam habe ich schon die eine oder andere Idee, wie ich das machen könnte. Aber es ist irgendwie doch noch zu vieles unklar. Ich glaube, ich werde lwip als Vorlage nehmen und nach meinem Gusto umschreiben.
@ Tobias: Der lwip Stack gefällt dir nicht, aber der funktioniert doch schon mal recht gut. Ist es denn nicht um ein vielfaches einfacher den lwip hier und da ein wenig um zu schreiben und zu optimieren? Und dann zu dokumentieren? Damit hätte man sechs Fliegen mit einer Klappe: - Das ganze wird übersichtlicher - lwip wird besser - und dass lwip besser wird, darüber würden sich garantiert viele hier freuen - damit würdes du viel bessere Unterstützung in diesem Forum/Usern bekommen - und es würden sich mehr leute finden die das dann auch testen würden - du musst nicht alles optimieren, sondern nur der Teil der dir nicht gefällt, somit kannst du irgendwann wieder aufhören und das (funktionierende) Ergebnis der open-source Gemeinde überlassen. Das würde wirklich vielen helfen. Denn bis dein Code, von 0 beginnend gut und fehlerfei ist gehen sicher 1-2 Jahre vorbei. Da den dann niemand kennt und warscheinlich schonmal lwip verwendet wurde, wird den auch niemand haben wollen. Überlege dir das wirklich nochmal mit dem selbst schreiben von 0 (null) beginnend.
Markus, ja ich werde wohl nicht umhin kommen, das so zu machen. Allerdings wird das auch nicht einfach. Ich möchte lwip so umschreiben, dass er sich nahtlos in mein uC/OS System integriert, das heisst dann natürlich auch, dass die ganzen APIs umgeschrieben werden müssen. Zudem möchte ich diese pbufs nicht haben. Denn dort müssen die Pakete, die versandt werden wollen, erst in einen solchen pbuf rein kopiert werden, bzw. empfangene Pakete müssen aus den pbufs raus kopiert werden. Das ist mühsam, unschön und verschwendet CPU Zeit, und es ist unnötig, wenn man einen MAC hat, der DMA kann. Von 0 an selber schreiben hätte natürlich auch was für sich, schliesslich kann nicht jeder behauptet haben, selber einen TCP-Stack entworfen zu haben ;-)
Mit dem pbuf muss man nichts kopieren. pbuf ist doch ein Zeiger auf einen Buffer, einfach diesem Zeiger eine andere Adresse zuweisen, fertig. Oder etwa nicht?
Nein. lwip hat einen eigenen memory manager, der verschiedene Pools zur Verfügung stellt, und ein pbuf ist eine verkettete Liste von solchen Pools. Eben genau dies gefällt mir z.B. nicht am lwip. Ich finde dies unnötig kompliziert. Man hätte es wenigstens so machen können, dass pro Paket ein einziger Buffer alloziiert wird, der so gross ist, dass das Paket grade rein passt. Dann hätte man sich auch den memory manager sparen können.....
Tobias schrieb: > Nein. lwip hat einen eigenen memory manager, der verschiedene Pools zur > Verfügung stellt, und ein pbuf ist eine verkettete Liste von solchen > Pools. > Eben genau dies gefällt mir z.B. nicht am lwip. Ich finde dies unnötig > kompliziert. Man hätte es wenigstens so machen können, dass pro Paket > ein einziger Buffer alloziiert wird, der so gross ist, dass das Paket > grade rein passt. Dann hätte man sich auch den memory manager sparen > können..... Der Memory Manager hat seinen Sinn. Ich tippe mal darauf, dass Du noch nie auf einem Amiga programmiert hast, weil Du einfach zu jung bist. Das AmigaOS war ein sehr schlankes Betriebssystem, das für einen 68k ohne MMU entworfen wurde. Da konnte es Dir nach einiger Zeit passieren, dass Du zB einen 2MB Speicherblock brauchtest, ihn aber nicht bekommen hast, obwohl noch insgesamt 4.5MB frei waren, davon aber 500 MB im Chip-RAM und zwei 1.5MB und ein 1MB Block im Fastram. Schade auch. Da war dann ein Reboot fällig, oder zumindest alle Programme schließen und neu starten. So etwas nennt man Speicherfragmentierung und kann auf allen Systemen ohne MMU passieren. Bei Embedded Systemen fordert man den Speicher daher genau einmal am Anfang an und arbeitet damit fortan, eben um genau die beschriebene Situation zu vermeiden. Nach Deinem letzten Posting möchte ich sagen "Lass es". Geh davon aus, dass sich der Adam Dunkel schon etwas dabei gedacht hat und versuch den Grund dafür rauszufinden. fchk
Frank, ich weiss schon, was es heisst, wenn das memory fragmentiert ist. AmigaOS kenne ich tatsächlich nur vom hörensagen, den 68k dafür aber umso besser. Ich würde aber mal behaupten, dass das memory kaum fragmentiert, wenn man genug davon hat. Oder? Und das ist bei mir der Fall, ich habe so viel Memory, dass ich wohl gar nicht alles brauchen kann. Nachdem ich jetzt einen anderen Chip aufgelötet habe, verfüge ich über 64M x 32 Memory, also 256 MBytes. Das sollte auch für den dicksten Stack noch reichen. Wenn der Dunkels schon diesen Memory Manager entworfen hat: wieso hat er den nicht gleich so designt, dass ein ganzes paket in einen einzelnen pbuf passt? Ich habe nämlich vor einiger Zeit mit lwip rumgedoktert (habe ihn allerdings nie recht zum laufen gekriegt). Dort musste dann auf umständliche Weise ein eingetroffenes Paket in einen solchen pbuf rein kopiert werden. Und wenn ein Paket versendet werden sollte, dann musste man erst einen pbuf alloziieren, und dann die Paketdaten in diesen pbuf rein kopieren. Warum spart man sich diese Kopiererei nicht einfach? Ich versteh's wirklich nicht. Aber ich gehe mal davon aus, dass es auf einem PC wohl kaum auch so gemacht wird, denn dann würde man ja die meiste CPU-Zeit nur für das sinnlose rumkopieren von Daten benutzen.
Tobias schrieb: > Frank, > ich weiss schon, was es heisst, wenn das memory fragmentiert ist. > AmigaOS kenne ich tatsächlich nur vom hörensagen, den 68k dafür aber > umso besser. > Ich würde aber mal behaupten, dass das memory kaum fragmentiert, wenn > man genug davon hat. Oder? Und das ist bei mir der Fall, ich habe so > viel Memory, dass ich wohl gar nicht alles brauchen kann. Nachdem ich > jetzt einen anderen Chip aufgelötet habe, verfüge ich über 64M x 32 > Memory, also 256 MBytes. Das sollte auch für den dicksten Stack noch > reichen. "kaum fragmentiert" ist genauso wie "kaum abstürzt" bei Windows 98, wenn der Systick Counter nach 49,7 Tagen überläuft - Pfusch. Ein gutes System sollte Jahre ohne Störungen durchlaufen. Bei Netware und Solaris-Maschinen habe ich schon vierstellige Uptimes gesehen. > Wenn der Dunkels schon diesen Memory Manager entworfen hat: wieso hat er > den nicht gleich so designt, dass ein ganzes paket in einen einzelnen > pbuf passt? Vielleicht fragst Du ihn einfach oder liest seine Papers? Ich denke, es war eine Designentscheidung, um den Speicherbedarf zu reduzieren. Mit 256 MB könntest Du auch zum BSD Stack greifen. Das ist sozusagen die Referenz, von der alle anderen abgepinnt haben. fchk
Ich habe ihm bereits eine Mail geschickt und warte auf eine Antwort. Den BSD-Stack werde ich mir anschauen, danke für den Tipp!
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.