c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot] virtual memory management ?

Absender: Timo Sandmann
Datum: Di, 29.05.2007 12:58:49
In-reply-to: <812F86EC9E1A96489D5E83C2AB7D6886FE37F1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <812F86EC9E1A96489D5E83C2AB7D6886FE37F1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>


Hallo,

Am 29.05.2007 um 07:35 schrieb Menzel, Frank IT-OO4:
Hallo,
Besten Dank. Der Trick war, in die neu erzeugte .dat-Datei "MAP" via HEX-Editor reinzuschreiben.

ja, ich habe gerade mal den PC-Bot um zwei Funktionen ergänzt,
ct-Bot.{elf | exe} -e 1024 MAP 4096
erzeugt in der mmc_emu.dat eine Mini-Fat-Datei "MAP" an der Adresse 1024 (0x400) mit der Größe 4 MB. Und
ct-Bot.{elf | exe} -d MAP
löscht diese Datei innerhalb von mmc_emu.dat wieder (falls man eine leere Map oder eine Map anderer Größe möchte, kann man dann eine Neue erstellen).

Außerdem setzt der Sim nun das Arbeitsverzeichnis des Bots auf das Verzeichnis, in dem auch das Bot-Binary liegt, damit der Bot Dateien (z.B. mmc_emu.dat oder map.pgm) immer an der selben Stelle erzeugt / liest, egal ob von der Konsole oder vom Sim aus gestartet.

Nun habe ich mal die Statistik via VM_STATS_AVAILABLE eingeschaltet zur Ausgabe der Map-Statistik. Die Daten werden mir auch wunderschön ausgegeben, jedoch ist die Doku dazu nicht aussagekräftig genug, um die Daten auch deuten zu können. Wann spricht man in diesem Zusammenhang z.B. von Seitenflattern bzw. wie müssen die Statistikdaten denn aussehen, damit dies nicht auftritt ?

Als erstes ist wichtig, auf was MAX_SPACE_IN_SRAM in mmc-vm.c eingestellt ist für den PC-Fall. Einem ATmega32 entspricht 1 oder 2, einem ATmega644 entspricht 4 oder 5 (der ATmega644 hat mehr RAM und deshalb kann mehr gecached werden). Bei der Statistik ist dann vor allem interessant, wie viel Seitenauslagerungen pro Sekunde es gibt. Ein Seitenwechsel auf dem echten Bot dauert bei einer nicht allzu langsamen SD-Karte rund 4 ms. Im Sim gibt es alle 10 ms einen neuen Bot-Zyklus, also besteht eine "Sim-Sekunde" aus 100 Bot-Zyklen. Gab es nun laut Statistik beispielsweise 500 Seitenwechsel pro Sekunde, dann folgt daraus, dass es pro Bot-Zyklus 5 Seitenwechsel gab (jedenfalls im Durchschnitt). Rechnet man das zurück auf den realen Bot, so verzögert sich dort ein Bot-Zyklus um 5*4 ms, also 20 ms (angenommen es gibt genauso viel Lese- und Schreibzugriffe auf die MMC wie im Sim). Dauert ein Bot- Zyklus auf dem realen Bot "normalerweise" 1.5 ms, so dauert er mit den angenommenen MMC-Zugriffen dann 21.5 ms, also ca. 14 mal so lange. Folglich ist die Reaktionszeit (z.B. auf einen erkannten Abgrund) im Beispiel 14 mal so hoch wie ohne MMC-Zugriffe, denn der Bot arbeitet ja nicht preemptiv.

Man muss dazu allerdings mmc_print_statistic() möglichst bald oder während solch einer "Messfahrt" aufrufen, denn sonst läuft die Zeit weiter, es gibt aber keine Seitenwechsel mehr und die Wechselrate nimmt mit der Zeit ab. Lässt man den Bot aber ein paar Minuten fahren und gibt dann die Statistik aus, fällt das kaum ins Gewicht, nur 20 s Messfahrt und 3 Minuten Wartezeit, bevor man mmc_print_statistic() aufruft, würde das Ergebnis umbrauchbar machen. ;)

Der ganze Spaß war / ist erstens dazu gedacht so ungefähr ausrechnen zu können, wie stark der Bot durch die MMC-Benutzung "verlangsamt" wird und um zweitens z.B. den Map-Code so optimieren zu können, dass es möglichst viele Cache-Hits und somit möglichst wenige Seitenwechsel gibt, denn im Sim lässt sich das mit einer emulierten MMC viel einfacher austesten als beim echten Bot.

Beim Einschalten der Defines kommen einige Warnings, die ich aber erst mal ignoriert habe.

Ich denke die müssten jetzt auch weg sein.

Viele Grüße,
Timo