Thema: Konzept für periodische Events

[kevin]

Dieses System mit APM, dass die CPU runtergetaktet wird, wenn keine Bildschirm- oder Tastaturaktivität passiert, ist doch insofern sinnvoll, als dass bei Nutzeraktivität - also interaktiver Nutzung des Systems - die Leistung da ist, sonst aber sofort wieder Strom gespart wird.

Wird so eine Logik tatsächlich implementiert? Das ist doch völlig kaputt. Wenn es grad keine Bildschirm- oder Tastaturaktvität gibt, dann warte ich vielleicht grad bis er den Kernel fertig durchgebaut hat (oder sonst irgendwas fertiggerechnet hat). Wenn er als Reaktion darauf den Kernel dann noch langsamer baut - ich weiß ja nicht...

[FlashBurn]

Wenn das BIOS nun aber deine CPU unbenachrichtigt und ungewollt für 2ms abschalten kann, weil es selbst was tun will, dann ist deine Zeitgenauigkeit doch ohnehin fürn Popo. Das betrifft dann auch Systeme mit HPET.

Ich will ja nicht so aus der Haut fahren wie du, aber wenn sowieso alles "fürn Popo" ist, wozu dann der ganze Ärger

Also CPU und HPET/PIT/ACPI-PMT (und auf neueren CPUs auch der TSC) laufen auch wenn die CPU irgendwie runtergetaktet oder abgeschaltet ist (bzw. wird das komplette Abschalten der CPU sowieso nicht gehen, weil es länger als 2ms dauern dürfte diesen Zustand zu erreichen und auch wieder aus ihm heraus zu kommen)!

Was APM betrifft, so kann dies im BIOS deaktiviert werden bzw. kannst du einstellen ob das BIOS eingreifen soll oder halt nicht.

Dieses System mit APM, dass die CPU runtergetaktet wird, wenn keine Bildschirm- oder Tastaturaktivität passiert, ist doch insofern sinnvoll, als dass bei Nutzeraktivität - also interaktiver Nutzung des Systems - die Leistung da ist, sonst aber sofort wieder Strom gespart wird.

Wie auch taljeth schon meinte, ist das "kaputt". Denn warum kann z.B. gerade keine Benutzeraktivität stattfinden? Vielleicht, weil der Nutzer darauf wartet das der PC fertig wird? Wenn dann auch noch die CPU runtergetaktet wird, dann dauert es ja noch länger und würde im Endeffekt heißen, du verbrauchst mehr Strom als wenn du die CPU nicht runtergetaktet hättest! Da ist also wirklich was kaputt

Zumal viel interessanter wäre doch zu wissen, von was für Zeiten wir hier sprechen? Ich meine wird das gemacht, wenn der Nutzer mal 1s nichts macht oder erst nach 3Minuten? Das spielt dann nämlich schon eine Rolle.

Zweite Sache, betrifft neuere Systeme mit ACPI: Wie ich neulich auf irgendeiner Kernel-ML gelesen habe, haben moderne BIOSse ebenfalls im Zusammenhang mit Stromsparmodi die Möglichkeit, jederzeit die CPU anzuhalten und/oder in spezielle Modi (SMBUS, ...) zu schalten. Und zwar für Dauern jenseits einiger Millisekunden! Unabhängig vom Betriebssystem! Damit meine ich nicht runtertakten, sondern Selbstverwaltung. Runtertakten kriegst du ja wenigstens noch mit, bzw. kannst du im Zweifelsfall drauf achten.

Auch hier gilt wieder, wenn das wirklich so passiert, fällt das dem Nutzer auf oder es passiert zu Zeiten, wo es eh keinen interessiert. Wenn es dem Nutzer aber auffällt und das System ständig "stockt", dann wird er das Gerät zurückgeben und die werden das ganz schnell wieder ändern! Denn mehrere ms sind für einen PC, besonders für einen modernen, ne halbe Ewigkeit!

Wenn du mal die Quelle nennen könntest, dann könnte ich mal nachsehen, was da wo und wann passiert.

[Svenska]

Was APM betrifft, so kann dies im BIOS deaktiviert werden bzw. kannst du einstellen ob das BIOS eingreifen soll oder halt nicht.

Womit du dann jegliche Form des Stromsparens abschalten kannst, richtig. Das geht im Übrigen auch per APM-Treiber (POWER.EXE kann das), dort kannst du das Gesamt-APM-System auch abschalten; zumindest auf diesem System.

Dieses System mit APM, dass die CPU runtergetaktet wird, wenn keine Bildschirm- oder Tastaturaktivität passiert, ist doch insofern sinnvoll, als dass bei Nutzeraktivität - also interaktiver Nutzung des Systems - die Leistung da ist, sonst aber sofort wieder Strom gespart wird.

Wie auch taljeth schon meinte, ist das "kaputt". Denn warum kann z.B. gerade keine Benutzeraktivität stattfinden? Vielleicht, weil der Nutzer darauf wartet das der PC fertig wird? Wenn dann auch noch die CPU runtergetaktet wird, dann dauert es ja noch länger und würde im Endeffekt heißen, du verbrauchst mehr Strom als wenn du die CPU nicht runtergetaktet hättest! Da ist also wirklich was kaputt

Grundgedanke: Wenn ich etwas interaktiv tue, dann sehe ich Reaktionen auf dem Bildschirm, sei es der Mauszeiger, seien es die Logmeldungen beim Kernelbau. So falsch ist der Gedanke nicht. Ich rede im speziellen von Geräten Anfang der 90er Jahre! Und da führte eine Aktion auch meist zu einer schnellen Reaktion oder einer Fortschrittsanzeige... oder man bewegt halt mal kurz die Maus unter Windows oder drückt kurz Shift.

Zumal viel interessanter wäre doch zu wissen, von was für Zeiten wir hier sprechen? Ich meine wird das gemacht, wenn der Nutzer mal 1s nichts macht oder erst nach 3Minuten? Das spielt dann nämlich schon eine Rolle.

Im BIOS (nicht im Betriebssystem) einstellbar zwischen 1/4s und 1min, in zwei Stufen, die Taktreduktion einstellbar zwischen 1/1 CLK bis 1/16 CLK, bei 25MHz Grundtakt. (Also z.B. nach 1/4 Sekunde den Takt auf 12 MHz =1/2CLK reduzieren, nach 15 Sekunden dann auf 3 MHz =1/8CLK.)

Zweite Sache, betrifft neuere Systeme mit ACPI: Wie ich neulich auf irgendeiner Kernel-ML gelesen habe, haben moderne BIOSse ebenfalls im Zusammenhang mit Stromsparmodi die Möglichkeit, jederzeit die CPU anzuhalten und/oder in spezielle Modi (SMBUS, ...) zu schalten. Und zwar für Dauern jenseits einiger Millisekunden! Unabhängig vom Betriebssystem! Damit meine ich nicht runtertakten, sondern Selbstverwaltung. Runtertakten kriegst du ja wenigstens noch mit, bzw. kannst du im Zweifelsfall drauf achten.

Auch hier gilt wieder, wenn das wirklich so passiert, fällt das dem Nutzer auf oder es passiert zu Zeiten, wo es eh keinen interessiert. Wenn es dem Nutzer aber auffällt und das System ständig "stockt", dann wird er das Gerät zurückgeben und die werden das ganz schnell wieder ändern! Denn mehrere ms sind für einen PC, besonders für einen modernen, ne halbe Ewigkeit!

Ja, für den PC... dem Menschen wird diese halbe ms bestimmt nicht auffallen. Außerdem passiert das in der Regel ja auch nicht ständig alle 10 Takte, dass das System für 10000 Takte steht, sondern unter gewissen Randbedingungen (Standby, Akkuladestand-Grenzwert erreicht, Bildschirmhelligkeitstaster betätigt, ...)

Das macht die Sache natürlich noch interessanter, da es sich um seltene Ereignisse handelt.

Wenn du mal die Quelle nennen könntest, dann könnte ich mal nachsehen, was da wo und wann passiert.

Hab ich nicht mehr, ging mir um die Suche nach einem gebrauchbaren Grafiktreiber für mein Netbook (VIA VX800 / Chrome9 IGP) bzw. einem Scheduler für die sehr langsame 2GB-SSD dadrin. an der Stelle auch wurde das auch nicht näher ausgeführt, nur angerissen. Hab es allerdings nach längerer Suche nicht wiedergefunden. War auf der LKML.

Gruß,
Svenska

[kevin]

Auch hier gilt wieder, wenn das wirklich so passiert, fällt das dem Nutzer auf oder es passiert zu Zeiten, wo es eh keinen interessiert. Wenn es dem Nutzer aber auffällt und das System ständig "stockt", dann wird er das Gerät zurückgeben und die werden das ganz schnell wieder ändern!

Auf einem Desktop wird das Bisschen niemanden jucken. Aber RT-Systeme stört es teilweise schon, dass im SMM Zeit verbraten wird.

[FlashBurn]

Auf einem Desktop wird das Bisschen niemanden jucken. Aber RT-Systeme stört es teilweise schon, dass im SMM Zeit verbraten wird.

Kommt halt wieder drauf an, wann es passiert. Wenn ich gerade einen HD-Film gucke und ACPI meint es müsste jetzt aus irgendeinem Grund mal die CPU schlafen legen oder runtertakten, dann dürfte der Film schon stocken. Das Beispiel ist jetzt insofern doof, weil ja die CPU arbeitet und auf dem Bildschirm tut sich ja auch was. Also dürfte ACPI da nicht auf solch eine Idee kommen.

Was mir da gerade noch auffällt, was hat der SMM jetzt mit meinem Timer zu tun? Die CPU läuft trotzdem weiter, genauso wie PIT/HPET und die anderen Sachen.

Womit du dann jegliche Form des Stromsparens abschalten kannst, richtig. Das geht im Übrigen auch per APM-Treiber (POWER.EXE kann das), dort kannst du das Gesamt-APM-System auch abschalten; zumindest auf diesem System.

Dann spricht diese "POWER.EXE" bestimmt APM übers BIOS an und das könnte ich zur Not auch machen.

Ich rede im speziellen von Geräten Anfang der 90er Jahre!

Problem ist jetzt, das es sich also um Prä-Pentium Systeme handelt und ich/man nicht weiß ob das dann auch auf die späteren Systeme übertragen wurde. Dann kommt noch hinzu das du vor dem Pentium sowas wie einen TSC nicht hattest und wie gesagt, die anderen Timer interessiert das nicht ob die CPU runtergetaktet ist.

Ja, für den PC... dem Menschen wird diese halbe ms bestimmt nicht auffallen. Außerdem passiert das in der Regel ja auch nicht ständig alle 10 Takte, dass das System für 10000 Takte steht, sondern unter gewissen Randbedingungen (Standby, Akkuladestand-Grenzwert erreicht, Bildschirmhelligkeitstaster betätigt, ...)

Und genau in diesen Randbedingungen kann ich dann mal auf die Genauigkeit verzichten Weil brauchen tust du sie nur, wenn der Nutzer wirklich was macht, z.B. spielen, Film gucken oder ähnliches und dann dürften diese Sachen auch nicht auftreten.

[Svenska]

Im Normalfall wird ein HD-Film im Voraus dekodiert, die Videodarstellung erfolgt meist über DMA in die entsprechenden Pages im Videospeicher in Form eines Overlays, welches von jeder halbwegs modernen 2D-Grafikkarte unterstützt wird. Außerdem gilt: 1/(2ms) = 500 Hz. Das fällt bei einem Video nicht auf.

Die Taktrate in modernen Systemen hängt von der aktuellen Auslastung der CPU ab und ändert sich während des Video-guckens trotzdem, da der Dekodieraufwand auch vom Inhalt des Videos abhängt.

Wenn die CPU sich im SMM befindet, läuft sie zwar weiter, aber du hast weder Informationen über den aktuellen Zustand der CPU, noch führt sie deinen Code aus. Und wenn zwischendrin der TSC auch noch kaputt geht (was ich in dem Szenario allerdings bezweifle), dann verwirrt das deinen Scheduler, wenn du ihn auf den TSC festpinnst.

POWER.EXE ist der APM-Treiber für MS-DOS. Er kann "POWER ON", "POWER OFF", "POWER AUTO" (=BIOS-Einstellungen, z.B. nur aktiv bei Akkubetrieb). Mehr kann er nicht.

Diese Art des Power Managements kann ich direkt bei einem 486er hier beobachten, der hat keinen TSC. Frühe Pentium-Systeme haben einen TSC - und das Power Management dürfte sich zwischen 486SL und Pentium-SL nicht wesentlich unterscheiden. Was nicht heißt, dass es überall genau so implementiert wurde, aber ich hatte ein Pentium-Notebook (P75), der ein ähnliches Verhalten zeigte. Zumindest war das Power Management recht seltsam. Ist ein - inzwischen defektes - TI Extensa gewesen.

Deinen letzten Nachsatz würde ich mir nochmal durch den Kopf gehen lassen... ein Scheduler, der dann (und nur dann) Amok läuft, wenn jemand die Bildschirmhelligkeit verändert und gleichzeitig das System nutzt... nun, das passiert in Vorlesungen bei uns öfter mal, dass man MATLAB nutzt und jemandem was zeigen will, oder ein Video guckt, oder oder oder...

Übrigens schweifen wir vom Thema inzwischen weitreichend ab. Ich wollte nur sagen, dass der TSC meiner Meinung nach - anhand von Beispielen, die ich real gesehen und wovon ich gelesen habe - nicht grundlegend für deinen Anwendungsfall geeignet ist und ich daher von dessen Verwendung in dem Zusammenhang abrate.

Gruß,
Svenska

[FlashBurn]

Deinen letzten Nachsatz würde ich mir nochmal durch den Kopf gehen lassen... ein Scheduler, der dann (und nur dann) Amok läuft, wenn jemand die Bildschirmhelligkeit verändert und gleichzeitig das System nutzt...

Naja, der Scheduler läuft ja in dem Sinne nicht Amok (und noch nutze ich meinen Counter nicht für meinen Scheduler und werde es höchst wahrscheinlich auch nicht machen), das einzige was passiert ist, das er die Zeit welcher ein Thread gelaufen ist (dann zu wenig) falsch berechnet oder das er einen Thread zu früh aufweckt (was ich schon als schlimmer bezeichnen würde).

Dann kommt noch hinzu das es nur Prä-ACPI Systeme betrifft und ansich gab es ACPI schon zu Sockel7 Zeiten!

Im Normalfall wird ein HD-Film im Voraus dekodiert, die Videodarstellung erfolgt meist über DMA in die entsprechenden Pages im Videospeicher in Form eines Overlays, welches von jeder halbwegs modernen 2D-Grafikkarte unterstützt wird. Außerdem gilt: 1/(2ms) = 500 Hz. Das fällt bei einem Video nicht auf.

Ich muss nochmal auf die 2ms zurück kommen. Ich habe mir deinen Satz, wo du diese erwähnst, nochmal durchgelesen. Was meintest du da, dass das BIOS die CPU runtertaktet oder das es selbst etwas tun möchte (z.B. SMM)? Ersteres würde den TSC stören, letzteres nicht.
Und wenn diese 2ms nicht auffallen, dann fällt es auch nicht auf das mein Timingsystem kurz aus dem Tritt gebracht wurde. Denn selbst wenn ich jetzt davon ausgehe, das der TSC komplett (!!) stehen bleibt, dann "verechnet" sich mein Timingsystem bis zum nächsten periodischen Int (max 62,5ms - 2ms) um eben diese 2ms. Ich denke damit kann man leben, immernoch genauer als nur eine periodische Quelle mit einem Intervall von 15ms!

Der Vorteil bei meinem System ist doch, das es ziemlich fehlertolerant ist und genau solche Sachen wenig bis gar nicht stören, bzw. schnell wieder korrigiert sind.

Diese Art des Power Managements kann ich direkt bei einem 486er hier beobachten, der hat keinen TSC. Frühe Pentium-Systeme haben einen TSC - und das Power Management dürfte sich zwischen 486SL und Pentium-SL nicht wesentlich unterscheiden. Was nicht heißt, dass es überall genau so implementiert wurde, aber ich hatte ein Pentium-Notebook (P75), der ein ähnliches Verhalten zeigte. Zumindest war das Power Management recht seltsam. Ist ein - inzwischen defektes - TI Extensa gewesen.

Ich werde mir wohl mal ein oder ein paar alte Notebooks beim eBay ersteigern müssen. Wollte ich eh mal machen, damit ich was zum Testen habe und so habe ich gleich noch einen Grund mehr.

Übrigens schweifen wir vom Thema inzwischen weitreichend ab. Ich wollte nur sagen, dass der TSC meiner Meinung nach - anhand von Beispielen, die ich real gesehen und wovon ich gelesen habe - nicht grundlegend für deinen Anwendungsfall geeignet ist und ich daher von dessen Verwendung in dem Zusammenhang abrate.

Mein Problem ist nur, das es nichts anderes/besseres gibt und das ich mit den Unzulänglichkeiten leben kann, aus den Oben genannten Gründen. Auch gilt dies nur für, wie gesagt, Prä-ACPI Systeme. Alles was ACPI kann hat den PMT oder ist so neu, das ich mich (und Linux auch wieder, rein aus performance Gründen) wieder auf den TSC verlassen kann!

Um nochmal auf das Powermanagement zurück zu kommen, die hatten damals noch keine Internetwerbung im Sinn Denn wenn der Bildschirm nicht ausgeht und/oder sich die CPU nicht runtertaktet, weil die Werbung sich ständig ändert (CPU + Bildschirmarbeit) wird gar kein Strom gespart

[Svenska]

Richtig. Nur noch eine Anmerkung als Nachsatz: Die gesamte SMM-Problematik trifft auf neuere Rechner mit ACPI zu. Der TSC ist auf den meisten aktuellen Systemen nicht stabil (zumindest behauptet Linux das bei mir).

Die von mir angesprochene Problematik betrifft dann alte/sehr alte Systeme ohne ACPI und kann - das vermute ich stark - andere Probleme auf den TSC haben.

Grüßle

[erik.vikinger]

Hallo,

Nochmal was zur Genauigkeit. Was mir vorallem wichtig ist, das wenn ein Thread 20ms schlafen möchte und du nur ne periodische Quelle für nen Timer hast (z.B. den PIT) mit einem Intervall von 15ms, dann schläft der Thread mindestens 30ms (eventuell sogar mehr).

Jedes System hat eben seine Grenzen, die überwiegende Mehrheit der anderen Betriebssysteme macht das jedenfalls nicht viel besser (zumindest als es noch keinen HPET gab).

ob der Thread dann im Endeffekt 20,05ms oder 20,25ms geschlafen hat, ist mir erstmal egal (und sollte mehr oder weniger zu vernachlässigen sein).

Ich verstehe Dich ehrlich gesagt nicht, erst schreibst Du von Nanosekunden (bis Du damit wirklich was sinnvolles anfangen kannst wird noch eine ziemlich große Menge an Silizium (oder gar was anderes) durch die Fabs der CPU-Hersteller fließen) und nun sind Dir mal eben so ganze 200000 davon einfach egal. Ich glaube Du solltest noch mal gründlich über Deine konkrete Zielvorstellung nachdenken.

Ich nehme ne nsek Auflösung weil es sich damit am einfachsten Rechnet

Für Dich vielleicht, aber die CPU hat am wenigsten Arbeit wenn sie direkt mit den Timer-Ticks umgehen darf (da muss dann gar nichts gerechnet werden) und die libc in den User-Programmen die Wünsche per GetTicksPerSecond passend umrechnet.

und ich mir nicht alzu große Sorgen über schnelle CPUs (>4GHz) machen muss

Mit ordentlicher Programmierung musst Du Dir über die Taktfrequenz der CPU eh keine Sorgen machen.

Also in meinem Bootloader berechne/messe ich die Frequenz des TSC

Wer garantiert Dir dass das BIOS die CPU mit Maximal-Frequenz übergibt. Es könnte doch auch sein dass das BIOS die CPU nur mit kleiner Kraft ins Rennen schickt (während eines typischen OS-Starts wartet die CPU eh meist darauf das die einzelnen OS-Teile von der HDD geliefert werden) und das hochtakten dem OS überlässt (ich hab das mal bei einem Business-PC gesehen).

(in einer Zeit von 110ms wimre)

Das ist IMHO zu kurz, ich hab das damals mit gut 2 Sekunden gemacht. Mit 18 Messwerten wo ich vor der Durchschnittsbildung noch den größten und den kleinsten Messwert entfernt habe.

Noch eins: selbst wenn Du alle obigen Probleme lösen solltest bleibt das der TSC keine IRQs generieren kann. Wenn ein sleep(20) auch wirklich exakt 20ms dauern soll bleibt also nur aktives Warten.

Hier kommt doch wieder mein toller One-Shot-Scheduler ins Spiel Mit Hilfe des Counters und diesem Scheduler kann ich, mehr oder weniger, genau die Threads wieder aufwachen.

Hä, bitte genauer erklären. Willst du neben einem periodischen PIT-Timer noch parallel einen One-Shot-PIT-Timer starten?

Ich verstehe nicht ganz was du mit Aufwand meinst?

Na das Du überhaupt mit mehreren unterschiedlich schnellen Timern arbeiten möchtest. Ich persönlich bin der Meinung das Du Dir da einen dicken Haufen komplizierte Arbeit schaffst und im Endeffekt nicht viel besser wirst als wenn Du Deine Zeit in einen anderen Aspekt Deines OS investieren würdest.

ist nur ne Motivation dich mit noch besseren Argumenten von meinem System zu überzeugen

Du kannst mich nicht überzeugen, auf meiner Plattform wird es etwas ähnliches zum HPET geben, einen 64Bit-Counter der monoton läuft, sich nicht beeinflussen lässt und eine auslesbare Frequenz benutzt zusammen mit 4 Comparatoren. Auf sowas wie den PIT würde ich mich freiwillig nicht mehr einlassen. Die Zeitscheiben sollen auf meiner Plattform die CPUs selber verwalten, ähnlich dem Local-APIC-Timer.

Aber mal ehrlich, ich finde so doll unterscheiden sich die beiden Systeme nicht

Ich finde schon das sich unsere Ideen da massiv unterschieden ich setze auf einen monotonen Counter (der breit genug ist damit er nicht ständig überläuft) mit flexiblen Comparator (welcher bei einem beliebigen Counter-Wert einen IRQ auslösen kann) und wenn das nicht in HW zur Verfügung steht dann würde ich das per SW und einem periodischem IRQ simulieren (nur eben mit deutlich kleinerer Zählgeschwindigkeit als bei der HW-Lösung). Für die User-Programme macht das dann keinen Unterschied, solange die immer brav in Ticks umrechnen.

Ich nutze halt noch ne 2. Quelle um auch Events innerhalb des Intervalls auslösen zu können.

Das mit dem "auslösen" musst Du mir bitte noch erklären. Weder TSC noch ACPI-PMT können das.

dann denke ich mal das dort auf keinen Fall die CPU irgendwie runtergetaktet wird.

Ich denke das Du da irrst. Gerade die PC-Zusammenschrauber die eher große Serien auflegen (wie DELL, HP oder Medion (soll keine Werbung sein)) bauen da manchmal eigene Dinge ein die nicht zwingenst zu irgendwelchen Standards passen. Wenn die dann ein eigenes proprietäres Windows-Programm fürs Power-Management aufspielen dann ist aus deren Sicht (die kennen NUR Windows) die Welt in Ordnung.

Da ich den TSC beim initialisieren meines Kernels auf allen CPUs synchronisiere

Was? TSCs synchronisieren, wie soll das denn bitte gehen? Und selbst wenn das gehen sollte, was denkst Du wie genau so eine Synchronisation per SW wäre?

die dürften auf solch alten Systemen auch noch nicht auseinandertriften

Das ist eine unbewiesene Annahme. Du solltest erst einmal (bis Du diese Annahme sicher bewiesen hast) vom Gegenteil ausgehen. Nach meiner Beobachtung driften die ganz sicher auseinander, die Frage ist nur wie schnell.

Ich habe gerade mal meine Berechnung wie lange ein TSC-Tick dauert ein wenig verändert und siehe da ist schon genauer. Auf einem AMD K6-200 bekomme ich 200440990Hz und auf einem Celeron 400 bekomme ich 401767778Hz.

Bist Du schon mal auf die Idee gekommen das die dafür benutzten Quarze alles andere als genau sind? Die sind in aller erste Linie billig. Mit ein bis zwei Prozent Abweichung vom Soll musst Du auf jeden Fall rechen. Und wieso eigentlich "Berechnung"? Du solltest das messen.

Wenn ich an einer Konstante noch ein wenig Pfeile

Solche Aussagen erwecken, zumindest bei mir, nicht gerade Vertrauen. Du musst die TSC-Frequenz messen und nicht irgendwie ins gewünschte Ziel hinrechnen!

und sie funktioniert bis zu einer Taktfrequenz von 1000GHz!

Da bin ich aber mal gespannt! Wenn ich ne passende CPU hab prüfe ich das nach.


Grüße
Erik

[FlashBurn]

Ich verstehe Dich ehrlich gesagt nicht, erst schreibst Du von Nanosekunden (bis Du damit wirklich was sinnvolles anfangen kannst wird noch eine ziemlich große Menge an Silizium (oder gar was anderes) durch die Fabs der CPU-Hersteller fließen) und nun sind Dir mal eben so ganze 200000 davon einfach egal. Ich glaube Du solltest noch mal gründlich über Deine konkrete Zielvorstellung nachdenken.

Ich wollte am Anfang vorallem besser sein, als Windows mit einer Zeitscheibe von 15ms. Bevor, vorallem ihr, mich auf die Unzulänglichkeiten mit meinem System aufmerksam gemacht habt, wollte ich schon noch irgendwie ne nsek Auflösung erreichen, bzw. ich erreiche sie bestimmt auch auf vielen Systemen (wenn der ACPI-PMT genutzt wird), aber halt nicht auf allen und wenn auf den alten System, wo es nur nen PIT und ne RTC gibt, die Ungenauigkeit maximal (und das ist das wichtige, im optimalen Fall wird es wesentlich genauer) 0,25ms ist, dann finde ich habe ich mein Ziel eigentlich ganz gut erreicht.

Für Dich vielleicht, aber die CPU hat am wenigsten Arbeit wenn sie direkt mit den Timer-Ticks umgehen darf (da muss dann gar nichts gerechnet werden) und die libc in den User-Programmen die Wünsche per GetTicksPerSecond passend umrechnet.

Das ist dem geschuldet das ich mehrere Zeitquellen nutze und da ist es am einfachsten wenn ich in nsek umrechne.

Mit ordentlicher Programmierung musst Du Dir über die Taktfrequenz der CPU eh keine Sorgen machen.

Dann müsste ich aber 128bit Zahlen benutzen und es war schon nicht einfach Code für ne 64bit Division zu finden, bzw. fehlt mir immernoch Code (der halbwegs genau und schnell ist) für eine "64bit div 64bit = 64bit" Division. Oder was meintest du?

Wer garantiert Dir dass das BIOS die CPU mit Maximal-Frequenz übergibt. Es könnte doch auch sein dass das BIOS die CPU nur mit kleiner Kraft ins Rennen schickt (während eines typischen OS-Starts wartet die CPU eh meist darauf das die einzelnen OS-Teile von der HDD geliefert werden) und das hochtakten dem OS überlässt (ich hab das mal bei einem Business-PC gesehen).

Das hast du leider recht, ich gehe halt immer davon aus das die PCs so konstruiert sind das auch alternative Betriebssysteme drauf laufen und dazu zähle ich dann auch DOS und da ist es eher unwahrscheinlich das es die CPU runter/hochtaktet! Aber ich behalte das Problem mal im Hinterkopf, bzw. betrifft dies auch wieder nur neuere Systeme (auf alten sollte das wohl eher nicht passieren).

Das ist IMHO zu kurz, ich hab das damals mit gut 2 Sekunden gemacht. Mit 18 Messwerten wo ich vor der Durchschnittsbildung noch den größten und den kleinsten Messwert entfernt habe.

Ich müsste meinen Code mal noch auf nen paar mehr PCs testen, aber mit der Länge wird dann nur die Ungenauigkeit bei den absolut letzten Stellen besser.

Hä, bitte genauer erklären. Willst du neben einem periodischen PIT-Timer noch parallel einen One-Shot-PIT-Timer starten?

Nope! Ich hatte doch erklärt das wenn die Zeit bis zu einem Event (jetzt mal als Bsp) kleiner ist als das Intervall des periodischen Timers, das dann das Event an den Scheduler weitergereicht wird. Dieser löst das dann im Endeffekt aus (weckt als z.B. einen Thread auf). Der Scheduler wird halt entweder vom PIT oder vom APIC befeuert (je nach dem was auf dem PC zur Verfügung steht).

Na das Du überhaupt mit mehreren unterschiedlich schnellen Timern arbeiten möchtest. Ich persönlich bin der Meinung das Du Dir da einen dicken Haufen komplizierte Arbeit schaffst und im Endeffekt nicht viel besser wirst als wenn Du Deine Zeit in einen anderen Aspekt Deines OS investieren würdest.

Das hat was mit meiner Motivation zu tun Ich kann mich für die anderen Bereiche meistens nicht so richtig motivieren Ansonsten hast du natürlich recht, aber da es ein Hobby-OS ist, sollte ich so viel Zeit wie nötig reinstecken, so dass ich meine gesteckten Ziele erreichen kann, auch wenn ich dann bis an mein Lebensende daran arbeite!

Du kannst mich nicht überzeugen, auf meiner Plattform wird es etwas ähnliches zum HPET geben, einen 64Bit-Counter der monoton läuft, sich nicht beeinflussen lässt und eine auslesbare Frequenz benutzt zusammen mit 4 Comparatoren. Auf sowas wie den PIT würde ich mich freiwillig nicht mehr einlassen. Die Zeitscheiben sollen auf meiner Plattform die CPUs selber verwalten, ähnlich dem Local-APIC-Timer.

Ich kann da noch nicht aus eigener Erfahrung sprechen, aber die Linuxleute sind nicht so sehr von dem HPET begeistert, wimre wird die Genauigkeit durch die Langsamkeit wieder weggemacht (Thema Hoch-Präziser-Counter) und sie nutzen am liebsten wieder den TSC. Wie das dann alles unter Linux zusammenarbeitet weiß ich nicht.

Das mit dem "auslösen" musst Du mir bitte noch erklären. Weder TSC noch ACPI-PMT können das.

Da kommt dann mein One-Shot-Scheduler zum tragen. Der liest so zu sagen, den aktuellen Wert aus und guckt dann wie lange es ist bis zum nächsten Event, ist die Zeit kürzer als die Zeit die der nächste Thread laufen darf, wird die Zeit bis der IRQ feuert auf die Zeit des Events gesetzt (ich hoffe das war jetzt nicht zu verwirrend).

Ich denke das Du da irrst. Gerade die PC-Zusammenschrauber die eher große Serien auflegen (wie DELL, HP oder Medion (soll keine Werbung sein)) bauen da manchmal eigene Dinge ein die nicht zwingenst zu irgendwelchen Standards passen. Wenn die dann ein eigenes proprietäres Windows-Programm fürs Power-Management aufspielen dann ist aus deren Sicht (die kennen NUR Windows) die Welt in Ordnung.

Mit den Problemen hat jedes alternative OS zu kämpfen und wenn jemand bereit ist, mein OS zu testen hat er genug wissen um das zu wissen und ich kann leider nicht alle Probleme der Welt mit meinem OS lösen, aber ich kann versuchen die Probleme so klein wie möglich zu halten. Denn eigentlich müsste ich mir jetzt schon ne Platte über fehlerhafte ACPI Tabellen machen, aber wozu!?

Was? TSCs synchronisieren, wie soll das denn bitte gehen? Und selbst wenn das gehen sollte, was denkst Du wie genau so eine Synchronisation per SW wäre?

Ist eigentlich ziemlich einfach und AMD hat dafür sogar nen extra Treiber. Du musst nur alle CPUs an eine Barriere zusammenholen und wenn dann alle eingetroffen sind, lässt du sie los und alle schreiben "0" in den TSC, damit sollten dann alle "Pi mal Daumen" synchronisiert sein. (alles schon seit Jahren implementiert )

Das ist eine unbewiesene Annahme. Du solltest erst einmal (bis Du diese Annahme sicher bewiesen hast) vom Gegenteil ausgehen. Nach meiner Beobachtung driften die ganz sicher auseinander, die Frage ist nur wie schnell.

Ähm, das auseinanderdriften kommt durch das Runtertakten, sprich wenn sich die CPUs unterschiedlich runtertakten. Das kann so nicht auf alten Systemen passieren. Ich wage sogar zu behaupten das sich die alten Systeme, die kein ACPI unterstützen, gar nicht runtertakten können/es einfach nicht machen. Also ich meine Multi-CPU Systeme, welche damals ausschließlich als Workstation/Server genutzt wurden und nicht für Ottonormalverbraucher.

Bist Du schon mal auf die Idee gekommen das die dafür benutzten Quarze alles andere als genau sind? Die sind in aller erste Linie billig. Mit ein bis zwei Prozent Abweichung vom Soll musst Du auf jeden Fall rechen. Und wieso eigentlich "Berechnung"? Du solltest das messen.

Das Problem bei mir ist doch das Umrechnen, denn eigentlich müsste man Gleitkommazahlen nehmen, aber da das viel zu viel Zeit kostet, nehm ich halt ne psek Auflösung und rechne dann den TSC-Wert in nsek um und genau bei dieser Umrechnung muss man halt sehen wie man rechnet, damit er wenn möglich viele Sachen, die sowieso Konstanten sind, schon als genaue Werte bekommt.
Ich habe z.B. zuerst die Frequenz des TSC berechnet um dann im Kernel die Zeit für einen Tick zu berechnen, da geht verdammt viel Genauigkeit verloren. Jetzt berechne ich gleich im Loader die Zeit für einen Tick und gebe auch die Konstanten in psek Genauigkeit an (da habe ich vorher auch rechnen lassen). Die Konstanten habe ich jetzt mit dem Windowstaschenrechner berechnet (der leider auch nur 64bit Genauigkeit hat).

Solche Aussagen erwecken, zumindest bei mir, nicht gerade Vertrauen. Du musst die TSC-Frequenz messen und nicht irgendwie ins gewünschte Ziel hinrechnen!

Das interessante an meiner Messung ist, das die Ungenauigkeit immer Konstant war, egal was für eine CPU ich hatte. Desto schneller die CPU ist, desto kleiner wird die Ungenauigkeit damit auch.

Um nochmal auf die nsek-Auflösung zu kommen. Die werde ich sowieso nicht immer erreichen können, dafür gibt es zuviel Störquellen (z.B. den SMM), aber ich will die ja auch nicht garantieren, was ich garantieren möchte ist eine Genauigkeit <1ms mit der Tendenz zur nsek-Genauigkeit!

Auch mit dem HPET hast du das Problem, das dieser immer eine gewisse Ungenauigkeit hat, durch irgendwelche Störquellen halt. Wenn du sogar noch so einen Counter mit dem HPET machen willst, kommt noch hinzu das durch das Auslesen eines "Geräts" auch wieder Zeit verbrätst. Deswegen wollen die Linuxleute ja auch wieder auf den TSC zurück. Der ist aus reiner Performancesicht am besten! Und daher auch am genauesten (wenn er denn nutzbar ist). Wie gesagt sollte der TSC bei den neueren CPUs (ab Core2Duo und vorallem ab Nehalem) wieder 100%ig benutzbar sein!

[Svenska]

die Ungenauigkeit maximal (und das ist das wichtige, im optimalen Fall wird es wesentlich genauer) 0,25ms ist, dann finde ich habe ich mein Ziel eigentlich ganz gut erreicht.

Also rechnest du in nsek, obwohl du eine (einigermaßen realistische) Wunschvorstellung von 250k davon hast.
Mal andersrum gedacht: 1 nsek =<>= 1 GHz ... du möchtest also eine Timerauflösung von (real) 4 Takten einhalten können? Wie lange braucht ein IRQ nochmal, bis du dich im Handler befindest...?

...es war schon nicht einfach Code für ne 64bit Division zu finden, bzw. fehlt mir immernoch Code (der halbwegs genau und schnell ist) für eine "64bit div 64bit = 64bit" Division.

Wieviele Takte braucht eine Division von 64-Bit-Zahlen? Wie lange auf einer 32-Bit-Plattform, die diese Division nicht in Hardware durchführen kann?

Wer garantiert Dir dass das BIOS die CPU mit Maximal-Frequenz übergibt. Es könnte doch auch sein dass das BIOS die CPU nur mit kleiner Kraft ins Rennen schickt (während eines typischen OS-Starts wartet die CPU eh meist darauf das die einzelnen OS-Teile von der HDD geliefert werden) und das hochtakten dem OS überlässt (ich hab das mal bei einem Business-PC gesehen).

Das hast du leider recht, ich gehe halt immer davon aus das die PCs so konstruiert sind das auch alternative Betriebssysteme drauf laufen und dazu zähle ich dann auch DOS und da ist es eher unwahrscheinlich das es die CPU runter/hochtaktet! Aber ich behalte das Problem mal im Hinterkopf, bzw. betrifft dies auch wieder nur neuere Systeme (auf alten sollte das wohl eher nicht passieren).

PCs sind NIE so konstruiert, dass alternative Betriebssysteme drauf laufen. NIE! Die sind billigst konstruiert, und zwar gerade so, dass Windows (in der aktuellen Version) darauf läuft. Und nichts weiter.

Nochmal als Rückgriff auf die alten PCs... das 486er Notebook taktet, bei hinreichender BIOS-Einstellung, bereits den Bootloader so stark herunter, dass der MS-DOS-Bootloader etwa 10sek (bei knapp unter 2 MHz) braucht. DOS wird auch runtergetaktet... und sehen kann ich das an einer netten LED, die mir den aktuellen Zustand anzeigt. Im Falle von Überhitzungen (herunterfahren, 3sek warten, einschalten, immernoch heiß!) hast du auch wieder hardwareseitig heruntergetaktete CPUs (Intel Core*), die sich später wieder hochtakten können, wenn sie kühler sind. Von BIOS-seitigen Stromsparmodi mal abgesehen.

Das hat was mit meiner Motivation zu tun Ich kann mich für die anderen Bereiche meistens nicht so richtig motivieren Ansonsten hast du natürlich recht, aber da es ein Hobby-OS ist, sollte ich so viel Zeit wie nötig reinstecken, so dass ich meine gesteckten Ziele erreichen kann, auch wenn ich dann bis an mein Lebensende daran arbeite!

Aha. Also willst du lieber 20 Jahre an einer niemals perfekt funktionieren könnenden hoch komplizierten Implementation für Timer arbeiten, als eine Treiberunterstützung für deine Testgeräte zu bauen... gut zu wissen.

Mit den Problemen hat jedes alternative OS zu kämpfen und wenn jemand bereit ist, mein OS zu testen hat er genug wissen um das zu wissen und ich kann leider nicht alle Probleme der Welt mit meinem OS lösen, aber ich kann versuchen die Probleme so klein wie möglich zu halten. Denn eigentlich müsste ich mir jetzt schon ne Platte über fehlerhafte ACPI Tabellen machen, aber wozu!?

Was du dir da vorstellst, schafft nichtmal Linux. Und eine seltsame, zweckfremde Hardwarenutzung soll, glaubst du, Probleme auf seltsamen Geräten vermeiden? Guck dir OS/2 an und den Grund, dass es sich auf den wenigsten Emulatoren vernünftig emulieren ließ (und lässt), dann weißt du, wie man Probleme mit der Hardware vermeidet - man macht es so, wie die anderen auch.

Was? TSCs synchronisieren, wie soll das denn bitte gehen? Und selbst wenn das gehen sollte, was denkst Du wie genau so eine Synchronisation per SW wäre?

Ist eigentlich ziemlich einfach und AMD hat dafür sogar nen extra Treiber. Du musst nur alle CPUs an eine Barriere zusammenholen und wenn dann alle eingetroffen sind, lässt du sie los und alle schreiben "0" in den TSC, damit sollten dann alle "Pi mal Daumen" synchronisiert sein. (alles schon seit Jahren implementiert )

Aja - also mein Rechner schaltet beim Standby erstmal die CPUs nacheinander ab, und CPU0 fährt das System dann endgültig in den Standby. Das asynchronisiert das Verhalten. Außerdem kannst (und solltest) du die CPUs auch getrennt runtertakten können, je nach Last, auch das asynchronisiert dir deine TSCs wieder.

Was nicht vollsynchron geschaltet ist, kann nicht als vollsynchron angenommen werden, ganz einfach. Oder: Worst-Case-Denken.

Ähm, das auseinanderdriften kommt durch das Runtertakten, sprich wenn sich die CPUs unterschiedlich runtertakten. Das kann so nicht auf alten Systemen passieren. Ich wage sogar zu behaupten das sich die alten Systeme, die kein ACPI unterstützen, gar nicht runtertakten können/es einfach nicht machen. Also ich meine Multi-CPU Systeme, welche damals ausschließlich als Workstation/Server genutzt wurden und nicht für Ottonormalverbraucher.

Drift passiert unabhängig von externen Ereignissen, das unterscheidet sie nämlich von Reaktionen. Das kann schon durch Temperaturschwankungen auftreten. Oder leicht Asynchronizität der Taktleitungen des Mainboards. Und auch CPUs vor ACPI können runtertakten. Ob sie es tun, mag ich nicht einschätzen.

Aber du nimmst gerne idealisiertes Verhalten an, über alles gesehen und ausnahmslos. So dass du dir ein Konstrukt aufbauen kannst, welches nur unter diesen Annahmen funktioniert.

Meine Empfehlung: Sorge dafür, dass es wirklich so ist, und dann geh in die Politik und repariere die Welt. Da ist auch einiges im Argen.

Das Problem bei mir ist doch das Umrechnen, denn eigentlich müsste man Gleitkommazahlen nehmen, aber da das viel zu viel Zeit kostet, nehm ich halt ne psek Auflösung und rechne dann den TSC-Wert in nsek um und genau bei dieser Umrechnung muss man halt sehen wie man rechnet, damit er wenn möglich viele Sachen, die sowieso Konstanten sind, schon als genaue Werte bekommt.

Aha, psek-Auflösung. Wunderbar.

Realitätscheck: Bei 1 THz Taktfrequenz (= 1 psek) kann der Strom sich wie weit bewegen? (Strom- bzw. Informationsübertragung geht mit Lichtgeschwindigkeit) Die Information muss diese Strecke mindestens zweimal zurücklegen, um eine Antwort produzieren zu können. Nicht einbegriffen sind die Transistorschaltungen dazwischen. Gut, du kennst die maximale Ausdehnung der CPU. Wieviele Transistoren müssen da drin sein? Bei der Taktfrequenz verbrauchen sie wieviel Energie? (Energieverbrauch tritt - abgesehen von Leckströmen - nur während des Schaltvorgangs auf, bei "1" hast du keine Spannung, bei "0" keinen Strom = P=U*I~0; darum heißt höherer Takt auch mehr Energieverbrauch je Transistor.) Gut. Wie kriegst du jetzt die Wärme aus der CPU raus?

Bei der heutigen Technologie ist das, was du dir vorstellst und als Vorteil anpreist, einfach nur unmöglich.

Um nochmal auf die nsek-Auflösung zu kommen. Die werde ich sowieso nicht immer erreichen können, dafür gibt es zuviel Störquellen (z.B. den SMM), aber ich will die ja auch nicht garantieren, was ich garantieren möchte ist eine Genauigkeit <1ms mit der Tendenz zur nsek-Genauigkeit!

Unmöglich. Zumindest auf x86. Guck dir ne fremde Architektur an, z.B. einen ATMega oder PIC, die sind klein genug, dass du ein realtime-OS da drauf kriegst.

Wie gesagt sollte der TSC bei den neueren CPUs (ab Core2Duo und vorallem ab Nehalem) wieder 100%ig benutzbar sein!

Geschätzt baust du jetzt also eine Timerstruktur, die du auf SMP-Systeme mit PPro zuschneidest (weil kein HPET/ACPI), andererseits nimmst du an, dass der TSC ab Core2 zuverlässig sein sollte. Da fehlen dann irgendwie alle CPUs (AMD K6, VIA C7, Intel PII-PIV), die zeitlich dazwischen existierten.

Aber ich glaube, noch einen Realitätscheck brauche ich nicht machen, du glaubst mir ja eh nicht.

Gruß,
Svenska

[FlashBurn]

Geschätzt baust du jetzt also eine Timerstruktur, die du auf SMP-Systeme mit PPro zuschneidest (weil kein HPET/ACPI), andererseits nimmst du an, dass der TSC ab Core2 zuverlässig sein sollte. Da fehlen dann irgendwie alle CPUs (AMD K6, VIA C7, Intel PII-PIV), die zeitlich dazwischen existierten.

Aber ich glaube, noch einen Realitätscheck brauche ich nicht machen, du glaubst mir ja eh nicht.

Ich fang mal damit an. Ich glaube dir, aber du scheinst meine Beiträge nicht richtig zu lesen!

AMD K6 kann, muss aber kein ACPI haben (also nutze ich den TSC nicht), VIA C7 hat auf jeden Fall ACPI, genau wie PII-PIV. Auf all den CPUs brauche ich den TSC nicht und nutze ihn auch gar nicht, da er halt wie du schon richtig festgestellt hast nicht wirklich funktionieren!

Also rechnest du in nsek, obwohl du eine (einigermaßen realistische) Wunschvorstellung von 250k davon hast.
Mal andersrum gedacht: 1 nsek =<>= 1 GHz ... du möchtest also eine Timerauflösung von (real) 4 Takten einhalten können? Wie lange braucht ein IRQ nochmal, bis du dich im Handler befindest...?

Wieso nagelt ihr mich immer alle auf 1nsek fest? was ist denn mit 1-1000nsek? Alles unter 1µs ist für mich nsek-Auflösung, genauso wie alles zw. 1000ns und 2000ns, also z.B. 1,554µs!

Aha. Also willst du lieber 20 Jahre an einer niemals perfekt funktionieren könnenden hoch komplizierten Implementation für Timer arbeiten, als eine Treiberunterstützung für deine Testgeräte zu bauen... gut zu wissen.

Die Smilies hast du aber gesehen, oder?

Aja - also mein Rechner schaltet beim Standby erstmal die CPUs nacheinander ab, und CPU0 fährt das System dann endgültig in den Standby. Das asynchronisiert das Verhalten. Außerdem kannst (und solltest) du die CPUs auch getrennt runtertakten können, je nach Last, auch das asynchronisiert dir deine TSCs wieder.

Also ich schicke meinen Rechner (und da gehe ich immer von Desktop aus) nie in den Standby-Modus. Beim Laptop nutze zumindest auch ich das nicht, aber egal. Der Standby-Modus wird vom OS durchgeführt (und das bekommt es auch mit und ich könnte dann den TSC neu synchonisieren) und jedes OS macht das so wie es, es für richtig hält.

Meine Empfehlung: Sorge dafür, dass es wirklich so ist, und dann geh in die Politik und repariere die Welt. Da ist auch einiges im Argen.

Wie schon beim letzten Mal, wieso schreibst du denn, wenn dir das hier alles "zu viel" wird?!

Aha, psek-Auflösung. Wunderbar.

Realitätscheck: Bei 1 THz Taktfrequenz (= 1 psek) kann der Strom sich wie weit bewegen? (Strom- bzw. Informationsübertragung geht mit Lichtgeschwindigkeit) Die Information muss diese Strecke mindestens zweimal zurücklegen, um eine Antwort produzieren zu können. Nicht einbegriffen sind die Transistorschaltungen dazwischen. Gut, du kennst die maximale Ausdehnung der CPU. Wieviele Transistoren müssen da drin sein? Bei der Taktfrequenz verbrauchen sie wieviel Energie? (Energieverbrauch tritt - abgesehen von Leckströmen - nur während des Schaltvorgangs auf, bei "1" hast du keine Spannung, bei "0" keinen Strom = P=U*I~0; darum heißt höherer Takt auch mehr Energieverbrauch je Transistor.) Gut. Wie kriegst du jetzt die Wärme aus der CPU raus?

Bei der heutigen Technologie ist das, was du dir vorstellst und als Vorteil anpreist, einfach nur unmöglich.

Wieder das selbe, was ist denn mit 1-1000psek?

Jetzt mal ein wenig Mathe. Wie willst du alles über 1GHz in nsek darstellen ohne Gleitkommazahlen zu nutzen? Dann wird dir vielleicht klar wieso ich psek nehme!

Unmöglich. Zumindest auf x86. Guck dir ne fremde Architektur an, z.B. einen ATMega oder PIC, die sind klein genug, dass du ein realtime-OS da drauf kriegst.

Das selbe wurde mal über das Fliegen, die Raumfahrt, ... gesagt

[Svenska]

x86 ist nur eingeschränkt echtzeitfähig, das liegt einerseits am Instruction Reordering, andererseits an der Systemumgebung, in die es eingebettet ist. Wenn du Latenzen im msek-Bereich einigermaßen einhalten möchtest, dann ja (soft realtime), mehr geht nicht.

Was das Festnageln betrifft... deine API stellt dir nsek zur Verfügung, sagt aber gleich an, dass "kleine" Werte unzuverlässig sind. Dann brauchst du sie ja nicht und könntest genausogut in Einheiten zu je 10 µsek rechnen. Das wäre zwar nicht so genau (und die Zahlen nicht so groß!), aber du könntest dann mit einigermaßen gegebener Sicherheit dort auch Einsen verwalten.

Mehr sag ich dazu mal jetzt nicht und ziehe mich, wie gewünscht, von hier zurück.
Und mach mich ab nächste Woche für nen Monat in den Urlaub.

Gruß,
Svenska

[FlashBurn]

Mehr sag ich dazu mal jetzt nicht und ziehe mich, wie gewünscht, von hier zurück.

So war das nicht gemeint, sondern das du dich halt aufgeregt hast. Ich finde halt, gerade ne technische Diskussion kann auch ohne sowas laufen.

Und mach mich ab nächste Woche für nen Monat in den Urlaub.

Na dann viel Spaß!

Was das Festnageln betrifft... deine API stellt dir nsek zur Verfügung, sagt aber gleich an, dass "kleine" Werte unzuverlässig sind. Dann brauchst du sie ja nicht und könntest genausogut in Einheiten zu je 10 µsek rechnen. Das wäre zwar nicht so genau (und die Zahlen nicht so groß!), aber du könntest dann mit einigermaßen gegebener Sicherheit dort auch Einsen verwalten.

Meine API macht das bisher noch nicht so richtig, bisauf das ich den Counter in nsek zurückgebe. Ansonsten nehme ich solch große Zahlen um nicht einen rießen Fehler immer mitzuschleppen und mir Gleitkommazahlen zu ersparen.

x86 ist nur eingeschränkt echtzeitfähig, das liegt einerseits am Instruction Reordering, andererseits an der Systemumgebung, in die es eingebettet ist. Wenn du Latenzen im msek-Bereich einigermaßen einhalten möchtest, dann ja (soft realtime), mehr geht nicht.

Ich bin mir gerade nicht sicher, was genau das mit der Echtzeitfähigkeit war, aber ansich wollte ich das nicht erreichen.

[Svenska]

Ich hab mich nicht aufgeregt, sorry wenn's so rüberkam. Ich halte nur das Ansinnen irgendwie für schwer umsetzbar. Und das Endergebnis für nicht erreichbar.

2^32 µs entsprechen etwa 70 Minuten, in einem Scheduler ist . Wenn du also als Zeitbasis 0.1µs nimmst, brauchst du nichtmal große Zahlen und kannst mit 32 Bit etwa 7 Minuten darstellen... besonders auf einer 32-Bit-Architektur haust du dir mit unnützen 64-Bit-Berechnungen im Scheduler nämlich dein schönes Timing weg. (Gut, Latenz ist jetzt nicht gleich Dauer, aber trotzdem.)

Interessant finde ich halt nur die Argumentation mit dem Fehler, das macht man ja schon in der Schule oft genug falsch... dass man Messergebnisse, die man "Pi * Daumen" abgeschätzt hat, dann nach der Rechnung mit sechs Nachkommastellen niederschreibt. Das meinte ich auch mit Realitätscheck. Wie genau sind deine Messungen - wie genau können sie technisch überhaupt sein - wie verlässlich sind sie überhaupt. Und da sehe ich (vermutlich nicht nur ich) schwarz.

Wenn du dein Timing möglichst genau machen willst, dann läuft das im Übrigen schon auf Echtzeitfähigkeit hinaus. Ein Multimedia-Betriebssystem muss per Definition echtzeitfähig sein, das heißt aber nicht sofortige (oder schnellstmögliche) Reaktion, sondern hinreichend schnelle Antwort.

Du zielst im Prinzip (unbewusst) auf eine hochgenaue Echtzeitfähigkeit ab.

Wann immer du Annahmen über etwas machst, dann überdenke auch immer, wann deine Annahmen nicht gelten. Da hab ich ein paar Sachen geschrieben, die für mich einige deiner Voraussetzungen verletzen und daher - vielleicht nicht grundsätzlich, aber durchaus in einigen Fällen - deine Ziele so verhindern.

Gruß,
Svenska

[FlashBurn]

2^32 µs entsprechen etwa 70 Minuten, in einem Scheduler ist . Wenn du also als Zeitbasis 0.1µs nimmst, brauchst du nichtmal große Zahlen und kannst mit 32 Bit etwa 7 Minuten darstellen... besonders auf einer 32-Bit-Architektur haust du dir mit unnützen 64-Bit-Berechnungen im Scheduler nämlich dein schönes Timing weg. (Gut, Latenz ist jetzt nicht gleich Dauer, aber trotzdem.)

Ich glaube hier reden wir immernoch aneinander vorbei Ich "brauche" beim TSC die psek, weil ich ab 1GHz Taktfrequenz, die Zeit für einen Tick des TSC nicht mehr bestimmen kann (die wäre dann immer "0").

Interessant finde ich halt nur die Argumentation mit dem Fehler, das macht man ja schon in der Schule oft genug falsch... dass man Messergebnisse, die man "Pi * Daumen" abgeschätzt hat, dann nach der Rechnung mit sechs Nachkommastellen niederschreibt. Das meinte ich auch mit Realitätscheck. Wie genau sind deine Messungen - wie genau können sie technisch überhaupt sein - wie verlässlich sind sie überhaupt. Und da sehe ich (vermutlich nicht nur ich) schwarz.

Das mit dem "Pi mal Daumen", da will ich nur sagen, das ich es nicht 100%ig genau hinbekomme (aus vielen auch hier genannten Gründen). Ich habe halt meinen Code auf einiges PCs und vielen CPUs getestet und da hat mein Code, innerhalb aktzepttabler Grenzen, soweit funktioniert (darüber habe ich auch selbst gestaunt ).
Um mal das mit den Nachkommastellen noch zu rechtfertigen. Nachdem ich mir eine Konstante per Taschenrechner ausgerechnet habe (und nicht mehr per Compiler), sind meine Messungen mit einmal wesentlich genauer geworden.
Das Problem ist z.B. das es ein Unterschied macht ob du mit 2 oder mit 2,5 rechnest, vorallem wenn du dann mit Zahlen >10000 multiplizierst.

Wenn du dein Timing möglichst genau machen willst, dann läuft das im Übrigen schon auf Echtzeitfähigkeit hinaus. Ein Multimedia-Betriebssystem muss per Definition echtzeitfähig sein, das heißt aber nicht sofortige (oder schnellstmögliche) Reaktion, sondern hinreichend schnelle Antwort.

Du zielst im Prinzip (unbewusst) auf eine hochgenaue Echtzeitfähigkeit ab.

Wie du schon geschrieben hast, dann eher unbewusst. Ich wollte genau auf eine hinreichend schnelle Antwort hinaus, aber halt wesentlich besser als z.B. Windows (irgendwo muss man ja besser sein ).

Wann immer du Annahmen über etwas machst, dann überdenke auch immer, wann deine Annahmen nicht gelten. Da hab ich ein paar Sachen geschrieben, die für mich einige deiner Voraussetzungen verletzen und daher - vielleicht nicht grundsätzlich, aber durchaus in einigen Fällen - deine Ziele so verhindern.

Problem bei, einigen von dir genannten Sachen, sehe ich darin, das es so wenig Systeme betrifft und ich die Zeit besser verwenden sollte, als mich auch noch um die Unsinnigkeiten von ein paar Systemen zu kümmern.
Zumal bei meinem Timing-System halt noch hinzukommt, dass ich damit rechne das es sich nicht weiter äußern wird (kann man unter fehlende Erfahrung verbuchen).

Ich kümmere mich im Moment um Desktopsysteme und halbwegs normale Laptops. Besonders interessant sind für mich SMP-Systeme, da ich vorallem gespant bin was man aus den älteren (<PII) noch so rausholen kann.

[erik.vikinger]

Hallo,


Sorry für mein langes Delay, ich hab zur Zeit ne Menge privater Probleme.

Bevor, vorallem ihr, mich auf die Unzulänglichkeiten mit meinem System aufmerksam gemacht habt

Dafür sind wir ja da.

wollte ich schon noch irgendwie ne nsek Auflösung erreichen, bzw. ich erreiche sie bestimmt auch auf vielen Systemen (wenn der ACPI-PMT genutzt wird)

Ich denke das Du selbst auf den aktuellsten PCs nicht genauer als etwa in den einstelligen Mikrosekundenbereich kommst. Und mit dem ACPI-PMT schon gar nicht, der hat doch nur 3.58 MHz.

Für Dich vielleicht, aber die CPU hat am wenigsten Arbeit wenn sie direkt mit den Timer-Ticks umgehen darf (da muss dann gar nichts gerechnet werden) und die libc in den User-Programmen die Wünsche per GetTicksPerSecond passend umrechnet.

Das ist dem geschuldet das ich mehrere Zeitquellen nutze und da ist es am einfachsten wenn ich in nsek umrechne.
[....]
Dann müsste ich aber 128bit Zahlen benutzen und es war schon nicht einfach Code für ne 64bit Division zu finden, bzw. fehlt mir immernoch Code (der halbwegs genau und schnell ist) für eine "64bit div 64bit = 64bit" Division. Oder was meintest du?

Genau das meinte ich mit unnötigem Aufwand. Wenn Du innerhalb des Kernels gar nichts umrechnest sondern immer direkt mit Ticks arbeitest sparst Du Dir erheblichen (Rechen-)Aufwand (so ein DIV-Befehl kann auf verschiedene Arten Exceptions auslösen und die könnten innerhalb Deines Kernels unangenehm sein und eventuell zu einem Tripple-Fault führen). Und wie man eine Division mit überbreiten Zahlen realisiert ist IMHO Aufgabe des Compilers (der Deine libc compiliert).

betrifft dies auch wieder nur neuere Systeme (auf alten sollte das wohl eher nicht passieren)

Das, mit der PC-Serie wo die CPU mit gedrosselter Kraft vom BIOS ans OS übergeben wurde, war vor etwa 8 Jahren. Das war ein Pentium 4 System und die haben absichtlich ein möglichst schwaches Kühlungssystem verbaut (an jedem PC 5 Euronen gespart macht sich bei >= fünfstelligen Stückzahlen durchaus bemerkbar) und eben fürs Hochfahren die CPU gedrosselt bevor dann bei laufendem OS ein extra Programm den CPU-Takt je nach Last und Temperatur geregelt hat.

Hä, bitte genauer erklären. Willst du neben einem periodischen PIT-Timer noch parallel einen One-Shot-PIT-Timer starten?

Nope! Ich hatte doch erklärt das wenn die Zeit bis zu einem Event (jetzt mal als Bsp) kleiner ist als das Intervall des periodischen Timers, das dann das Event an den Scheduler weitergereicht wird. Dieser löst das dann im Endeffekt aus (weckt als z.B. einen Thread auf). Der Scheduler wird halt entweder vom PIT oder vom APIC befeuert (je nach dem was auf dem PC zur Verfügung steht).

Wenn der Scheduler auch nur mit dem selben PIT arbeitet dann hast Du doch keinen Genauigkeitsgewinn. Den könntest Du theoretisch haben wenn Du zusätzlich zum periodischen IRQ einen weiteren PIT-Zähler (der PIT hat doch 3 Zähler oder irre ich da) als One-Shot-Timer aufziehst. Bei Verwendung des Local-APIC-Timers hast Du natürlich auch die theoretische Möglichkeit auf einen Genauigkeitsgewinn. Diesen Gewinn erkaufst Du Dir aber in jedem Fall mit einiges an Mathematik im Kernel.

... auch wenn ich dann bis an mein Lebensende daran arbeite!

Mein Projekt ist auch Hobby aber bis an mein Lebensende möchte ich daran wirklich nicht arbeiten. In spätestens 5 bis 7 Jahren möchte ich auf meinem komplett selbst entwickeltem Computer das absolute Lieblings-Spiel meiner Jugend spielen können. (ich verzichte hier absichtlich auf Smilies)

aber die Linuxleute sind nicht so sehr von dem HPET begeistert, wimre wird die Genauigkeit durch die Langsamkeit wieder weggemacht (Thema Hoch-Präziser-Counter) und sie nutzen am liebsten wieder den TSC

Wo ist der HPET langsam? Der benutzt immerhin Memory-Mapped-I/O und sollte sich daher sehr einfach und effizient benutzen lassen. Für (Performance-)Messungen sehr kurzer Zeitspannen ist der HPET auch nie gedacht gewesen.

Du musst nur alle CPUs an eine Barriere zusammenholen und wenn dann alle eingetroffen sind, lässt du sie los und alle schreiben "0" in den TSC, damit sollten dann alle "Pi mal Daumen" synchronisiert sein.

Das dürfte etwa 100 bis 1000 Takte (bei richtig vielen CPUs und entsprechendem Cache-Kohärenz-Protokoll-Aufwand wohl noch mehr) Differenz ergeben. Naja, wenn Du meinst das sich dieser Aufwand lohnt dann nur zu.
Ich wusste gar nicht das die TSCs beschreibbar sind, wozu auch, die driften doch eh wieder auseinander (spätestens wenn das Powermanagement die unterschiedlichen CPUs in unterschiedliche Power-Modi schickt).

was ich garantieren möchte ist eine Genauigkeit <1ms mit der Tendenz zur nsek-Genauigkeit!

Das sind 6 (sechs) Zehnerpotenzen, das ist wirklich ein sehr ehrgeiziges Ziel. Respekt!

Auch mit dem HPET hast du das Problem, das dieser immer eine gewisse Ungenauigkeit hat

Das ist der Jitter, der ist tatsächlich kaum zu vermeiden, aber richtige Ungenauigkeit hat man beim HPET nicht (beim PIT im periodischen Modus ebenfalls nicht).

Guck dir OS/2 an und den Grund, dass es sich auf den wenigsten Emulatoren vernünftig emulieren ließ (und lässt)

Könntest Du Bitte diesen Grund etwas näher erläutern.

man macht es so, wie die anderen auch

Also das ist definitiv der schlechteste Vorschlag den man geben kann! Wir sind doch alle hier weil wir eben nicht alles so machen wollen wie alle anderen auch. Wir wollen neue Wege gehen!

z.B. einen ATMega oder PIC, die sind klein genug, dass du ein realtime-OS da drauf kriegst

Das liegt IMHO nicht daran das die klein sind sondern daran das die sehr deterministisch sind. Bei denen kannst Du u.a. für einen bestimmten Code-Abschnitt ganz genau sagen wie lange der braucht bei x86 geht das schon seit über 20 Jahren nicht mehr.

Also ich schicke meinen Rechner (und da gehe ich immer von Desktop aus) nie in den Standby-Modus.

Energie kostet Geld, wenn Dein OS damit nicht verantwortungsbewusst umgehen kann hat es grundsätzlich keine echte Chance.

Jetzt mal ein wenig Mathe. Wie willst du alles über 1GHz in nsek darstellen ohne Gleitkommazahlen zu nutzen? Dann wird dir vielleicht klar wieso ich psek nehme!

Selbst mit Gleitkommazahlen kannst Du nicht jede CPU-Takt-Frequenz exakt darstellen aber wenn Du Dich auf Pikosekunden in Integer festlegst hast Du für die heutigen CPUs nur maximal 8 signifikante Bits und das ist schon sehr knapp bemessen, dann lieber gleich Femtosekunden. Außerdem haben die Gleitkommazahlen einen zusätzlichen Vorteil, man kann recht schnell mit ihnen rechnen (heutige FPUs sind ziemlich fix und besser als ne händische "64Bit / 64Bit = 64Bit" Division auf ner 32Bit-CPU ist die FPU alle mal).

aber halt wesentlich besser als z.B. Windows (irgendwo muss man ja besser sein )

Dann nimm ne andere Plattform. Windows (zumindest in aktueller Version) dürfte x86 schon recht gut ausreizen, die haben ein ganzes Team an Vollzeit-Programmierern nur allein für den Kernel. Wenn Du dieses Ziel wirklich erreichen willst dann überlege Dir mal ob Du nicht z.B. bei mir mitmachen möchtest. Zumindest "genaueres Timing als Windows" dürfte ein einigermaßen realistisches Ziel in meinem Projekt sein. Und kreative Leute die nicht immer nur in aus getrampelten Bahnen denken dürften in vielen Projekten sehr willkommen sein.


Grüße
Erik

[FlashBurn]

Sorry für mein langes Delay, ich hab zur Zeit ne Menge privater Probleme.

Kein Problem, bin eh im "Urlaub" und private Probleme gehen eh vor!

Ich denke das Du selbst auf den aktuellsten PCs nicht genauer als etwa in den einstelligen Mikrosekundenbereich kommst. Und mit dem ACPI-PMT schon gar nicht, der hat doch nur 3.58 MHz.

Naja, wie gesagt ich meine damit, das ich z.B. wenn ein Event in 1µs gefeuert werden soll, das du das dann halt nicht nach 2µs sondern so nahe wie möglich an 1µs bekommst. Mir geht es im Endeffekt um die "Nachkommastellen". Das ich also schon nach 1,15µs (was dann für mich nsek-Auflösung wäre) und nicht erst nach 2µs das Event bekomme. Das du das auf älteren Systemen nicht hinbekommst ist mir klar, alleine schon weil die CPUs ja doch ne Weile brauchen um die Instruktionen abzuarbeiten.

Um es nochmal ganz genau zu sagen, mir gefällt der Gedanke nicht, das du ein Event nach 15ms haben möchtest, dieses aber frühestens nach 20ms bis zu 40ms später bekommst (wenn du nen periodischen Timer von 20ms nutzt).
Wenn mein worst-case dann mal 0,25ms daneben liegt, denke ich habe ich mein Ziel mehr oder weniger erreicht. Denn der average-case wird wesentlich genauer sein!

Ich denke das Du selbst auf den aktuellsten PCs nicht genauer als etwa in den einstelligen Mikrosekundenbereich kommst. Und mit dem ACPI-PMT schon gar nicht, der hat doch nur 3.58 MHz.

Ich glaube ich habe irgendwo µs und ms durcheinander gebracht, wenn ich auf nem PII mit nem ACPI-PMT µs-Auflösung bekomme, dann ist das doch schon verdammt gut und Welten besser als Windows

Genau das meinte ich mit unnötigem Aufwand. Wenn Du innerhalb des Kernels gar nichts umrechnest sondern immer direkt mit Ticks arbeitest sparst Du Dir erheblichen (Rechen-)Aufwand (so ein DIV-Befehl kann auf verschiedene Arten Exceptions auslösen und die könnten innerhalb Deines Kernels unangenehm sein und eventuell zu einem Tripple-Fault führen). Und wie man eine Division mit überbreiten Zahlen realisiert ist IMHO Aufgabe des Compilers (der Deine libc compiliert).

Also nochmal. Ich nutze mehrere Zeitquellen mit unterschiedlichen Ticks, also muss ich so oder so irgendwo umrechnen und um mir und dem Programmier/in das Leben etwas leichter zu machen, sage ich, dass ich gleich nsek zurückgebe.
Das mit den Exceptions dürfte nicht passieren (mir fällt da spontan eh nur die 0-Teiler-Exception ein).
Was die Division großer Zahlen betrifft, setzt du vorraus das ich ne libc habe (nutze ich nicht für meinen Loader und auch nicht für meinen Kernel). Ich habe bisher alles mehr oder weniger alleine geschrieben. Das ich nachher eine Libc für das Userland portieren werde ist klar. Obwohl ich mit der Lösung nicht so richtig glücklich bin und wahrscheinlich eher alles OS-Unabhängige "portieren" werde und den Rest mehr oder weniger neuschreiben werde.
Denn was nützt dir ein tolles OS mit neuen Ideen, wenn du dann bei der Libc schon ne Art Emulierungsschich hast.

Das, mit der PC-Serie wo die CPU mit gedrosselter Kraft vom BIOS ans OS übergeben wurde, war vor etwa 8 Jahren. Das war ein Pentium 4 System und die haben absichtlich ein möglichst schwaches Kühlungssystem verbaut (an jedem PC 5 Euronen gespart macht sich bei >= fünfstelligen Stückzahlen durchaus bemerkbar) und eben fürs Hochfahren die CPU gedrosselt bevor dann bei laufendem OS ein extra Programm den CPU-Takt je nach Last und Temperatur geregelt hat.

Also für mich eh nicht interessant, da ich auf diesen PCs keinen TSC nutze!

Wenn der Scheduler auch nur mit dem selben PIT arbeitet dann hast Du doch keinen Genauigkeitsgewinn. Den könntest Du theoretisch haben wenn Du zusätzlich zum periodischen IRQ einen weiteren PIT-Zähler (der PIT hat doch 3 Zähler oder irre ich da) als One-Shot-Timer aufziehst. Bei Verwendung des Local-APIC-Timers hast Du natürlich auch die theoretische Möglichkeit auf einen Genauigkeitsgewinn. Diesen Gewinn erkaufst Du Dir aber in jedem Fall mit einiges an Mathematik im Kernel.

Ihr versteht meine Kombinationen leider immernoch nicht

Also, entweder man hat nen alten PC ohne APIC, dann wird die RTC als periodische Quelle und der PIT für den One-Shot-Scheduler (eher sehr ungenau) genommen.
Hast du nen PC mit APIC (was SMP-Systeme mit einschließt) dann wird der PIT als periodische Quelle und der APIC für den One-Shot-Scheduler genommen.
Wenn ich dann mal soweit bin, dann wird der HPET als periodische Quelle und der APIC für den One-Shot-Scheduler genommen (wo ich dann auch die Events nicht mehr an den Scheduler weiterreichen brauche).

Wo ist der HPET langsam? Der benutzt immerhin Memory-Mapped-I/O und sollte sich daher sehr einfach und effizient benutzen lassen. Für (Performance-)Messungen sehr kurzer Zeitspannen ist der HPET auch nie gedacht gewesen.

Ich kann dir leider nicht sagen, worum es bei dem Code ging, den ich da mal gesehen hatte. Ich vermute mal um nen Counter (hochpräzise) und wenn du da jedesmal den HPET auslesen musst, dann ist der TSC einfach schneller und dein Counter somit genauer!

Mein Projekt ist auch Hobby aber bis an mein Lebensende möchte ich daran wirklich nicht arbeiten. In spätestens 5 bis 7 Jahren möchte ich auf meinem komplett selbst entwickeltem Computer das absolute Lieblings-Spiel meiner Jugend spielen können. (ich verzichte hier absichtlich auf Smilies)

Sorry, aber wer sich nicht im Klaren ist, dass ein OS nie fertig ist, der hat etwas nicht verstanden

Ich weiß jetzt schon, das ich entweder mein OS nach 64bit portiere oder aber ein neues schreibe und meine (guten) Ideen und meine Erfahrungen mitnehme.

Das dürfte etwa 100 bis 1000 Takte (bei richtig vielen CPUs und entsprechendem Cache-Kohärenz-Protokoll-Aufwand wohl noch mehr) Differenz ergeben. Naja, wenn Du meinst das sich dieser Aufwand lohnt dann nur zu.

Der Punkt geht an dich

Problem ist hier nur, dass ich das im Kernel machen muss. Wenn ich es mir gerade so recht überlege, ist das ganze aber eigentlich nicht notwendig, weil ...

Wenn ich ein altes SMP-System ohne ACPI habe, gehe ich jetzt mal frech davon aus, das die TSCs (von irgendwelchen Stromsparmaßnahmen mal abgesehen, da ich eh nicht glaube das es sowas auf solchen System gab und ich noch nichts gefunden habe, das der TSC dort Probleme macht) synchron sind und funktionieren.
Auf nem neuem System wo ICH den TSC dann wieder nutze, sind die eh synchron und funktionieren (das wird ja dort "garantiert", nach dem sich MS und "Linux" darüber beschwert hatten).
Also bräuchte ich diese Synchronisation eigentlich nicht mehr und könnte den Code auskommentieren.

Ich wusste gar nicht das die TSCs beschreibbar sind, wozu auch, die driften doch eh wieder auseinander (spätestens wenn das Powermanagement die unterschiedlichen CPUs in unterschiedliche Power-Modi schickt).

Gegenfrage, wenn die nicht schreibbar wären, wie soll die AMD dann per Treiber synchronisieren können?
Und wie oben schon geschrieben, passiert das ganz auseinanderdriften auf neueren CPUs halt nicht mehr! Ich gehe jetzt auch davon aus, das es auf Multi-Sockel-Systemen auf diesen CPUs auch alles funktioniert.

Energie kostet Geld, wenn Dein OS damit nicht verantwortungsbewusst umgehen kann hat es grundsätzlich keine echte Chance.

Ich gehe hier jetzt mal von einer privaten Nutzung aus und da macht der Standbybetrieb bei einem Desktop-Rechner für mich einfach keinen Sinn! Ich mach meinen Rechner dann einfach aus!

Zumal ich ja z.B. aus Energietechnischer Sicht keine periodische Zeitquelle mit einem Intervall von 1ms nutzen möchte

Selbst mit Gleitkommazahlen kannst Du nicht jede CPU-Takt-Frequenz exakt darstellen aber wenn Du Dich auf Pikosekunden in Integer festlegst hast Du für die heutigen CPUs nur maximal 8 signifikante Bits und das ist schon sehr knapp bemessen, dann lieber gleich Femtosekunden. Wink  Außerdem haben die Gleitkommazahlen einen zusätzlichen Vorteil, man kann recht schnell mit ihnen rechnen (heutige FPUs sind ziemlich fix und besser als ne händische "64Bit / 64Bit = 64Bit" Division auf ner 32Bit-CPU ist die FPU alle mal).

Diese Division findet einmal statt und zwar in meinem Bootloader. Selbst wenn die noch so langsam ist, dürfte das wohl kaum auffallen!
Es gibt da irgendwo so ne Regel das man keine FPU im Kernel nutzt und das halte ich genauso! Macht mir nur die Arbeit schwerer und ich komme bisher ohne ganz gut klar!

Dann nimm ne andere Plattform. Windows (zumindest in aktueller Version) dürfte x86 schon recht gut ausreizen, die haben ein ganzes Team an Vollzeit-Programmierern nur allein für den Kernel. Wenn Du dieses Ziel wirklich erreichen willst dann überlege Dir mal ob Du nicht z.B. bei mir mitmachen möchtest. Wink Zumindest "genaueres Timing als Windows" dürfte ein einigermaßen realistisches Ziel in meinem Projekt sein. Und kreative Leute die nicht immer nur in aus getrampelten Bahnen denken dürften in vielen Projekten sehr willkommen sein.

Kommt drauf an welche Windows-Version du meinst Ich weiß gar nicht ob die inzwischen auch nen One-Shot-Scheduler haben.

Ich müsste mal nachgucken, wie lange so eine Division braucht, aber so lange sollte das nun auch wieder nicht dauern!

[FlashBurn]

Mir ist gerade eingefallen warum der TSC an sich die beste Lösung fürs Timing (in Form eines Counters wäre und damit auch warum es von Linux bevorzugt wird) ist.

Leider ist es mit dem HPET nicht möglich ihn für einen Counter zu nutzen, den man auch im Userland, OHNE in den Kernel gehen zu müssen, nutzen kann.

Denn den TSC kann man ja auch im Userland auslesen (so fern es das OS zulässt) und damit ist der TSC nochmal schneller (was er ja ohnehin ist, da direkt in der CPU und nicht IO-Gerät), da nicht in den Kernel gegangen werden muss.

Ich habe mir nämlich gerade ne Rübe gemacht, wie man solch einen Counter auch direkt im Userland implementieren könnte und habe noch keine all-in-one Lösung gefunden.

Der Grund für genaues Timing wäre z.B. ein Emulator. Ich habe mich zwar noch nicht weiter mit der Programmierung beschäftigt (und anscheinend funktioniert es auch ohne genaues Timing), aber es würde die Sache bestimmt einfacher machen, wenn man ein Gerät (z.B. eine CPU) in der genauen Geschwindigkeit (also Frequenz) timen kann.

[erik.vikinger]

Hallo,

Kein Problem, bin eh im "Urlaub" und private Probleme gehen eh vor!

Du kennst meine momentanen Probleme nicht, sei froh.

Naja, wie gesagt ich meine damit, das ich z.B. wenn ein Event in 1µs gefeuert werden soll, das du das dann halt nicht nach 2µs sondern so nahe wie möglich an 1µs bekommst.

Das einzigste Werkzeug was ich dazu generisch in der Lage sehe ist der HPET. Der Local-APIC-Timer gibt den Event nur auf der CPU wo er läuft und ist somit zwar nutzbar aber nicht für jeden Zweck und der TSC (ebenso wie der ACPI-PMT) gibt gar keine Events ist also nur für Messung und kurzes aktives Warten (z.B. in nsleep) geeignet. Für Messungen ist der TSC natürlich perfekt weil man ihn schnell abfragen kann und weil er (Aufgrund der hohen Zählgeschwindigkeit) eine feine zeitliche Auflösung bietet, dafür bleibt das Problem das alles durcheinander gerät wenn das OS das User-Programm zwischendurch auf ne andere CPU schedult. Fürs Timing, also z.B. das Auslösen eines Event in möglichst exakt 30ms oder auch 2µs, ist der TSC eben gar nicht geeignet (er kann schlicht keine Events auslösen). Und wenn Du bei einem periodischen RTC/PIT-IRQ quasi die Nachkommastellen willst dann nimm lieber den ACPI-PMT oder den HPET, die laufen mit konstanter und verlässlicher Geschwindigkeit.

Wenn mein worst-case dann mal 0,25ms daneben liegt, denke ich habe ich mein Ziel mehr oder weniger erreicht. Denn der average-case wird wesentlich genauer sein!

Der worst-case wird deutlich mehr daneben liegen, das liegt in der Natur eines General-Purpose-OS. Auch der average-case wird kaum in den einstelligen Mikrosekundenbereich (wohl noch nicht mal in den zweistelligen) vordringen, das ist eher der selten erreichte best-case.

Ich glaube ich habe irgendwo µs und ms durcheinander gebracht

Das machst Du meiner persönlichen Meinung nach (und wohl auch nach Svenskas Meinung) schon seit ner ganzen Weile.

wenn ich auf nem PII mit nem ACPI-PMT µs-Auflösung bekomme, dann ist das doch schon verdammt gut

Das ist nicht gut sondern unmöglich. Mit dem ACPI-PMT kannst Du höchstens prüfen ob ein sleep(6ms) noch vor dem nächsten RTC/PIT-IRQ fertig ist (damit bereits dort der entsprechende Thread wieder aufgeweckt werden kann) oder erst mit dem übernächsten IRQ sicher abgelaufen ist. Damit wirst Du höchstens zufällig mal eine Mikrosekundengenauigkeit erreichen wenn eben das sleep zufällig genau 6ms (+ eine winzige Reserve für Latenzen) vor dem nächsten IRQ aufgerufen wurde.

Ich nutze mehrere Zeitquellen mit unterschiedlichen Ticks

Also nochmal, genau darin sehen wir das Problem. Eben weil diese unterschiedlichen Zeitquellen kein exakt bekanntes Verhältnis zu einander haben (und dieses Verhältnis wohl auch Schwankungen und Drifts unterliegt) wirst Du viel Arbeit für (fast) nichts investieren müssen damit das ganze Konstrukt zumindest nicht schlechter läuft als die simple Lösung. Den Genauigkeitsvorteil den Du Dir davon versprichst sehe ich bis jetzt nur in der Theorie aber ich kann mir nicht vorstellen wie Du den in die Praxis bringen willst.

also muss ich so oder so irgendwo umrechnen

Ja, Du wirst an so vielen Stellen (verlustbehaftet) umrechnen müssen das am Ende von Deiner Genauigkeit nicht viel übrig bleibt.

Das mit den Exceptions dürfte nicht passieren (mir fällt da spontan eh nur die 0-Teiler-Exception ein).

DIV wirft auch ne Exception wenn das Ergebnis zu groß für ein Register ist, also z.B. bei 0x00000033_33333333 / 0x00000002 wäre das Ergebnis größer als 32Bit.

Was die Division großer Zahlen betrifft, setzt du vorraus das ich ne libc habe (nutze ich nicht für meinen Loader und auch nicht für meinen Kernel).

Nein, ich wollte damit sagen das die User-Mode-Programme ihre Zeitbedürfnisse in einer ihnen genehmen Einheit (meinetwegen auch Femtosekunden) verwalten sollen und die libc (oder ne andere lib) das dann passend in Ticks für den Kernel umrechnen muss (um das dann den Syscalls als Parameter mitzugeben) damit im Kernel überhaupt nichts gerechnet werden muss. So will ich das zumindest in meinem OS machen.

Ihr versteht meine Kombinationen leider immernoch nicht

Wir verstehen nicht wie Du glaubst trotz der ganzen Probleme, die die unterschiedlichen Komponenten beim Zusammenspiel bringen, noch einen Genauigkeitsgewinn erzielen zu können.

Also, entweder man hat nen alten PC ohne APIC, dann wird die RTC als periodische Quelle und der PIT für den One-Shot-Scheduler (eher sehr ungenau) genommen.

Damit wäre der PIT aber nur für relative Dinge (wie z.B. ein sleep) geeignet. Wenn Du z.B. einem Video-Player-Programm einen 24Hz Event geben möchtest damit ein Film mit 259200 Bildern bei 24fps auch ganz genau 3 Stunden läuft dann nützt Dir der PIT im One-Shot-Mode nicht viel. Für die Verwaltung der Zeitscheiben (auf einem Single-CPU-System), was ja auch relative Zeiten sind, taugt der One-Shot-PIT natürlich.

Hast du nen PC mit APIC (was SMP-Systeme mit einschließt) dann wird der PIT als periodische Quelle und der APIC für den One-Shot-Scheduler genommen.

Das Problem, zumindest bei SMP, ist IMHO das es mehrere Local-APICs gibt. Wie bestimmst Du den an welche CPU ein bestimmtes Event geht? Zur Verwaltung der Zeitscheiben braucht man mehrere CPU-Lokale Timer (genau dafür wurden die Local-APIC-Timer ja gedacht), da ja jeder laufende Thread seine eigene Zeitscheibe hat, aber fürs globale/generische Timing betrachte ich die er als ungeeignet.

Wenn ich dann mal soweit bin, dann wird der HPET als periodische Quelle und der APIC für den One-Shot-Scheduler genommen (wo ich dann auch die Events nicht mehr an den Scheduler weiterreichen brauche).

Der HPET ist keine periodische Quelle. Das ist ein garantiert monotoner und nicht beeinflussbarer Counter der an beliebigen vorherbestimmbaren Zeitpunkten IRQs senden kann. Natürlich kann man diese Zeitpunkte auch in ein festes Raster legen, was z.B. bei dem Beispiel mit dem Video-Player-Programm nötig wäre. Man kann aber den einen HPET für viele verschiedene Events benutzen, man muss bei einem Event (also im IRQ-Handler) immer nur den absoluten Zeitpunkt des nächsten Events in den HPET-Comparator laden (deswegen die sortierte Liste). Die Zeitscheiben für die laufenden Threads würde ich natürlich trotzdem mit den Local-APIC-Timern managen da ja der Event auf genau der CPU kommen soll wo die Zeitscheibe abläuft. Dazu ist der HPET nicht fähig, dessen IRQ wird an irgendeine CPU geleitet (eventuell auch immer an die selbe).

Trotzdem wüste ich gerne was Du mit "One-Shot-Scheduler" meinst.

Gegenfrage, wenn die nicht schreibbar wären, wie soll die AMD dann per Treiber synchronisieren können?

Ich wusste auch nicht das AMD die per SW synchronisiert. Auf so eine unsinnige Idee wäre ich auch nie gekommen, das kann gar nicht präzise funktionieren!

Und wie oben schon geschrieben, passiert das ganz auseinanderdriften auf neueren CPUs halt nicht mehr!

Wieso sollten die TSCs nicht mehr auseinander driften, gerade auf den modernen CPUs können alle CPU-Kerne ihre Taktfrequenz unabhängig und dynamisch ändern (bei den aktuellen Core i? eventuell sogar ganz ohne aktives zutun von OS oder BIOS). Und selbst bei den aller ersten Pentium-Pro Systemen war es nicht verboten CPUs mit unterschiedlichem Core-Takt auf ein Board zu stecken solange der Front-Side-BUS-Takt identisch war. Wie will man sowas synchronisieren? Von den ganzen physikalische Phänomenen wie schwankenden Temperaturen usw. mal ganz abgesehen. Stell Dir mal ein Dual-Sockel Core i7 System vor bei dem einer der beiden CPU-Lüfter leicht verschmutzt ist (in einem privaten PC sicher nicht auszuschließen) und der Turbo-Boost-Controller der betreffenden CPU alle ihre Kerne nicht ganz bis an die maximale Frequenz ran lässt (weil das CPU-Die am Temperatur-Limit ist). Dann hast Du 4 CPU-Kerne mit z.B. 2,6GHz und 4 mit 2,0GHz. Wie will man sowas synchronisieren?
Das synchronisieren der TSCs ist völliger Blödsinn, um die als Stoppuhr zu benutzen braucht man sie nicht zu synchronisieren.

Leider ist es mit dem HPET nicht möglich ihn für einen Counter zu nutzen, den man auch im Userland, OHNE in den Kernel gehen zu müssen, nutzen kann. ....

Das ist richtig. Der HPET ist aber nie als (hochpräzise) Stoppuhr gedacht gewesen, so wie der TSC nie fürs (generische) Timing gedacht wurde.


Grüße
Erik