Thema: Timer-Interrupt

[clemensoft]

Also, ich brauche einen Interrupt, der in regelmäßigen Abständen vom Prozessor aufgerufen wird. Ich kenne nur 0x1C, der 18,2 mal pro Sekunde aufgerufen wird, der ist mir zu langsam. Bei Win***s gibt es doch auch so eine Timer-Funktion mit 1000 Ticks pro Sekunde, und wenn ich mich recht entsinne, gibt es im PC einen Baustein names Performance Counter mit einem Quarzkristall...

[joachim_neu]

interessiert mich auch! allerdings is 1000 switchs pro sekunde für MultiTasking a bisserl schnell, oda?

[clemensoft]

Nehmen wir mal an, jeder Task bekommt 100 ticks. Dann hat er genügend Zeit zum Rechnen, und nach 100t kommt dann der nächste dran. Das kann man so ausweiten, dass der Kernel 200 t bekommt, ein Microsoft-Programm 1t, Open-Source-Programme eine Sekunde...

[TeeJay]

Also soweit ich weiß kann man den TImerchip auch umprogrammieren.
Sprich das er öfter als 18,2 mal pro Sek aufgerufen wird.

Und in der Tat gibt es einen Befhel "rtdsc" oder so.
Der Prozessor erhöht jede Mikrosekunde den Wert darin, wenn ich mich recht erinnere.
Man kann damit also Funktionen a la GetTickCount() von WIndows nachbauen.

Der Befehl kann auch in einem Ring3 Programm benutzt werden.

[clemensoft]

Er heißt rdtsc, aber das hilft mir leider nicht. Das Teil muss selbstständig einen int auslösen, damit die gerade arbeitenden Programme ungestört arbeiten können. Das würde unglaublich viel Rechenzeit kosten, die ganze Zeit rdtsc auszuführen!

[joachim_neu]

du übersiehst bei deinem alle-1-ms-tick-int was! und zwar, dass das ausführen des int schon länger als 1 ms dauern würde, und sich das so überschlägt. und irgendwann ist dein stack zu groß, weil du nimmer zum iret des ints kommst! deswegen ist das mit den 100 ticks zwar praktisch, allerdings ist die vergleichroutine zu lange, als dass sie in 1 tick passt!

[clemensoft]

OK, aber mit 50 ms, da muss es doch was geben! Ich kann doch nicht ständig den Timestamp abfragen! Ich habe etwas dagegen, Billy Gates nachzuahmen

[joachim_neu]

*g* 50ms reicht natürlich! ich meinte, dass eine Millisekunde net reich!

[Jidder]

du übersiehst bei deinem alle-1-ms-tick-int was! und zwar, dass das ausführen des int schon länger als 1 ms dauern würde, und sich das so überschlägt. und irgendwann ist dein stack zu groß, weil du nimmer zum iret des ints kommst! deswegen ist das mit den 100 ticks zwar praktisch, allerdings ist die vergleichroutine zu lange, als dass sie in 1 tick passt!

Während du in einer ISR bist, kannst du die Ints deaktivieren (wird sogar automatisch bei der Auslösung des Ints gemacht) und schon bist du das Problem los. Um die Hardware-Ints wieder zu aktivieren musst du ein EOI (End of Interrupt) an den PIC (Programmable Interrupt Controller) senden.

RDTSC ist der Befehl um den Timestamp Counter (TSC) auszulesen. Dieses 64 bit Register wird bei jedem Takt um 1 erhöht. Also bei einem 200 MHz Prozessor wird er um 200.000.000 pro Sekunde erhöht. Wenn man die Prozessorfrequenz weiss kann man mit diesem Register viel genauer die Zeit messen, als mit den anderen Standardmöglichkeiten. Der TSC hat halt keine "Interruptanbindung" ...

Hier mal der Code, den ich verwende um bei meinem OS den PIT (Programmable Interrupt Timer) umzuprogrammieren:

Code: [Auswählen]

#define PIT_FREQ 1193181 // die Standardfrequenz des PIT
#define FREQ 20 // die Frequenz die wir haben wollen

void setup_pit()
{
int counter; // nur eine temporäre variable ...

counter = PIT_FREQ / FREQ; // (achtung: bei der wahl der frequenz die (ab)rundung bei division beachten! also nicht wundern wenn der timer irgendwann "vor-" oder "nachgeht")

// achtung bei mir ist es outb(value, port); !!!!!
outb(0x34, 0x43); // control word schreiben
outb(counter & 0xFF, 0x40); // an den Counter 0 die neue Frequenz schreiben
outb(counter >> 8, 0x40);   // --------- " ----------

// todo: interrupt handler installieren
}

[joachim_neu]

@Pork: ne! denn soweit ich weiß, kommt ein interrupt, der wartet gleich zum zuge, wenn das andere sich abmeldet. das heißt also, dass entweder direkt nach dem EOI, also noch vor dem iret oder nach dem iret das int wieder aufgerufen wird. man hat also keine zeit für den task, weil gleich wieder geswitcht wird. allerdings denke ich, dass 18,2 switches schon reichen... und was ist der PIT? wird damit umgeschrieben, wie oft das Int 0x00 aufgerufen wird?

mfg

J!N

[Jidder]

@Pork: ne! denn soweit ich weiß, kommt ein interrupt, der wartet gleich zum zuge, wenn das andere sich abmeldet. das heißt also, dass entweder direkt nach dem EOI, also noch vor dem iret oder nach dem iret das int wieder aufgerufen wird.

jo aber erst das iret aktiviert die interrupts wieder. erst wenn das iret das interrupt flag setzt kann wieder ein interrupt auftauchen.

man hat also keine zeit für den task, weil gleich wieder geswitcht wird. allerdings denke ich, dass 18,2 switches schon reichen...

ich würd sagen nein. wenn du z.b. ein os mit 30 offenen anwendungen hast, dann kannst du ja mit bloßem auge sehen welches programm gerade am zug ist und gerade arbeitet.

und was ist der PIT? wird damit umgeschrieben, wie oft das Int 0x00 aufgerufen wird?

nope. der PIT ist das teil was den IRQ 0 auslöst. und den kann man entsprechend programmieren wie oft er das tun soll. (der PIT macht auch noch mehr und was das genau ist verrät google.)

[Roshl]

Mein PIT ist auf 250 Hz programmiert, also 250 Switches pro Sekunde.
1ms ist viel, sogar sehr viel. Der Taskhandler der eine Milliesekunde muss wirklich äusserst schlecht gecodet sein. Auf einem 1MHZ prozessor (MHZ nicht GHZ) hat man 1000000 Takte durch 1000 (1ms) wären das 1000 Takte, und solange sollte kein Taskhandler brauchen, im worstcase hat meiner vielleicht wenns sehr hoch kommt 200-250. Und da wir heute im Bereich von     mehreren GHZ sind, ist 1ms so extrem viel^^  1GHZ->1Millionen Takte pro Task pro Sekunde, wenn wir bei 1000Hz für den PIT sind. Die Reelle Rechenzeit für den Task hängt also nur von der  PIT-Frequenz und von der Rechengeschwindigkeit der CPU ab, der Taskhandler fällt da kaum ins Gewicht.

PS: 1000 Switches ist nicht sonderlich viel, wenn man daran denkt das Videoschnitt, MP3-Audio, 3D-Rendering nebeneinanderlaufen können ohne irgendwo zu stocken!  1000 ist eher so normal^^
PPS: Soll ich noch mehr Rechnereien machen?

[TeeJay]

Naja das mit den 1000 Switches ist etwas sehr pauschal ausgedrückt.
So viele Tasks hat man ja kaum am laufen.
Und dann kommt ja auch noch zum tragen mit welcher Priorität der Task läuft.

10 ms Timeslice soll sehr oft benutzt werden wie ich gelesen habe. Und man muss sich mal überlegen das damit 100 Tasks pro Sekunde laufen könnten. Und selbst wenn man so viele Tasks am laufen hat, sind die meisten die größte Zeit eh inaktiv.

[Roshl]

Es ging hauptsächlich darum das joachim behauptet das 18,2 ausreichen und sich die IRQ sonst überschneiden würden, was purer blödsinn ist. Ausserdem diente 1000 nur als theoretisches Rechenbeispiel.

[joachim_neu]

Es ging hauptsächlich darum das joachim behauptet das 18,2 ausreichen und sich die IRQ sonst überschneiden würden, was purer blödsinn ist. Ausserdem diente 1000 nur als theoretisches Rechenbeispiel.

achtung! du hast da was falsch verstanden! ich sagte bei 1000 aufrufen pro sekunde würden sie sich (zumindest bei mir) überschneiden! und warum sollten 18,2 net ausreichen?

[clemensoft]

Das menschliche Auge sieht ca. 24 Bilder pro Sekunde. Das Heißt also, damit dein Auge das Multitasking nicht bemerkt, muss JEDER Task mindestens 24 mal pro Sekunde ablaufen, was bei 3 Tasks schon 72 Mal pro Sekunde wechseln.

[TeeJay]

Also das mit den Bildern und dem Auge hat beim Taskwechsel nicht wirklich eine Rolle *G*

Wenn du Musik decodierst (mp3 z.B.) dann muss das nicht 24 mal pro sekunde der Task laufen. Er muss nur so oft laufen, das immer für die jeweils nächsten paar Sek die Musik decodiert wird, damit man keine Aussetzer hat.....

[joachim_neu]

er hat recht, wenn jedes programm sein fenster zeichnen muss, was er warscheinlich so meint. allerdings ist es ja so, dass man net wie in einem film immer wieder die fenster aktualisiert, sondern nur dann, wenn sie sich geändert haben.

[Roshl]

18,2 reicht aber definitiv nicht. Hättest du zum Beispiel nen Microkernel (so wie ich einen bastle) dann hast du einen Task der alle Aufgaben in Sachen Video übernimmt, die anderen Tasks melden dem nur was sie wollen. So bei 8 Tasks (ausser dem Videotask) würde der somit nur 2 mal pro Sekunde drankommen, also könnte das bild da nur 2 mal pro Sekunde gepinselt werden. Counter-Strike mit 2 Frames/s? Na supi:P
Bei einem Monokerlen mag das ja vielleicht anders aussehen, je nach Implementierung von dem ganzen. Hier reicht es halt nicht zu sagen RM PM usw. sondern das OS-Kernel-Design ist da wichtig.

[joachim_neu]

ich weiß, dass 18,2 da net reichen. bei mir ist es allerdings so, dass ich einen buffer hab, und ein int, dass den buffer überspielt. dadurch wird das nur nötig, wenn sich etwasverändert. sonst net. außerdem kann man bei mir alle anderen tasks pausieren, wenn man max. leistung braucht.