Interner Speicher -> Stabilität von GoPal & Datensicherung

    ?( rohoel, Du liest aber schon konzentriert hier mit, oder? ;D


    Zitat

    Original von Ralf25
    Sollte der Wert unterschritten werden, d.h., das System mehr benötigen, als zugewiesen, reserviert es sich autom. 10000, den Default! Es passiert also definitiv nix.


    Probier's aus, trage 1000 (in Worten: eintausend) ein und Du wirst es sehen. ;)


    Stell den Wert so ein, daß Du direkt nach dem StartMenu knapp unter 1 MB StM bist. Dann bist Du bei Deinen mögl. Prg. auf jeden Fall auf der sicheren Seite. 500 KB geht auch, Du mußt es halt mal selber beobachten.



    Alles kann man halt nicht vorkauen, es hängt sehr stark von der jew. Verwendung ab.

    Solange Du Dein System jetzt nicht änderst, wird alles OK sein. Die nächste neue Menuseite, die nächste DLL in \Windows, etc. läßt den Bedarf aber schon wieder ansteigen. Also immer auch ein wenig sensibel dahingehend sein! ;)

    • Offizieller Beitrag

    jetzt hab ich das mal ganz krass auf 1750 im menü eingestellt und siehe da, bisher klappt alles (auch sehr lange routenberechnungen)!
    ich werde die sache im auge behalten (bei 200 spielt sich ein bisher funktionierendes backup so schwer zurück ohne beifahrer der das lenken übernehmen kann).
    danke dir!


    mfg rohoel.

    Mich wundert, das Du so skeptisch bist, es müßte eigentlich sogar spürbar schneller sein! :D Aber < 250 ist schon sehr grenzwertig. ;D



    @deichjunge
    Hast Du jetzt hiervon auch profitieren und etwas verbessern können an Deinem System?

    Hey Ralf und rohoel [SIZE=7](den ich, genau wie HSVMichi neulich schrieb, bis vor kurzem auch immer ro-ho-el gelesen habe :D)[/SIZE]


    Erst mal vielen Dank für eure Antworten :)


    Also: ich hab' eigentlich schon vor gut 2 Stunden angefangen, eine Antwort zu schreiben. Dann musste ich allerdings noch etwas anderes erledigen, wobei ich schon Idee habe, wo der Hund begraben liegt!


    Ich muss jetzt erstmal ein bisschen 'was ausprobieren und melde mich dann noch mal!


    Bis dahin, viele Grüße
    dj


    [edit]peinlicher Namenstippfehler korrigiert. Sorry rohoel!

    2 Mal editiert, zuletzt von deichjunge ()

    Die Belegung ist gut, das ganze Menu hat sich doch geändert, verglichen zur vorletzten Hardcopy. Und Du hast die Zuweisung an StM nochmal um 750 KB reduziert.


    Oder was willst Du mir mit dem letzten Shot sagen? ?(

    Jetzt ist es verständlicher. Deine bisherigen Shots zeigen, daß das V4-Menu deutlich weniger Resourcen benötigt als Deines von der V3.0. Interpretiere ich das jetzt durch die Änderungen richtig?
    Trotzdem, erhöhe mal lieber den StM auf mind. 1.5, besser 2.0MB, ich kenne das System nicht und wer weiß, was Du auf einmal für seltsame Phänomene erhälst.


    So, bin jetzt aber erstmal wech, :sleep

    So, nach einigen Unterbrechungen bin ich nu' endlich fertig mit dem Experimentieren :)


    Also:
    Bei meinem ersten Posting hatte ich noch einen Denkfehler: Durch mein PC-Verständnis bin ich davon ausgegangen, dass das RAM beim PNA aufgeteilt wird in Program Memory = Programmspeicher (zum Ausführen von Programmen) und Storage Memory = Datenspeicher (Speicher, in den Programme ihre Daten ablegen). Auch wenn ich hier im Forum mittlerweile schon viel gelesen habe, ist mir erst nach dem Posting von

    Zitat

    Original von Ralf25
    Das StM schaut bei mir immer gut aus, schon weil ich fast nix, außer ein paar Schriften und DLLs, im CE-Bereich installiert habe.


    und eigenem Experimentieren aufgegangen, dass das StM von allen Dateien belegt wird, die NICHT im ROM stehen, aber in den CE-Bereich geschrieben (bzw. kopiert) werden. Also alles, was irgendwelche zusätzlichen Programme an DLL's mitbringen (aygshell.dll & co.) und ins Windows-Verzeichnis schreiben, geht zu Lasten des StM und damit auch zu Lasten des des gesamten RAM und damit eben auch zu Lasten des PrM.
    Hab' ich's soweit richtig, Ralf?


    Soweit so gut. Nach einem Hardreset habe ich nur 300Kb StM belegt, damit also noch recht viel freien RAM bzw. PrM.


    Nun kommt das ABER:
    Werden nun die ROM- und andere Dateien aus dem Windows-Verzeichnis in einen Backup-Ordner kopiert und von dort wieder zurück in das Windows-Verzeichnis (mit der Option 'alle überschreiben') geschrieben, sind die ROM-Duplikate offensichtlich plötzlich 2x im Windows-Verzeichnis vorhanden! Ich konnte einmal beim Restore mit TotalCommander für wenige Sekunden beobachten, wie in der File-Liste tatsächlich die Duplikate namentlich sortiert direkt unter den Originalen auftauchten. Nach kurzer Zeit wurden die Dupliakte zwar nicht mehr in dem Verzeichnis angezeigt, aber der Speicherplatz, den sie dort belegten, wurde nicht mehr freigegeben! Dieser quasi doppelt belegte Speicherplatz machte, wie in meinem ersten Posting beschrieben, über 9 Mb aus.
    Ich hoffe, meine Ausführungen sind einigermaßen verständlich?;D


    ERGO:
    Will man eine vernünftige Backup-Restore-Lösung für seinen WinCE5 PNA, ohne dass nach dem Restore wichtiger Programmspeicher flöten geht, muss man aufpassen, dass beim Restore keine ROM-Dateien zurück in den CE-Bereich (also Windows-Verzeichnis) geschrieben werden, da sie sonst zusätzlichen StM und somit auch potentiellen PrM belegen.
    Das bedeutet: entweder eine ziemliche Friggelarbeit über ein manuelles Backup bzw. Backup-Skript (ROM-Dateien aussortieren) oder eine gekaufte Backup-Lösung, wie sie Ralf benutzt. Bei ihm scheint es ja so zu sein, das sein StM auch nach einem Restore schön klein bleibt.


    So, nun leg ich mich aber auch mal ins Bett... :sleep


    Nochmal danke für eure Anregungen!
    Viele Grüße
    dj


    [edit] Tja, mit dem Wissen, dass ich jetzt habe, verstehe ich auch erst den Aufwand, der dem von m.g. veröffentlichten Backup-Mort-Skript zugrunde liegt. In diesem Skript werden nämlich, wenn ich es richtig verstanden habe, System-Files oder Read-Only-Files vor dem Backup aussortiert. Das bedeutet aber auch, dass man nach Programminstallationen evtl. neu ins Windowsverzeichnis geschriebene Dateien auf diese File-Attribute überprüfen muss, da sie ggfs. sonst nicht ins Backup genommen werden und nach Hardreset&Restore dann entsprechend fehlen. Oder? ?(

    2 Mal editiert, zuletzt von deichjunge ()

    Hi deichjunge,


    das Speichermanagement von WM5 unterscheidet sich wesentlich von dem des PC. Der int. Speicher setzt sich zusammen aus dem Anteil, der auf der Flash Disk (FD) und nicht flüchtig ist und dem RAM, dessen Inhalt nach Stromverlust weg ist.


    Das RAM wiederum beinhaltet alles im Program- und StorageMemory. Im Gegensatz zum PC, wo außer in einer RAM-Disk keine Files direkt angesprochen werden können, ist es beim PNA so, daß darin sehr wohl auch Installationen gespeichert werden können (-> Datenspeicher), nämlich alles außerhalb von der FD. Der Programmspeicher (Program Memory) dagegen ist direkt vergleichbar mit dem RAM vom PC.


    Das muß beim Aufsetzen natürlich berücksichtigt werden und kann mit entspr. Einstellungen noch weiter optimiert werden.


    Wenn also kurzzeitig Dateien aus Performancegründen nach \Program Files kopiert werden, muß der Anteil vom Datenspeicher (Storage Memory) erhöht werden, damit es nicht zum Overflow kommt. Nach dem eigentlichen Einsammeln der Daten ist es aber sinnvoll, diese auszulagern auf die FD, um damit den StM-Anteil wieder reduzieren zu können, was ja dem PM und damit den Prog. zur Runtime wieder zugute kommt.

    Zitat

    Original von deichjunge
    Das bedeutet aber auch, dass man nach Programminstallationen evtl. neu ins Windowsverzeichnis geschriebene Dateien auf diese File-Attribute überprüfen muss, da sie ggfs. sonst nicht ins Backup genommen werden und nach Hardreset&Restore dann entsprechend fehlen. Oder? ?(


    Genauso habe ich es auch verstanden, wobei m.g hierzu sicherlich kompetenter Auskunft geben kann, ich habe mir sein Skript nur gemopst ... :D


    Was aber kein so großes Drama ist, denn man kann ja dann bei Bedarf die entsprechenden neuen Dateien einmal mit dem richtigen Attribut versehen oder einen Kopierbefehel für diese zusätzlich ins Skript aufnehmen.


    Gruß

    Hi Ralf!


    Zitat

    Original von Ralf25
    das Speichermanagement von WM5 unterscheidet sich wesentlich von dem des PC. Der int. Speicher setzt sich zusammen aus dem Anteil, der auf der Flash Disk (FD) und nicht flüchtig ist und dem RAM, dessen Inhalt nach Stromverlust weg ist. Das RAM wiederum beinhaltet alles im Program- und StorageMemory.


    Danke nochmal für deine Aufklärungshilfe! Jetzt habe ich endlich den Durchblick!



    Zitat

    beim PNA [ist es] so, daß darin sehr wohl auch Installationen gespeichert werden können (-> Datenspeicher), nämlich alles außerhalb von der FD. [...] Das muß beim Aufsetzen natürlich berücksichtigt werden und kann mit entspr. Einstellungen noch weiter optimiert werden.


    Da ja auch das WinCE-Verzeichnis dem StM zugeordnet ist (ohne dass die ROM-Files StM belegen, sondern nur zusätzliche Installationen), frage ich mich, ob es nicht möglich wäre, das Windows-Verzeichnis nach FD zu verschieben (könnte mit Registry-Hack klappen). Genial wäre ein Mortscript, dass diese Aufgabe nach einem Hardreset übernimmt. Ob das klappt, probiere ich mal aus, wenn ich ganz viel Zeit habe. :D



    Zitat

    Wenn also kurzzeitig Dateien aus Performancegründen nach \Program Files kopiert werden, muß der Anteil vom Datenspeicher (Storage Memory) erhöht werden, damit es nicht zum Overflow kommt. Nach dem eigentlichen Einsammeln der Daten ist es aber sinnvoll, diese auszulagern auf die FD, um damit den StM-Anteil wieder reduzieren zu können, was ja dem PM und damit den Prog. zur Runtime wieder zugute kommt.


    Das klingt einfach nur 'geil' :D - ich hab's aber trotzdem verstanden! Ich habe mal angefangen, die Inhalte dieses Threads (Speicheraufteilung/die Probleme, die sich bei Hardreset und Restore ergeben/mögliche Lösungen der Probleme bzw. Speichertuning) auf Computer-Bild-Niveau herunter zu brechen und für Einsteiger zusammen zu fassen. Wenn ich fertig bin, werde ich es hier mal posten.


    Viele Grüße an alle und habt einen schönen Sonntag!
    dj