Thema: Konzept für periodische Events

[FlashBurn]

Ein abgelaufener Timer kann prinzipiell maximal nur 1 Kind haben und ist damit garantiert immer mit wenig Aufwand zu löschen.

Da kann ich nur sagen, du solltest dich noch ein wenig mit solch ausbalanzierten Bäumen beschäftigen Denn es ist in dem Sinn egal wieviel Kinder ein Knoten hat, ob der Baum danach ausbalanziert werden muss, dass ist die entscheidene Frage. Ich würde dir ja den AVL-Baum als einstiegs Lektüre empfehlen, da ich ihn einfacher zu verstehen finde.

Gerade das wird mit dem PIT-One-Shot-Modus nicht klappen weil ja der PIT immer wieder neu zeitaufwändig konfiguriert werden muss. Nach genau 360000 Bildern wird mit der PIT-One-Shot-Methode sicher etwas mehr Zeit als ganz exakt 4 Stunden vergangen sein. Wenn Du das anders siehst dann erkläre mir das bitte mal genauer.

Den Vorteil den ich beim PIT und periodisch sehe ist, dass du genau sagen kannst wie der Jitter aussieht. Das ist bei der One-Shot Methode nicht möglich.
Ich denke mal das du immernoch mit deinem absoluten Zeiten rechnest Wenn ich aber relative Zeiten nehme, dann ist der Jitter, der vor dem aktuellen Zeitpunkt aufgetretten ist, egal! So wird es ihn zwar geben, aber er summiert sich nicht auf.
Was mir aber gerade aufgefallen ist, das ich mir mit den 40ms selbst ein Ei gelegt habe Denn dieser Timer wird immer in der Sleep-Queue der CPU bleiben (und dummer weise sogar immer auf der selben CPU, was aber nicht bedeutet das der Thread der das Event abfragt immer auf der selben CPU läuft).

Bei einer PIT-Periode von 15ms dürfte der Jitter für ein 25Hz-Timer zwischen 0ms und 10ms liegen. Wie Du da auf 20ms kommst verstehe ich nicht.

Gut, auch da fällt mir gerade auf, das der Jitter den ich meine nur beim 1. Mal auftritt. Denn best-case wäre, wenn der Thread dieses Event kurz bevor der PIT feuert erstellt, aber der worst-case wäre, wenn der Thread kurz nach dem der PIT gefeuert hat, das Event erstellt. Ich hoffe du kannst nachvollziehen wie ich das meine. Das Problem ist die "lange" Periode von 15ms. Du kannst ja schlecht wissen ob das Event am Anfang oder am Ende der Periode erstellt wird, aber der Wert des Counters, der absoluten Zeit, ist der selbe!

Schon klar, ich verstehe das Du Präzision willst, geht mir genau so. Aber Du solltest erst mal klar definieren was Du unter Präzision verstehst. Willst Du das ein Film mit 216048 Frames bei 24fps genau 2:30:02 geht oder was möchtest Du?

Ich muss dir ganz ehrlich sagen, das ich wo ich das System "entwickelt" habe, mir gar keinen Kopf über periodische Sachen gemacht habe, sondern mir war wichtig das wenn ich nen sleep(10) aufrufe, das so genau wie möglich sein sollte. Das will ich auch immernoch, aber ich muss halt mit den Nachteilen dieses Systems für periodische Sachen leben. Obwohl ich ja finde das durch mein 2-geteiltes System der Jitter ganz gut abgefangen wird.

Echt? Ich bin geschockt! Das hätte ich im 20 Jahrhundert der x86-Plattform nicht mehr zugetraut das es noch HW gibt die so lange Bedenkzeit nur für sich selbst braucht. Die APICs haben doch keine nennenswerten externen Abhängigkeiten, wofür benötigen die mal einfach so Zeit? Kannst Du nicht alle APs gleichzeitig aktivieren?

Problem ist, du sollst dem APIC Zeit geben, so dass er die Nachricht verschicken und die anderen CPUs diese auch empfangen können. Ich könnte alle APs gleichzeitig aktivieren (was ich in einer alten Version auch gemacht habe), aber das kann zu Problemen führen (auch wenn das sehr unwahrscheinlich ist). In dem Standard von ACPI und MPS ist vorgesehen, dass ne CPU auch als defekt vom BIOS markiert werden kann und diese CPU willst du nicht starten! So sage ich, lieber ein wenig mehr Zeit beim Starten der APs verbraten und dafür alle Eventualitäten aus dem Weg räumen!
Das Problem sind hier im Endeffekt halt auch wieder die alten Systeme. Wenn ich mich recht erinnere, dann wurde das busy-Flag im x2Apix-Mode entfernt, du brauchst dir da also keine Gedanken mehr machen, ob die Message verschickt wurde oder nicht (und brauchst somit auch nicht mehr warten).
Das "lustige" ist, man sollte lieber zu lange Warten als zu kurz. Denn ich hatte schon den Fall, das mein OS auf nem neuem Core2Duo PC alle Kerne starten konnte, aber auf nem alten Dual P3 System konnte mit einmal die 2. CPU nicht mehr gestartet werden. Als ich dann die Zeit zum Warten verlängert hatte, lief wieder alles.

Das klingt für mich viel aufwändiger als es IMHO eigentlich nötig wäre. Du schreibst in den Local-APIC-Timer ja 2 verschieden Dinge rein, das finde ich persönlich verwirrend und möglicherweise etwas fehleranfällig. Was ist wenn kein APIC vorhanden ist?

Wieso und wo schreibe ich 2 Dinge in den APIC? Jeder Timer der nen Counter hat kann so benutzt werden (also auch der PIT).

Auch das erscheint mir unnötig kompliziert. Außerdem gibt es dann eine 2 Klassengesellschaft bei den Timern: solche die kürzer sind als diese 55,4ms und recht genau laufen und jene die länger als 55,4ms laufen und auf ein 55,4ms-Raster gedrückt werden (also wohl mindestens 110,8ms). Wie willst Du eigentlich den Startzeitpunkt eines Timers ermitteln (also den Moment wo z.B. ein sleep(20) aufgerufen wurde) um zu ermitteln ob er noch vor dem nächsten 55,4ms-Tick abläuft oder erst danach. Wenn Du nur diese 55,4ms-Ticks hast dann hast Du auch keine genauere absolute Zeitbasis, kannst also den Timer-Start auch nur auf 55,4ms genau bestimmen. Oder hab ich was übersehen? Oder war das die Idee mit dem auslesen des aktuellen PIT-Zählerwertes und diesen quasi als zusätzliche Genauigkeit (das meinte ich mit dem Nachkomma-Bits) zu benutzen?

Du hast mich leider immernoch nicht richtig verstanden

Also zum ermitteln des genau Zeitpunktes (was leider im Falle des PITs "nur" auf 3*832ns genau wird) nutze ich den Wert des Counters! Also das was du vermutlich mit den Nachkomma-Bits meinst.

Nun zu meiner 2-Klassengesellschaft. Ich habe 2 Queues, eine für Timer >55,4ms und eine für Timer <= 55,4ms.
Wir lassen die periodischen Timer jetzt mal außen vor. Ich habe also einen Thread der will 100ms schlafen. D.h. er kommt auf jeden Fall erstmal in die Queue mit den Timern >55,4ms. Aber nach einem Tick (ich ignoriere die genaue Zeit jetzt mal um es einfacher zu machen) will der Timer ja nur noch 44,6ms warten und d.h. er wird aus der Queue für Timer >55,4ms entfernt und wird in die Queue <=55,4ms gepackt.

Ich hoffe du siehst nun das die Timer früher oder später alle in der Queue <=55,4ms landen und auch nur dort ausgelöst werden können. Die Queue für Timer >55,4ms ist nur dafür da um den Jitter so klein wenig möglich zu halten.

Darf ich Dich an die vielen Smart-Phones erinnern? Es gibt einiges an tollen Nicht-x86-Systemen die für die normalen PC-Arbeiten absolut geeignet sind, z.B. verschiedene NetBooks mit ARM- oder MIPS-Innenleben. Das Problem, welches die Hersteller von einer aktiven Vermarktung abhält, ist einfach das kein Windows (und oft auch kein Flash) drauf läuft. Ich persönlich betrachte beides eher als Vorteil und nicht als Nachteil und hoffe das Android ein Erfolg wird und damit dann die Windows-Pflicht, die viele Hersteller empfinden, deutlich reduziert wird. Mit der Abkehr von Windows kann dann auch eine Abkehr von x86 erfolgen, ich denke beides wird langsam aber sicher an Bedeutung verlieren aber wohl auch nicht ganz verschwinden.

Wie gesagt, Smart-Phones gehören nicht wirklich zu meinen Zielen! Zumal das OS-Deving schon kompliziert genug ist. Wenn ich mich dann auch noch damit auseinander setzen muss wie ich mein OS auf ein solches Smart-Phone bekomme und dann müsste ich noch Reverse-Enginering bertreiben, da die Platformen nicht offen sind und von den vielen total unterschiedlichen Platformen will ich erst gar nicht anfagen. Das wäre einfah nur der absolute Overkill!

Was Windows betrifft, glaube ich nicht das es je komplett verschwinden wird. Dann gibt es halt nen Windows für die anderen Platformen!

Wo gibt es denn diese Netbooks für normale Menschen (und zu normalen Preisen) zu kaufen? Die ARM-Netbooks werden zwar ständig angekündigt, aber kommen tut da nicht wirklich was und von MIPS-Netbooks habe ich noch gar nichts gehört.

Hast Du schon was vom iPad gehört? Die Restriktionen, die Apple künstlich einbaut, finde ich zwar ganz und gar nicht toll (deswegen werde ich wohl nie ein iPad besitzen) aber die Hardware als solche ist schon ziemlich gut (von ein paar fehlenden Schnittstellen abgesehen, die aber gewiss ganz leicht zu integrieren wären). Für ein paar Euro mehr wäre sicher auch Dual-Core und ordentlich RAM möglich, die nötigen Komponenten gibt es jedenfalls. Was der ARM-Plattform fehlt ist der Schritt in Richtung 64Bit. Das haben MIPS und PowerPC schon lange (schon vor x86) und erfolgreich (beide waren schon im High-Performance-Computing vertreten) erledigt und würden sich daher auch für dicke PCs empfehlen. Man darf also gespannt sein was die Zukunft so bringt.

Das iPad ist ja gut und schön (nicht wirklich ), aber wie gesagt, die ganzen Beschränkungen und wer wirklich im Internet surfen will und da schließe ich das Mailschreiben, Forumsbeitragschreiben und Blogschreiben mit ein, der kommt einfach nicht ohne eine Tastatur aus. Zumindest möchte ich nicht solch langen Beiträge wie hier mit ner Tastatur auf nem Touchdisplay schreiben!
Ich kann zwar auch nicht in die Zukunft sehen, aber ich behaupte mal wenn Intel x86 überall haben will, dann bekommen die das auch hin! Ob du gut ist, sei mal dahin gestellt.

Das gleiche Problem gibt es momentan beim Auto. Ein Elektromotor ist was die Effizienz betrifft nem Benzin/Diesel-Motor sowas von überlegen, aber wen interessierts? Das selbe damals beim Video-System (VHS und Beta2000 oder so ähnlich). Wir leben im Kapitalismus und der normale Mensch ist dumm wie Knäckebrot (um es mal ganz überspitzt zu sagen). Der kauft was ihm die Werbung sagt und wer hat die beste Werbung, nicht zwangsläufig der mit dem besten Produkt, sondern der mit dem meisten Geld! Und Intel hat verdammt viel Geld.

Also aus meiner Sicht ist das Netbook ein verdammt gutes Bsp, das es egal ist wie gut oder schlecht ein Produkt ist (Apple fällt da auch rein ). Ich kann mit den Dingern nichts Anfangen. Denn zu wenig Leistung und am Anfang viel zu kleiner Bildschrim. Ich bin Brillenträger und möchte nicht das meine Augen noch schlechter werden (bezieht sich auf bestimmte "hohe" Auflösungen auf nem viel zu kleinem Bildschirm).

Das Problem eines wirklich guten Produktes ist doch, es muss auch ne Firma mit entsprechenden finanziellen Mitteln dahinter stehen. Denn wenn PowerPC so toll wäre, warum haben wir den dann heute nicht im Mainstream bereich (ich weiß das sie im Serverbereich ganz gut sind)?

Das selbe wurde auch in nem anderem Forum diskutiert. Da ging es darum warum so wenig DAUs AMD wollen. Es mangelt einfach an Werbung und die kostet Geld.

So ich denke ich bin jetzt genug abgeschweift

[FlashBurn]

Um das Thema mal wieder zu beleben habe ich mir in letzter Zeit mal Gedanken gemacht, wie ich das Problem mit dem Jitter bei periodischen Events die kleiner (von der Zeit her) sind als der periodische Timer (im Falle des PIT <55,4ms).

Ich habe mir überlegt, das von den periodischen Events immer so viele "Kinder" von dem Event erstellt werden (und damit auch in die Queue wandern) das genau ein Kind soweit in der Zukunft liegt, das es in der Queue des periodischen Timers liegt. Damit bleibe ich auf lange Sicht Konstant, kann aber trotzdem die Events die zwischen zwei Ticks von dem periodischem Timer liegen, sehr genau feuern lassen.

Soweit so gut. Das Problem was jetzt aber kommt ist, dass man damit das System ganz leicht in die Knie zwingen kann, indem man einfach eine sehr kleine Periode nimmt (z.B. 20µs = 2770 "Kinder"-Events).

Ich sehe da jetzt 2 Lösungen, einfach ignorieren und hoffen das keiner auf die dumme Idee kommt oder die Zeit für eine Periode einschränken.

Auf der einen Seite möchte ich das man das System nicht so leicht in die Knie zwingen kann, aber auf der anderen Seite möchte ich es auch nicht künstlich beschränken. Obwohl scheinbar bisher niemand eine solch kleine Periode benötigt hat.

[Svenska]

Ich antworte mal auf die anderen Sachen, die dir aber sicher schon bekannt sind.

Der E-Motor spielt keine nennenswerte Rolle im Automobilbereich (vgl. mit Benzin/Diesel), da du nicht genug Strom mitnehmen kannst, um hohe Reichweiten zu erzeugen. Im Bereich der Gabelstapler etc. (lokal begrenzt) sind die Teile Standard, Hybrid ist im Kommen.

VHS hat gewonnen, weil die Monopolisten der anderen Sorten jegliche Form von Pornographie auf ihren Medien verboten haben. Auf VHS waren diese erlaubt, und so verbreitete sich das System, trotzdem es qualitativ schlechter war.

Ich hab ein Netbook, mit 7" Display und 800x480 Auflösung (die Auflösung ist sehr gering). Wenn man das auf 10" und 1024x600 hochrechnet, kann man damit durchaus arbeiten. Und ich hab -10 Dioptrien. Praktisch ist halt die Größe - man hat es immer dabei, wiegt fast nix und hat ne vernünftige Akkulaufzeit. Ist mir in der Uni sehr wichtig. Richtig doof sind drei Dinge... die 2GB SSD (definitiv zuwenig, nächstemal mind. 4GB), der VIA C7 1GHz (ist halt nicht soo schnell, trotz Hardwarecrypto) und der VIA VX800 / Chrome9-Grafikchipsatz (Linux-Treiber sind unter aller Sau, kein 3D, kein XvMC, buggy Xv, kein DualScreen). Trotzdem möchte ich es nicht missen. Das hängt vom Anwendungsfall ab - mal schnell was nachgucken geht besser als ohne Rechner. Und ich hab einen schnellen SSH/VNC-Server zuhause...

ARM, MIPS haben wesentlich mehr Rechenleistung je Stromverbrauch als x86 oder PPC. Dafür hat x86 die maximale Rechenleistung pro CPU bei gegebenem Preis, da hält PPC nicht mit. Für mich wäre ein schnelles ARM-Netbook durchaus akzeptabel, aber solange sich keine Architektur durchsetzt, nehmen die Hersteller lieber einen Intel Atom und pappen nen Ubuntu drauf, als ein ARM mit Custom-Architektur, wo sie dann Kernel/Userland selber warten müssen. Gibt aber schon bestrebungen, ARM-Linux zu vereinheitlichen. Bei MIPS wird das prinzipiell nicht geschehen, da die Architektur nicht fest ist - bei ARM hast du recht enge Grenzen, die du einhalten musst, bei MIPS darfst du auch am Befehlssatz schrauben und es noch MIPS nennen. Dafür kannst du es besser synthetisieren und gleich mit anderer Hardware (DSL-Modem, ZigBee-/Bluetooth-Stack, TCP-Beschleuniger, ...) auf einen Chip packen. Das geht mit ARM nicht so gut.

So, jetzt weiter zum Topic

Gruß,
Svenska

[erik.vikinger]

Hallo,


dann schreibe ich in diesem Thread auch mal wieder etwas, hab ja schließlich angefangen mit diesem Thema.

Ich habe mir überlegt, das von den periodischen Events immer so viele "Kinder" von dem Event erstellt werden (und damit auch in die Queue wandern) das genau ein Kind soweit in der Zukunft liegt, das es in der Queue des periodischen Timers liegt. Damit bleibe ich auf lange Sicht Konstant, kann aber trotzdem die Events die zwischen zwei Ticks von dem periodischem Timer liegen, sehr genau feuern lassen.

Ich finde Dein Konzept immer noch irgendwie unnötig kompliziert. Wenn Du keine genaue Hardware zur Verfügung hast (also keinen HPET) dann kannst Du auch kaum genaues Timing für die Applikationen anbieten. Mit den Tricks legst Du Dir meiner Meinung nach nur ein faules Ei ins Nest, also Komplexität deren Nutzen in Relation zum Aufwand wahrscheinlich viel zu klein ist. Aber das ist nur meine persönliche Meinung, vielleicht könnten sich dazu auch mal andere Leute äußern.

Ich sehe da jetzt 2 Lösungen, einfach ignorieren und hoffen das keiner auf die dumme Idee kommt oder die Zeit für eine Periode einschränken.
Auf der einen Seite möchte ich das man das System nicht so leicht in die Knie zwingen kann, aber auf der anderen Seite möchte ich es auch nicht künstlich beschränken. Obwohl scheinbar bisher niemand eine solch kleine Periode benötigt hat.

Also ich denke das ich für periodische Events eine untere Grenze definiere oder das ich meine PopUp-Threads als Limit benutze (also für jedes Event ein PopUp-Thread erstellt wird aber nur wenn der PopUp-Thread vom letzten Event schon wieder ans System zurückgegeben wurde). Das Problem ist aber schon interessant, man will keine (potentiell nützlichen) Möglichkeiten unterbinden aber auch das System nicht in die Knie gehen lassen. Mich würde dazu mal interessieren wie andere OSe das lösen.


Auf http://www.openbsd.org/loongson.html sieht man ein interessantes Nettop mit MIPS-kompatiblem Innenleben. Aber der Godson-Prozessor will auch x86-kompatibel werden, offenbar sehen auch in China die Verantwortlichen einen gewissen Druck in Richtung Windows (die pressen ja schließlich auch die Backup-Kopien von Windows ).
Leider muss ich Svenska recht geben, wenn hinter einer guten Idee nicht auch gutes Geld steht dann kommt leider nur selten ein gutes Produkt bei raus.


Grüße
Erik

[FlashBurn]

Ich finde Dein Konzept immer noch irgendwie unnötig kompliziert. Wenn Du keine genaue Hardware zur Verfügung hast (also keinen HPET) dann kannst Du auch kaum genaues Timing für die Applikationen anbieten. Mit den Tricks legst Du Dir meiner Meinung nach nur ein faules Ei ins Nest, also Komplexität deren Nutzen in Relation zum Aufwand wahrscheinlich viel zu klein ist.

Kompliziert ist es bzw. wird es immer mehr, desto mehr Probleme ich "ausbügeln" muss
Das Ziel ist es auch ohne HPET ein annährend genaues Timing zu haben. Dass das ganze kompliziert wird war mir klar.

... Mich würde dazu mal interessieren wie andere OSe das lösen.

In dem Sinne, gar nicht! Wenn du einen periodischen Timer nutzt ist die untere Grenze genau 1 Tick (im Falle von Windows 10ms oder 15ms). Ansonsten haben sich die jeweiligen Programmierer die kleinere und/oder genauere Events benötigten eben anderes beholfen. Z.B. indem das Video am Audio synchronisiert wird.
Ab Vista wird dann sogar der HPET genutzt (unter XP wird er zwar erkannt, aber nicht genutzt).

Wie das ganze unter Linux läuft weiß ich nicht, aber da auch Linux mal nen periodischen Timer hatte, gehe ich mal davon aus, dass für diesen Timer das gleiche gilt wie unter Windows.
Wie sie das dann mit dem tickless Timer gelöst haben müsste man auch nachgucken.

Was die MIPS Platform angeht. Nach dem was ich da gerade auf deinem Link gelesen habe, war das nicht gerade ein toller Start. Ich meine Hardwarefehler, welche ich dann umgehen muss, sonst friert das System ein. Auf solche Spielchen wollte ich mich eigentlich nicht einlassen. Dann lieber eine ARM-CPU, aber auch bei der ist das Problem, die werden zwar seit Jahren angekündigt, aber auf dem Markt kommen sie nicht wirklich an!

[erik.vikinger]

Hallo,

Kompliziert ist es bzw. wird es immer mehr, desto mehr Probleme ich "ausbügeln" muss

Es könnte passieren das Du so viele Problemchen "ausbügeln" musst das Du am Ende Dein eigentliches Ziel verfehlst. Das wäre schade.

Das Ziel ist es auch ohne HPET ein annährend genaues Timing zu haben. Dass das ganze kompliziert wird war mir klar.

Nur mit dem PIT alleine ist das mMn unmöglich (entweder ist man auf eine konstante/niedrige PIT-IRQ-Frequenz festgelegt oder man verliert die Langzeitgenauigkeit wenn man immer wieder am PIT rumdreht), und wenn Du noch einen/mehrere Local-APIC-Timer benutzt kannst Du zwar theoretisch eine höhere Genauigkeit bekommen hast aber auch Probleme weil diese zwei Systeme nicht exakt Synchron sind und langsam aber sicher auseinander driften.

... Mich würde dazu mal interessieren wie andere OSe das lösen.

In dem Sinne, gar nicht!

Da hast Du wohl recht. Bei mir wird das sicher ähnlich enden, der PopUp-Thread läuft mit der Priorität seines Prozesses (also das Programm das den Timer angefordert hat) so kann zumindest kein einfaches User-Programm einen Root-Prozess, wie z.B. Geräte-Treiber u.ä., ausbremsen. Es ist mir persönlich schon wichtig das ich zumindest immer an eine Root-Shell komme um dort amok laufende Prozesse abschießen zu können.

Was die MIPS Platform angeht. Nach dem was ich da gerade auf deinem Link gelesen habe, war das nicht gerade ein toller Start. Ich meine Hardwarefehler, welche ich dann umgehen muss, sonst friert das System ein. Auf solche Spielchen wollte ich mich eigentlich nicht einlassen.

Das sind Anfangsprobleme, das Bild zeigt sicher einen Prototyp bzw. ein Exemplar einer Null-Serie (von denen es vielleicht 5 Stück gibt), da muss man immer noch mit dem einen oder anderen Hardware-Problem kämpfen. Bei den meisten Produktentwicklungen wo ich bis jetzt beteiligt war musste erst eine zweite oder dritte Hardware-Revision gefertigt werden bis alles Rund läuft. Einen Bug im Platinenlayout kann man nicht einfach mal so fixen wie einen Bug in der Software, da wird erst mal ein SW-Workaround programmiert und das Problem in die ToDo-Liste für die nächste Hardware-Revision aufgenommen. Wenn dann der Softi sagt das er keine weiteren Hardware-Probleme entdeckt hat dann startet man mit dem nächsten Entwicklungszyklus. Auf der nächsten Hardware-Revision baut man dann alle SW-Workarounds aus und schaut ob die Hardware nun sauber läuft, wenn nicht dann bekommt die Hardware-Abteilung vom Chef erklärt wie viel Geld diese Hardware-Revision eigentlich gekostet hat und es startet ein nächster Entwicklungszyklus. Bei guten Profis bzw. nicht zu exotischen Entwicklungen sind meistens nur ein oder zwei Entwicklungszyklen erforderlich, bei komplizierten oder neuartigen Sachen, wo keiner mit Erfahrung hat, sollte man besser ein oder zwei Entwicklungszyklen mehr annehmen. Das Management bestimmt dann das der richte Zeitpunkt ein Produkt auszuliefern dann ist wenn die SW-Workarounds für die verbleibenden Hardware-Bugs nicht mehr einfach zu erkennen sind, das bedeutet dann das der SW-Entwickler seine SW so gestalten muss das diese die exakte HW-Revision erkennt und die nötigen Workarounds aktiviert, da das nicht immer perfekt klappt bleiben manche Workarounds einfach immer drin. Schlimmer wäre es wenn Käufer der ersten Stunde keine SW-Updates bekommen könnten und noch schlimmer wäre es wenn der Kunde vor dem SW-Update die exakte HW-Revision bestimmen müsste (um den passenden Download zu selektieren) dann müsste man ja zugeben fehlerhafte Hardware ausgeliefert zu haben. Wer sich jetzt noch über so manche Probleme mit seinem Produkt wundert bzw. sich ärgert warum manche offensichtlichen (SW-)Bugs einfach nicht gefixt werden der sollte mal in großen Unternehmen dem Management über die Schulter schauen. Ich hab dort oft genug zu gesehen, eigentlich zu oft aber von irgendetwas muss man ja schließlich leben.

Dann lieber eine ARM-CPU, aber auch bei der ist das Problem, die werden zwar seit Jahren angekündigt, aber auf dem Markt kommen sie nicht wirklich an!

Das hat nichts mit ARM oder MIPS oder anderen CPU-Architekturen zu tun. Bis jetzt gibt es nur eine Firma die gute ARM-Systeme erfolgreich anbietet aber leider machen dort bestimmte Management-Entscheidungen, die die zugehörige Software betreffen (oder fehlende HW-Schnittstellen), diese Produkte für einen mündigen Käufer quasi gänzlich indiskutabel.


Grüße
Erik

[FlashBurn]

Nur mit dem PIT alleine ist das mMn unmöglich (entweder ist man auf eine konstante/niedrige PIT-IRQ-Frequenz festgelegt oder man verliert die Langzeitgenauigkeit wenn man immer wieder am PIT rumdreht), und wenn Du noch einen/mehrere Local-APIC-Timer benutzt kannst Du zwar theoretisch eine höhere Genauigkeit bekommen hast aber auch Probleme weil diese zwei Systeme nicht exakt Synchron sind und langsam aber sicher auseinander driften.

Ahhh

Deswegen nutze ich ja immer 2 Timer, einen der "tickless" läuft und einen der periodisch läuft, aber die Periode ziemlich lang ist (im Falle des Gespanns APIC/PIT 55,4ms) bzw. theoretisch wenn kein periodisches Event läuft, kann er (der periodische Timer) abgestellt werden.

Da das alles in meiner Freizeit als Hobby läuft mach ich es sowieso so, dass ich meine Idee implementiere und wenn ich dann irgendwann später feststelle die Idee war doch nicht so gut oder hat noch Lücken, dann bessere ich halt nach. Soll heißen ich habe mir keinen Plan für meine Entwicklung gemacht und ich überlege mir nicht schon vorher wie alles hinterher aussehen soll. Dadurch dauert es manchmal etwas länger bzw. muss oft Code komplett neu geschrieben werden, aber es geht schneller (was in dem Fall sehr relativ ist ) voran.

Das hat nichts mit ARM oder MIPS oder anderen CPU-Architekturen zu tun. Bis jetzt gibt es nur eine Firma die gute ARM-Systeme erfolgreich anbietet aber leider machen dort bestimmte Management-Entscheidungen, die die zugehörige Software betreffen (oder fehlende HW-Schnittstellen), diese Produkte für einen mündigen Käufer quasi gänzlich indiskutabel.

Ich gehe mal davon aus du redest von Apple.

Nachdem was ich in letzter Zeit so in verschiedenen News gelesen habe, ist das Interesse an ARM System, besonders an Servern (im Hinblick auf den Energieverbrauch) aber groß genug.
Sagen wir es doch so wie es ist. Linux als alleiniges Betriebssystem verkauft sich nicht für die Masse und Windows gibt es nicht vernünftig für die ARM CPUs (von den Mobile Versionen mal abgesehen).

Was ich an den MIPS zu bemängeln hatte, war aber das die ja schon Netbooks herstellen und selbst die OpenBSD Entwickler gesagt haben, das sie nicht alle Work-Arounds implementieren werden und MIPS ist jetzt nicht gerade ne niegel nagel neue Architektur. Ich kenne mich da zwar leider auch nicht aus, aber ist es da nicht wie bei ARM, soll heißen du kaufst so zu sagen "Pläne" und kannst dann deine eigene CPU zusammen basteln?!

Naja, ich hoffe das bald ARM-Systeme in großer Stückzahl zu finden sein werden (im Net/Notebook und PC Segment). Wenn ich das Geld hätte, würde schon längst so ein schickes BeagleBoard bei mir zu Hause stehen!

[Svenska]

Die MIPS-Architektur unterliegt weniger Restriktionen als die ARM-Architektur, d.h. man darf auch Befehle hinzufügen und/oder entfernen und es trotzdem noch als MIPS verkaufen. Außerdem ist MIPS einfacher gestrickt als ARM, daher findet man fast keine reinen MIPS-Prozessoren; da ist meist noch ziemlich viel dabei (z.B. DSL-Modem in den Fritzboxen, die CPUs sind von TI).

Bei ARM muss man recht enge Grenzen einhalten, was den CPU-Befehlssatz betrifft, so dass alle ARM-Chips garantiert kompatibel sind, wenn sie den gleichen Befehlssatz (ARMv4, Thumb, ...) sprechen.

Davon unabhängig ist leider die Systemarchitektur, weswegen es zwar immer wieder Versuche gibt, aber kein Linux-for-all-ARM. Das geht prinzipiell nicht. Naja, für Netbooks hat sich ein ARM-Consortium gegründet, welches eben diese Architektur standardisieren möchte, schaunmermal. Wird in jedem Fall noch ein paar Jahre dauern.

Das einzige ARM-(XScale-)System, was ich hier habe und wo Debian drauf installiert ist und läuft, ist ein NAS (Thecus N2100 / Allnet). Das Teil ist laut, hat einen nicht regelbaren Lüfter und die Performance ist unter aller Sau. (Hat 2x GBit Ethernet und schafft insgesamt keine 100 MBit/s ... außerdem müssen die Kernel stark gepatcht werden und Intel wartet die Patches nicht.) Enttäuschend.

Gruß

[FlashBurn]

So ich melde mich auch mal wieder und möchte mal wieder was zum eigentlichen Topic beitragen.

Da ich mal wieder Zeit gefunden haben ein wenig an meinem System zu arbeiten und ich mich auch endlich mal mit der 3D-Programmierung befassen will, ist mir wieder eingefallen wozu man nen "High-Performance-Counter" braucht.
Bei Spielen möchtest du ja das sich die Spieler-Figur auf jedem Rechner (egal wie schnell oder langsam) gleich schnell bewegt. Dazu benutzt man solch einen "High-Performace-Counter". Um sagen zu können, so seit dem letzten Zeichnen ist ne bestimme Zeit vergangen und die Spielerfigur bewegt sich damit jetzt ne bestimmte Anzahl von "Pixeln".

Problem ist nun natürlich, wie implementiert man solch einen Counter im System. Ich habe nochmal ein wenig gesucht und habe jetzt hoffentlich nen brauchbares System dafür gefunden.

Ich werd dafür ne Kombination aus dem ACPI-PMT und dem PIT bzw. wenn möglich den TSC nehmen.

Den ACPI-PMT kann ich natürlich nur nutzen wenn ACPI auch vorhanden ist (da mein System ja auch PCs unterstützt die kein ACPI haben). Ist das System aber so alt das es kein ACPI hat, dann sollte ich davon ausgehen können das ich ohne Bedenken den TSC nutzen kann (ist dem so? konnten sich die CPUs damals schon runtertakten?).
Warum will ich den ACPI-PMT in Kombination mit dem PIT nutzen? Also erstens einmal gibt es das Problem das je nachdem wie der PMT implementiert ist, der Counter entweder 24bit oder 32bit groß ist. Er läuft also alle 4Sek oder alle 1130Sek über. Nutze ich diesen Counter jetzt in Kombination mit dem PIT, so erspare ich mir auch ständig den PIT lesen zu müssen (was ja ein Problem mit meinem System ist), da ich einfach bei jedem PIT-IRQ den Counter auslese und abspeichere. Will ich dann wissen wieviel Zeit seit dem letzten PIT-IRQ vergangen ist, brauche ich einfach nur den PMT auslesen und die Differenz zw dem aktuellen Wert und dem gespeicherten Wert ausrechnen (da kann ich dann auch relativ einfach den Überlauf behandeln). Desweiteren sollte ich damit auch das Problem umgehen, das der PMT wohl auch mal 4Sek oder mehr abtriftet (da ich ja immer nur die Differenz zw 2 Werten nehme und nicht den Counter nutze um die Werte aufzuaddieren).

Was den TSC betrifft, so würde ich diesen genauso benutzen wie den PMT.

Habe ich einen solchen "High-Performance-Counter" kann ich auch mein Event-System (also das mit "tickless"-Timer) einfacher umsetzen.

Optimal läuft das ganze natürlich erst mit dem HPET. Obwohl ich mal behaupte das ich so eigentlich alle Probleme der vielen Timer umgehen sollte. Das einzigste was ich dann nicht mehr machen kann, ist den PIT (als periodischen Timer) abschalten, wenn keine Events vorhanden sind. Denn ich möchte ja jetzt über diesen auch die Systemzeit und den "High-Performance-Counter" implementieren. Ich denke aber das ich damit leben kann

So bin für Meinungen offen und bitte auch etwaige Fehler die in dem System stecken nennen!

[erik.vikinger]

Hallo,

.... und ich mich auch endlich mal mit der 3D-Programmierung befassen will

Womit Du dann aber doch wieder Off-Topic wirst.

, ist mir wieder eingefallen wozu man nen "High-Performance-Counter" braucht.
Bei Spielen möchtest du ja das sich die Spieler-Figur auf jedem Rechner (egal wie schnell oder langsam) gleich schnell bewegt. Dazu benutzt man solch einen "High-Performace-Counter". Um sagen zu können, so seit dem letzten Zeichnen ist ne bestimme Zeit vergangen und die Spielerfigur bewegt sich damit jetzt ne bestimmte Anzahl von "Pixeln".

Das konnte DOOM bereits vor über 15 Jahren auch ohne den ganzen neumodischen Kram. Wäre natürlich mal sehr interessant zu schauen wie die das damals gemacht haben, der Source-Code ist ja wimre offen zugänglich.

Ich werd dafür ne Kombination aus dem ACPI-PMT und dem PIT bzw. wenn möglich den TSC nehmen.
.....

Ich habe ehrlich gesagt kaum etwas von dem verstanden was Du da schreibst. Vielleicht solltest Du mal die verschiedenen HW-Kombinationsmöglichkeiten (die Dein OS unterstützen soll) aufzählen und für jede einzeln und präzise erklären was Du genau vor hast.


Außerdem empfehle ich Dir ernsthaft Dich erst mal auf eine (eventuell auch zwei ähnliche) HW-Kombination fest zu legen und nur für diese zu programmieren, wenn das fertig ist kannst Du immer noch überlegen ob Du auch für andere HW-Kominationen noch Lust hast bzw. ob Dein Konzept da überhaupt läuft. Alles auf einmal angehen zu wollen könnte unter Umständen nicht so gut enden. Ich will Dir nicht absprechen das Du das alles erfolgreich hinbekommst, das ist nur ein gut gemeinter Rat von jemandem der auch schon mal daneben gegriffen hat.


Grüße
Erik

[FlashBurn]

Um es kurz zu machen, implementiert war es 1 Tag nach dem Post

Ich habe ehrlich gesagt kaum etwas von dem verstanden was Du da schreibst. Vielleicht solltest Du mal die verschiedenen HW-Kombinationsmöglichkeiten (die Dein OS unterstützen soll) aufzählen und für jede einzeln und präzise erklären was Du genau vor hast.

Du wolltest es so

Also ältere PCs haben kein ACPI (auf denen sollte dann der TSC 100%ig laufen), aber nen PIT und die RTC. Ich nutze also den PIT für meinen One-Shot-Scheduler. Die RTC wird im periodischen Modus (62,5ms) programmiert und inkrementiert immer nen Counter, aber was viel wichtiger ist, bei jedem Aufruf des Interrupthandlers (von der RTC) speichere ich den aktuellen TSC Wert.
So kann ich ganz einfach sagen, wieviel "Ticks" (welche man dann auch "einfach" in nsek umrechnen kann) seit dem letzten RTC Interrupt vergangen sind. Damit hab ich nen wirklich Hoch-Präzisen-Counter (je nachdem wie schnell die CPU ist).

Hat man dann nen PC mit ACPI, kann man den ACPI-PMT (Performance Monitor Timer, wimre) nutzen, anstatt des TSCs. Sprich das System bleibt das gleiche, ich nutze den PIT für den One-Shot-Scheduler und die RTC für nen periodischen Interrupt. Anstatt des TSC als Counter nutze ich aber jetzt den ACPI-PMT, womit ich Probleme durch runtertakten oder ähnliches umgehen will.

Hat der PC dann auch noch nen APIC, den ich nutzen kann, ändert sich das System ein wenig. Der APIC wird für den One-Shot-Scheduler genutzt. Diesmal nehme ich den PIT im periodischen Modus (55ms) anstatt der RTC. Ansonsten funkioniert es hier wieder genauso. Beim Interrupthandler des PITs wird der aktuelle Wert des ACPI-PMTs gespeichert.

Bei SMP-System findet das gleiche System wie oben Anwendung.

Wie funktioniert jetzt der Hoch-Präzise-Counter?

Wenn ich ganz genau bin, ist das nicht irgendein Counter, sondern der wird sogar in nsek geführt. Soll heißen, wenn man sich den Wert holt und 1000 bekommt und der letzte Wert den man sich geholt hat war 500, dann sind "Pi mal Daumen" 500ns vergangen.
Ich rechne auf meinen globalen Counter (wird über RTC oder PIT implementiert) immer genau die nsek drauf, wie zwischen 2 Interrupts liegen.
Will dann ein Programm den Wert des Counters haben, mache ich folgendes (vereinfacht):

Code: [Auswählen]

uint64t counter= nsecscounter, perf= perfcounterRead(), last= timeLastInt;

if(flags & USING_TSC)
    return counter + ((perf - last) * tscTickNSecs);
else
    return counter + ((perf - last) * acpiPMTTickNSecs);
Natürlich behandle ich in meinem Code noch überläufe, was beim ACPI-PMT sehr wichtig ist (da er entweder bei 4 Sek (24bit) oder 1130 Sek (32bit) überläuft), aber das ist für das Bsp nicht wichtig.

Das zu implementieren ist/war nicht schwer, ist auch nicht wirklich viel Code. SMP-Safe ist das ganze auch noch, sprich ich brauche keine Locks dafür nutzen (den Fall das sich der Counter während des auslesens ändert oder halt der Wert von "TimeLastInt" beachte ich in meinem Code auch).

Wie gesagt sollte ich nun alle Probleme, Schwächen und sonstige Sachen ausgebügelt haben. Ich habe alles was ich wollte, nen One-Shot-Scheduler, nen Hoch-Präzisen-Counter und ich kann meine Threads für sehr kurze Zeiten (<1ms) und das ganze noch mit ne verdammt vernünftigen Präzision schlafen legen.

Wenn ich die Zeit und Lust (da ich es bisher nicht wirklich brauche) finde, werde ich auch noch den HPET nutzen.

Da bin ich mir dann aber noch nicht sicher wie ich es mache. Aufjeden Fall wird der HPET dann den PIT, in seiner Funktion, ersetzen, aber ob ich dann auf nen 3. Counter verzichte (also auf TSC oder ACPI-PMT) weiß ich noch nicht. Am liebsten würde ich dafür dann wieder den TSC nutzen, was auf neueren CPUs ja wieder ohne Probleme möglich ist. Das hätte halt den Vorteil, das ich nicht ständig den HPET auslesen müsste (zwecks Counter-Wert) und ich würde so eine noch höhere Auflösung (da der TSC, wenn er an die CPU Frequenz geknüpft ist, ja ne verdammt hohe Freq hat) bekommen. Mal ganz davon abgesehen, dass das Auslesen des TSCs wohl schneller sein dürfte als das Auslesen des HPETS.

Ich hoffe ich war präzise genug, wenn nicht, wie gehabt, einfach fragen!

Edit::

Mir ist noch ein wunderbarer Vergleich eingefallen. Im Endeffekt entspricht das System einer Uhr mit Stunden- (periodischer Interrupt -> RTC/PIT) und Minutenzeiger (Counter -> TSC/ACPI-PMT)

[Svenska]

Ich würde mich nie Nie NIE auf den TSC verlassen, schon garnicht systemweit.

Den TSC gibt es erst ab i586 (gut, das kann man vernachlässigen), aber er ist grundsätzlich nicht stabil. Kein ACPI ist ein Hinweis, aber kein Grund - mobile Systeme mit Stromsparfunktionen gab es auch schon vorher (POWER.EXE). Obwohl es später nicht mehr so oft gemacht wurde, besteht auch bei APM die Möglichkeit, die CPU vom BIOS runtertakten zu lassen - das heißt, der TSC läuft langsamer. Außerdem gibt es Möglichkeiten zu Suspend und Standby, die vollständig vom BIOS gesteuert werden.

Mein 486er Notebook hat eine Hardwaretaste für Standby. Drückst du die, ist das Betriebssystem "aus", die PCMCIA-Verwaltung wird ebenfalls vom BIOS erledigt. Das OS kriegt nichtmal mit, dass es gerade abgewürgt wird. (Du kannst aber auch Start>Standby machen, aber auch das führt zu "klack">Standby.) Bei Pentiumsystemen ist das teilweise auch so.

Benutze den TSC für das, für das er gebaut wurde - Hochgeschwindigkeitszeitmessungen auf kurzen Zeiträumen. Alles andere ist nicht grundsätzlich verlässlich; ein Timingsystem darauf aufzusetzen ist ungünstig.

Gruß,
Svenska

[FlashBurn]

@Svenska

Also ich habe deine Bedenken zur Kenntnis genommen. Ich weiß das der Pentium irgend so ein "SL Enhanced Power Management" hat, aber was das genau bedeutet konnte ich leider noch nicht finden.

Um mir meine Sache jetzt nicht unnötig schwer zu machen, nutze ich erstmal den TSC weiter. Im Moment ist das einzigste Problem was ich mir vorstellen kann, ein kurzzeitiges "stocken/stolpern" des Hoch-Präzisen-Counters. Der Vorteil ist ja, das er periodisch "synchronisiert" wird und damit etwaige Fehler des kleinen "zwischen"-Counters (TSC/ACPI-PMT) ausbügelt.

Wenn wir gerade schon beim TSC sind. Weiß jemand wie man bei Intel nachgucken kann (z.B. mittels CPUID) ob der TSC immer konstant aktualisiert wird? Ich weiß das es bei AMD dafür extra nen Flag bei CPUID gibt, habe aber bei Intel dazu noch nichts gefunden. Ansonsten müsste ich halt Family und Co auslesen und danach dann entscheiden ob ich ihn nutzen kann oder nicht.

@Offtopic

Weiß jemand ob man zu alten Sockel7 Zeiten das ACPI im BIOS aktivieren musste? Irgendwie findet mein Loader bestimmte ACPI Sachen nicht, obwohl diese vorhanden sein müssten (handelt ich um ein Board mit nem VIA MVP3 Chipsatz).

[Svenska]

Vielleicht findest du in den Dokumenten zum i386SL/i486SL Informationen zum Power Management. Ich kann mich jedenfalls nicht daran erinnern, dass das beim Pentium groß beworben wurde; ich vermute, es wurde einfach von den Vorgängern übernommen.

Wenn die CPU hinreichend viele NOPs ausführt, [oder keine Bildschirm-/Tastatureingabe erfolgt,] kann das BIOS den CPU-Takt automatisch auf einen dort vorher eingetragenen Wert (z.B. CLK/16) senken, außerdem gibt es eine APM-Idle-Funktion. Dazu kommen dann noch Sachen wie Bildschirmabschaltung etc. Wichtig ist, dass das BIOS anhand von Systemeigenschaften entscheidet, ob der Takt nun runtergesetzt wird oder nicht und das Betriebssystem davon nichts(!) mitkriegen muss.

Ich hatte mal ein Pentium-Notebook, auch da wurde der TSC als instabil markiert. Bei den Desktop-Pentiums dürfte der TSC eigentlich immer stabil sein, aber solche Geräte lagere ich aus Platzgründen bei mir nicht mehr. Genau sowas macht aber Entscheidung schwieriger, da du zwischen aktivem/inaktivem Power-Management unterscheiden müsstest - was man im BIOS umstellen kann - ob der TSC nun immer stabil ist oder nicht.

Bedenke die Konsequenzen, was passiert schlimmstenfalls, wenn dein hochpräziser Counter groben Unfug enthält? Und denke auch daran, dass du bei _jeder_ Nutzung darauf Rücksicht nehmen musst. Wenn du nämlich dein Gesamttiming auf diesen Counter irgendwie aufbaust, wird das dir später böse in den Rücken fallen - möchtest du das Teil nur für kurzzeitige, exakte Messungen nutzen, reicht der TSC auch direkt aus und du sammelst dir keine Probleme ein.

Naja, und dann stelle ich mir halt noch die Frage, warum du auf so einem (langsamen) System einen Couter mit nsek-Auflösung überhaupt brauchst; bei allem, was irgendwie größer als klein ist (Browser, Officepaket, Mediaplayer) kannst du eh nicht mit der geforderten Latenz darauf reagieren. Und wenn du ein richtiges Real-Time-Betriebssystem schreiben möchtest, dann ist das ohnehin nur ein sehr kleiner Teil des Gesamtpaketes.

Gruß,
Svenska

[FlashBurn]

Naja, und dann stelle ich mir halt noch die Frage, warum du auf so einem (langsamen) System einen Couter mit nsek-Auflösung überhaupt brauchst; bei allem, was irgendwie größer als klein ist (Browser, Officepaket, Mediaplayer) kannst du eh nicht mit der geforderten Latenz darauf reagieren. Und wenn du ein richtiges Real-Time-Betriebssystem schreiben möchtest, dann ist das ohnehin nur ein sehr kleiner Teil des Gesamtpaketes.

Naja, ich wollte halt ne Auflösung die <1ms ist ohne das ich nen periodischen Timer dafür nutze. Auf die nseks bin ich gekommen, weil es eine gute Auflösung auch für aktuelle Systeme ist und ich mir so die Arbeit am HAL (Hardware-Abstraction-Layer) vereinfachen wollte.

Bedenke die Konsequenzen, was passiert schlimmstenfalls, wenn dein hochpräziser Counter groben Unfug enthält? Und denke auch daran, dass du bei _jeder_ Nutzung darauf Rücksicht nehmen musst. Wenn du nämlich dein Gesamttiming auf diesen Counter irgendwie aufbaust, wird das dir später böse in den Rücken fallen - möchtest du das Teil nur für kurzzeitige, exakte Messungen nutzen, reicht der TSC auch direkt aus und du sammelst dir keine Probleme ein.

Im Moment schätze ich die Probleme als nicht so schwerwiegend ein (noch ). Denn es kann "nur" zu Problemen innerhalb des Intervalls von 62,5ms (RTC) bzw. 54ms (PIT) kommen. Denn mit jedem Interrupt einer der beiden Timer, stimmt der Wert des Counters wieder ab dem Zeitpunkt. Wenn ich später wirklich feststellen sollte, dass das Intervall zu groß ist, könnte ich es immernoch verkleinern. Aber wie du selbst schon gesagt hast, braucht man "eigentlich" die hohe Auflösung auf solch alten Systemen nicht, also dürfte das etwaige "stoplern/stocken" auch kein Problem darstellen.

Vielleicht findest du in den Dokumenten zum i386SL/i486SL Informationen zum Power Management. Ich kann mich jedenfalls nicht daran erinnern, dass das beim Pentium groß beworben wurde; ich vermute, es wurde einfach von den Vorgängern übernommen.

Genau die Dokumente (vom 486) hab ich mir angeguckt und konnte leider nichts konkretes finden bzw. das was ich gefunden habe, legt nahe, das der TSC komplett stehen bleiben kann. Der Punkt ist aber, dass das ja nur passieren kann wenn die CPU nichts zu tun hat und dann wiederum benutzt auch keiner den Counter und somit gibt es für mich kein Problem.
Denn so wie ich dich und das Dokument verstanden habe, gibt es nur Probleme mit dem TSC, wenn die CPU absolut gar nichts zu tun hat und dann wird, wie gesagt, auch mein Counter in dem Moment nicht gebraucht. Ab dem Zeitpunkt wo er dann vielleicht wieder gebraucht wird und die CPU wieder was zu tun hat, funktioniert das System ja auch wieder. Denn die periodischen Interrupts kommen immer, egal in welchem Zustand sich die CPU befindet.

Mich würde noch interessieren was du genau unter Gesamttiming verstehst, also was da deiner Meinung nach alles dran hängt?

Im Moment nutze ich das nur als Hoch-Präzisen-Counter und eventuell bald um festzustellen, wie lange ein Thread gelaufen ist. Ansonsten um den Zeitpunkt festzustellen, wann ein Thread sich schlafen legen möchte (um den Aufweckzeitpunkt zu errechnen).

[Svenska]

Naja, und dann stelle ich mir halt noch die Frage, warum du auf so einem (langsamen) System einen Couter mit nsek-Auflösung überhaupt brauchst; bei allem, was irgendwie größer als klein ist (Browser, Officepaket, Mediaplayer) kannst du eh nicht mit der geforderten Latenz darauf reagieren. Und wenn du ein richtiges Real-Time-Betriebssystem schreiben möchtest, dann ist das ohnehin nur ein sehr kleiner Teil des Gesamtpaketes.

Naja, ich wollte halt ne Auflösung die <1ms ist ohne das ich nen periodischen Timer dafür nutze. Auf die nseks bin ich gekommen, weil es eine gute Auflösung auch für aktuelle Systeme ist und ich mir so die Arbeit am HAL (Hardware-Abstraction-Layer) vereinfachen wollte.

Pass auf, dass du nicht von der gedachten, aber nicht erreichten Qualität deiner Messung abhängig wirst. Konkret heißt das, dass du nicht unbedingt davon ausgehen kannst, dass dein Timer dann einen monotonen, gleichmäßigen Verlauf hat.

Mal abgesehen scheinst du mit der Grundidee eine Auflösung garantieren zu wollen, die du aber nicht einhalten kannst. Sowas ist bei nem Realtime-System tödlich; für dich wahrscheinlich eh egal.

Bedenke die Konsequenzen, was passiert schlimmstenfalls, wenn dein hochpräziser Counter groben Unfug enthält? Und denke auch daran, dass du bei _jeder_ Nutzung darauf Rücksicht nehmen musst. Wenn du nämlich dein Gesamttiming auf diesen Counter irgendwie aufbaust, wird das dir später böse in den Rücken fallen - möchtest du das Teil nur für kurzzeitige, exakte Messungen nutzen, reicht der TSC auch direkt aus und du sammelst dir keine Probleme ein.

Im Moment schätze ich die Probleme als nicht so schwerwiegend ein (noch ). Denn es kann "nur" zu Problemen innerhalb des Intervalls von 62,5ms (RTC) bzw. 54ms (PIT) kommen. Denn mit jedem Interrupt einer der beiden Timer, stimmt der Wert des Counters wieder ab dem Zeitpunkt. Wenn ich später wirklich feststellen sollte, dass das Intervall zu groß ist, könnte ich es immernoch verkleinern. Aber wie du selbst schon gesagt hast, braucht man "eigentlich" die hohe Auflösung auf solch alten Systemen nicht, also dürfte das etwaige "stoplern/stocken" auch kein Problem darstellen.

Für Zeitmessungen nicht. Wenn du davon dann allerdings deinen Scheduler abhängig machst und der TSC unter Umständen nicht nur stehen bleibt, sondern sogar kaputtgeht, kannst du große Probleme mit dem Scheduling kriegen, wenn du damit nicht rechnest.

Vielleicht findest du in den Dokumenten zum i386SL/i486SL Informationen zum Power Management. Ich kann mich jedenfalls nicht daran erinnern, dass das beim Pentium groß beworben wurde; ich vermute, es wurde einfach von den Vorgängern übernommen.

Genau die Dokumente (vom 486) hab ich mir angeguckt und konnte leider nichts konkretes finden bzw. das was ich gefunden habe, legt nahe, das der TSC komplett stehen bleiben kann. Der Punkt ist aber, dass das ja nur passieren kann wenn die CPU nichts zu tun hat und dann wiederum benutzt auch keiner den Counter und somit gibt es für mich kein Problem.

So einfach ist es, denke ich, nicht. Das BIOS kann ja an sich garnicht feststellen, ob die CPU nun fleißig arbeitet oder nicht - solange es nicht explizit aufgerufen wird. Auf einem Notebook, was ich hier habe (Highscreen 486SX25, ist aber ein SL-Typ) wird die Aktivität an Bildschirm- und Tastaturaktivität gemessen, und zwar ausschließlich! Neben HLT gibt es ja keine CPU-internen Inaktivitätsbefehle.

Das bedeutet, dass ein Prozess unter DOS, wenn er keine Bildschirmausgaben macht und nur rechnet, die CPU in den 2 MHz-Modus schaltet, wenn das Power Management im BIOS aktiviert ist; gleiches gilt im Übrigen unter Windows 95. Auf einem Pentium habe ich dieses Verhalten auch schon einmal beobachtet, bin mir aber nicht mehr sicher.

Denn so wie ich dich und das Dokument verstanden habe, gibt es nur Probleme mit dem TSC, wenn die CPU absolut gar nichts zu tun hat und dann wird, wie gesagt, auch mein Counter in dem Moment nicht gebraucht. Ab dem Zeitpunkt wo er dann vielleicht wieder gebraucht wird und die CPU wieder was zu tun hat, funktioniert das System ja auch wieder. Denn die periodischen Interrupts kommen immer, egal in welchem Zustand sich die CPU befindet.

APM definiert m.W. nur die Systemaktivität, nicht die CPU-Aktivität. Siehe oben.

Mich würde noch interessieren was du genau unter Gesamttiming verstehst, also was da deiner Meinung nach alles dran hängt?

Das hängt von der Nutzung ab.

Ich würde dem TSC - je nach Prozessortyp - im Allgemeinen keine langfristige Monotonie oder Stabilität zutrauen.

Im Moment nutze ich das nur als Hoch-Präzisen-Counter und eventuell bald um festzustellen, wie lange ein Thread gelaufen ist. Ansonsten um den Zeitpunkt festzustellen, wann ein Thread sich schlafen legen möchte (um den Aufweckzeitpunkt zu errechnen).

Wäre es da nicht sinnvoller, den Thread selbst den Aufweckzeitpunkt bestimmen zu lassen?

Gruß,
Svenska

[FlashBurn]

Mal abgesehen scheinst du mit der Grundidee eine Auflösung garantieren zu wollen, die du aber nicht einhalten kannst. Sowas ist bei nem Realtime-System tödlich; für dich wahrscheinlich eh egal.

Ich sag mal alles unter 1ms ist doch schon gut, wie genau es dann unter 1ms wird, ist doch erstmal zweitrangig.
Um es genauer zu sagen ist es mir wichtig, wenn ein Thread in 55ms aufgeweckt werden will, das er auch in annährend 55ms aufgeweckt wird (nur mal so als Bsp.) und nicht erst in 60ms.

Für Zeitmessungen nicht. Wenn du davon dann allerdings deinen Scheduler abhängig machst und der TSC unter Umständen nicht nur stehen bleibt, sondern sogar kaputtgeht, kannst du große Probleme mit dem Scheduling kriegen, wenn du damit nicht rechnest.

Genau das hält mich im Moment noch davon ab, diesen Counter auch im Scheduler zu nutzen. Denn das "witzige" daran ist, der eigentliche Grund ihn zu nutzen ist der PIT. Es wäre halt viel schneller den Counter zu lesen als den PIT und ich rede hier von 2496ns, hört sich erstmal nicht nach viel an, aber wenn man das pro Scheduleraufruf sparen kann, so summiert sich das nach einer Weile ganz schön auf. Um jetzt nochmal auf das "witzige" zu kommen, wenn ich den PIT nicht mehr nutze (also dann den APIC), dann habe ich (mit Ausnahme von ein paar alten SMP-System) eigentlich auch den ACPI-PMT zur Verfügung und brauche den TSC nicht nutzen.

So einfach ist es, denke ich, nicht. Das BIOS kann ja an sich garnicht feststellen, ob die CPU nun fleißig arbeitet oder nicht - solange es nicht explizit aufgerufen wird. Auf einem Notebook, was ich hier habe (Highscreen 486SX25, ist aber ein SL-Typ) wird die Aktivität an Bildschirm- und Tastaturaktivität gemessen, und zwar ausschließlich! Neben HLT gibt es ja keine CPU-internen Inaktivitätsbefehle.

Das bedeutet, dass ein Prozess unter DOS, wenn er keine Bildschirmausgaben macht und nur rechnet, die CPU in den 2 MHz-Modus schaltet, wenn das Power Management im BIOS aktiviert ist; gleiches gilt im Übrigen unter Windows 95. Auf einem Pentium habe ich dieses Verhalten auch schon einmal beobachtet, bin mir aber nicht mehr sicher.

Wenn das so ist, dann nehme ich darauf erst recht keine Rücksicht! Denn das System funktioniert ja ohnehin nicht wirklich.

Ich würde dem TSC - je nach Prozessortyp - im Allgemeinen keine langfristige Monotonie oder Stabilität zutrauen.

Hier habe ich das Gefühl das du mich, genau wir erik auch, nicht ganz verstanden hast.

Der TSC wird nicht für langfristige Monotonie genutzt. Im Endeffekt musst du dir mein System so vorstellen als wenn du nur eine periodische Quelle (RTC/PIT) hast, die mit nem, verhältnismäßg, langem Intervall (>=55ms) läuft. Diese Quelle ist langfristig gesehen genau! Um jetzt aber auch die Zeit innerhalb dieses Intervalls genau zu kennen, nutze ich eine andere Quelle (TSC/ACPI-PMT).

Als mal als Bsp. die periodische Quelle macht bei jedem Aufruf des Handlers:

Code: [Auswählen]

highPrecisionCounter+= nsecsPeriodicSourceIntervall;
timeLastInt= _rdtsc();
Wenn du jetzt den aktuellen Wert des Counters haben willst machst du das:

Code: [Auswählen]

returnVal= highPrecisionCounter + (_rdtsc() - timeLastInt);

Damit erreiche ich das mit jedem Aufruf des Interrupthandlers der Wert des Counters wieder genau ist, egal was dazwischen mit dem TSC passiert ist!

Ich hoffe du hast es jetzt verstanden. Im Endeffekt nutze ich den TSC um "kurze" (<=62,5ms) Zeiten zu messen.

Wäre es da nicht sinnvoller, den Thread selbst den Aufweckzeitpunkt bestimmen zu lassen?

Auch hier hast du mich nicht ganz verstanden.

Ich meinte damit, dass der Thread die Sleep-Funktion aufruft (wo er als Parameter, die Zeit die er schlafen will angibt), ich den aktuellen Wert des Counters (siehe Oben) hole und darauf die Zeit die er schlafen will drauf rechne und damit weiß zu welchem Zeitpunkt ich ihn wieder aufwecken muss.

[erik.vikinger]

Hallo,


Das Du mit einem periodischem IRQ den TSC eichst, um ihn als zusätzliche Genauigkeit zu nutzen (das meinte ich mit den Nachkommabits), ist prinzipel eine gute Idee aber dafür ist weder der PIT/RTC noch der TSC geeignet. Um genau zu wissen wie viele TSC-Ticks pro IRQ kommen solltest Du das mehrmals messen und zum anderen darfst Du niemals die IRQs abschalten oder andere langwierige (FPU-)Befehle ausführen die in diese Messungen nen Jitter reinbringen könnten ansonsten kannst Du Dir die ns-Aulösung auch gleich ganz sparen. Dass das BIOS (eventuell ohne Dein Wissen) an der Taktfrequenz rumdreht ist denke ich prinzipiel auf jedem Computer möglich der neu genug ist um einen TSC zu haben (das kannst Du zumindest nicht ausschließen und warscheinlich auch nicht erkennen), und damit wird es quasie unmöglich aus dem aktuellen TSC-Stand auch nur abzulesen ob der letzte IRQ erst kurz vorbei ist oder ob gleich der nächste IRQ kommt. Das nächste ist das bei SMP ja mehrere TSCs da sind die garantiert nicht synchron laufen. Da der IRQ ja nur von einer CPU verarbeitet wird (für Dein Vorhaben hoffentlich immer von der selben) kannst Du auch nur diesen TSC als zusätzlichen Genauigkeitslieferanten benutzen und das geht nur wenn der User-Mode-Thread, der gerade sleep() aufruft, auch zufällig auf dieser CPU läuft den an fremde TSCs kommt man ganz sicher nicht ran. Ein weiterer Punkt ist das Du zum umrechnen der TSC-Ticks in Nanosekunden (oder irgendeiner anderen fixen Zeitauflösung) definitiv Gleitkomma-Arithmetik benötigst und selbst dann noch Tricks brauchst um den Jitter beim periodischen TSC auslesen auszugleichen (die einzelnen Taktfrequenzen werden nicht vom selben Quarz erzeugt Du musst also mit minimalen Geschwindigkeitsunterschieden rechnen die möglicherweise erst nach längerer Laufzeit sichtbar werden).

Damit erreiche ich das mit jedem Aufruf des Interrupthandlers der Wert des Counters wieder genau ist, egal was dazwischen mit dem TSC passiert ist!

Nein, damit kennst Du zwar wieder den aktuellen Wert des schnellen Counters aber seine Zählgeschwindigkeit kennst Du nur wenn Du über mehrere exakt getimmte (also jitterfreie und das dürfte bei normaler SW-Nutzung quasi unmöglich sein) Auslesungen den Counterwert beobachtest und genau diese Zählgeschwindigkeit brauchst Du ja damit Du auch einen Nutzen aus dem schnellen Counter ziehen kannst.

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.

Ob an den obigen Problemen der ACPI-PMT noch was bessert kann ich nicht sagen, den kenne ich nicht da ich mich nur sehr oberflächlich mit ACPI beschäftigt habe. Kann der ACPI-PMT Interrupts generieren? Zumindest gibt es diesen nur ein mal aber er ist wohl auch wieder über langsame I/O-Ports angebunden und da die Arbeitsfrequenz nur etwa das doppelte der vom PIT ist solltest Du Dir genau überlegen ob der Aufwand sich überhaupt lohnt.


Am Anfang dieses Threads hab ich doch ein schönes Konzept beschrieben das einfach und zuverlässig funktioniert und mit PIT zwar auskommt aber auch vom HPET profitiert.
Ich will nicht unhöflich sein aber ich habe das Gefühl das Du Dich da in ein unerreichbares Ziel verrannt hast.


Grüße
Erik

[FlashBurn]

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). Genau hier wollte ich ansetzen, 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 nehme ne nsek Auflösung weil es sich damit am einfachsten Rechnet und ich mir nicht alzu große Sorgen über schnelle CPUs (>4GHz) machen muss, ob ich die dann auch erreiche kann und will ich gar nicht garantieren (aber 10µs-Auflösung sollte eigentlich drin sein).

Um genau zu wissen wie viele TSC-Ticks pro IRQ kommen solltest Du das mehrmals messen und zum anderen darfst Du niemals die IRQs abschalten oder andere langwierige (FPU-)Befehle ausführen die in diese Messungen nen Jitter reinbringen könnten ansonsten kannst Du Dir die ns-Aulösung auch gleich ganz sparen.

Ich weiß das meine Messung mit welcher Frequenz der TSC läuft nicht perfekt ist (ich bekomme auf einem AMD K6-200 ca. 197896???Hz), aber ich denke das ich mit der Genauigkeit leben kann. Eigentlich ist alles was genauer als 1ms ist doch schon verdammt gut, gerade auf solch alten System.

Ein weiterer Punkt ist das Du zum umrechnen der TSC-Ticks in Nanosekunden (oder irgendeiner anderen fixen Zeitauflösung) definitiv Gleitkomma-Arithmetik benötigst und selbst dann noch Tricks brauchst um den Jitter beim periodischen TSC auslesen auszugleichen (die einzelnen Taktfrequenzen werden nicht vom selben Quarz erzeugt Du musst also mit minimalen Geschwindigkeitsunterschieden rechnen die möglicherweise erst nach längerer Laufzeit sichtbar werden).

Also was das umrechnen betrifft, da nutze ich im Moment 64bit und halt nsek-Auflösung (oder sogar PSec, da bin ich mir gerade nicht sicher) und das sollte auch ohne Gleitkommazahlen reichen.

Meinst du mit den verschiedenen Taktfrequenzen PIT und TSC? Was den Unterschied betrifft, ich nutze für die langfristige Zeimessung im Endeffekt nur den PIT, daher ist es mir egal wie sehr der TSC und der PIT auseinandertriften! Zumal ich ja immer nur eine Differenz nutze, von daher summiert sich doch ein vorhandener Fehler nicht auf.

Nein, damit kennst Du zwar wieder den aktuellen Wert des schnellen Counters aber seine Zählgeschwindigkeit kennst Du nur wenn Du über mehrere exakt getimmte (also jitterfreie und das dürfte bei normaler SW-Nutzung quasi unmöglich sein) Auslesungen den Counterwert beobachtest und genau diese Zählgeschwindigkeit brauchst Du ja damit Du auch einen Nutzen aus dem schnellen Counter ziehen kannst.

Also in meinem Bootloader berechne/messe ich die Frequenz des TSC mit Hilfe des PITs (in einer Zeit von 110ms wimre). Da passiert außer einer Schleife wo "hlt" (was eventuell stören könnte) ausgeführt wird und dem PIT-Interrupt (wo nur ein Counter inkrementiert wird) nichts.

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.

Ob an den obigen Problemen der ACPI-PMT noch was bessert kann ich nicht sagen, den kenne ich nicht da ich mich nur sehr oberflächlich mit ACPI beschäftigt habe. Kann der ACPI-PMT Interrupts generieren? Zumindest gibt es diesen nur ein mal aber er ist wohl auch wieder über langsame I/O-Ports angebunden und da die Arbeitsfrequenz nur etwa das doppelte der vom PIT ist solltest Du Dir genau überlegen ob der Aufwand sich überhaupt lohnt.

Ich verstehe nicht ganz was du mit Aufwand meinst? Ich meine entweder ich machen nen "_rdtsc()" oder ich mache nen "ind(ACPI_PMT_PORT)".
Unterschiedlich sind nur, dass das Auslesen des PMT länger dauert, aber dafür kann ich ihn einfach und ohne Probleme auf SMP-Systemen verwenden. Ansonsten sind sie mehr oder weniger gleich. Beide machen nicht mehr als einen Counter zur Verfügung zu stellen, nur muss ich den PMT nicht ausmessen, sondern weiß wie lange ein Tick dauert.

Am Anfang dieses Threads hab ich doch ein schönes Konzept beschrieben das einfach und zuverlässig funktioniert und mit PIT zwar auskommt aber auch vom HPET profitiert.
Ich will nicht unhöflich sein aber ich habe das Gefühl das Du Dich da in ein unerreichbares Ziel verrannt hast.

Ich seh das nicht als unhöflich an, ist nur ne Motivation dich mit noch besseren Argumenten von meinem System zu überzeugen
Aber mal ehrlich, ich finde so doll unterscheiden sich die beiden Systeme nicht, dein Intervall ist kürzer (1ms : 55ms/62,5ms). Wenn man es nur so betrachtet ist es, mehr oder weniger, gleich. Ich nutze halt noch ne 2. Quelle um auch Events innerhalb des Intervalls auslösen zu können.

Um nochmal auf die SMP-Systeme zurück zu kommen. Ich weiß jetzt nicht ab wann man davon ausgehen kann das solche Systeme ACPI haben, aber selbst wenn nicht, dann denke ich mal das dort auf keinen Fall die CPU irgendwie runtergetaktet wird. Da ich den TSC beim initialisieren meines Kernels auf allen CPUs synchronisiere sollte es da eigentlich keine Probleme geben (die dürften auf solch alten Systemen auch noch nicht auseinandertriften). Ich möchte meinen das mit dem auseinandertriften ist erstmals so richtig auf AMD K7 SMP-Systemen aufgefallen.

Edit::

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. Die Werte habe ich jetzt jedesmal (ich habe jeweils 3mal getestet) bekommen. Wenn ich an einer Konstante noch ein wenig Pfeile, dann komm ich vielleicht sogar noch genauer hin. Jedenfalls sollte die Genauigkeit meiner TSC-Messung in Ordnung gehen und sie funktioniert bis zu einer Taktfrequenz von 1000GHz!

[Svenska]

Okay, ich wiederhole nochmal, was ich vorher gesagt habe...

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.

Das geschieht bei APM im Auftrag des BIOS, unabhängig vom Betriebssystem - und zerstört dir u.U. den TSC bei frühen Pentiums.

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.

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.

Aber tu, was du nicht lassen kannst.