|
 |
 |
 |
|
|
c't Projekte - c't-Bot und c't-Sim -
Mailinglisten
[Voriger (Datum)]
[Nächster (Datum)]
[Voriger (Thread)]
[Nächster (Thread)]
[Nach Datum][Nach Thread]
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
|
|
|