Nachrichten

781

Lowlevel-Coding / Re: Konzept für periodische Events

« am: 25. April 2010, 17:10 »

Hä? Was willst Du da genau machen? Also ich würde nicht bestimme OS-Kernel-Aufgaben auf bestimmte CPUs festpinnen. Das würde ich auch nicht mit IRQs machen, ein IRQ wird am besten auf der CPU verarbeitet auf welcher gerade der User-Mode-Code mit der niedrigsten Priorität läuft.

Also bei meinem System wird der IRQ Handler immer auf der CPU mit der niedrigsten Prio ausgeführt (Ausnahme sind CPUs im Idle-Zustand).

Ich hab mir das so vorgestellt. Du hast halt den PIT im periodischen Modus mit den magischen 18,2Hz = 55,4ms.
Ein Thread läuft auf CPU0 und möchte für 200ms schlafen, dann ruft er halt sleep(200000000) auf (die Zahl ist so groß, weil ich ns als Basis nehme, da rechnet sich einiges leichter ohne die FPU verwenden zu müssen) und die holt sich den aktuellen Wert des internen PIT Counters (weil ich den vorher von der zu wartenden Zeit abziehen muss) und packe den Thread in die Delta-Queue des PIT-Handlers.
Jedes Mal wenn der PIT den IRQ-Handler aufruft, zieht er 55,4ms von dem 1. Thread in der Delta-Queue ab und wenn die Zeit die da rauskommt kleiner als 55,4ms ist, wird der (und alle Threads für die dies auch noch gilt) in die Sleep Queue der CPU gepackt auf welcher der IRQ-Handler gerade ausgeführt wird.

Ich hätte dann also eine "globale" Sleep-Queue die nur vom PIT bearbeitet wird und auf jeder CPU noch mal eine Sleep-Queue die von der jeweiligen CPU bearbeitet wird.
In der PIT Queue sind alle Threads welche länger als 55,4ms warten wollen und in den CPU Queues sind alle Threads welche weniger als 55,4ms warten wollen.

Damit sollte ich den Jitter klein halten bzw. (mal vom worst-case abgesehen) sollte der sich zumindestens nicht aufaddieren.

Als Alternative würde ich den PIT nicht betrachten, aller höchstens, und nur mit viel Bauchweh, als Notlösung.

Genau das ist er auch (aber war er das nicht von Anfang an ).

Du musst immer mit absoluten Zeiten rechnen. Wenn Dein Programm zum Zeitpunkt 510638ms den ersten Event bekommen hat und der nächste Event 60ms später kommen soll dann muss das eben zum Zeitpunkt 510698ms passieren und darf nicht von der verbrauchten Zeit o.ä. abhängen. Den HPET kann man auch nicht einfach so mal auf einen neuen Zählerwert setzen sondern man kann nur einen neuen absoluten Vergleichswert hinein laden an dem der nächste IRQ generiert wird, genau das habe ich in meinem Ursprungspost beim PIT in Software nach gebaut.

Wenn ich dich richtig verstanden habe, dann meinst du das ich Probleme mit periodischen Events bekommen würde.

Das Problem was ich im Moment mit Events habe ist, ich habe noch gar keine Events auf meinem System Ich rede die ganze Zeit nur von Threads die schlafen gelegt werden. Das andere was ich noch meine ist ne Performance Counter um sagen zu können wieviel Zeit vergangen ist.

Aber, deine Idee mit den Events (um z.B. ein Spiel auf 60FPS zu "eichen") find ich gut, ich weiß halt nur nicht wie ich die umsetzen würde/sollte.

Jetzt so spontan würd ich einfach ne Message an einen vorgegebenen Port senden und der Inhalt wäre halt ne Art ID die sagt, Event ausgelöst.
So dass ich einfach Events in anstatt Threads in eine Queue packe (anstatt der Sleep-Queue im PIT und auf den CPUs) und dann so alles löse.
Die periodischen Events würde ich dann so lösen, das du ne Startzeit (die Zeit bei der der Event eingetragen wurde) nimmst und die Eventzeit draufrechnest und den Event wieder in die PIT-Queue packst und nen "neuen" Event erzeugst mit der Restzeit (kleiner als 55,4ms) und diesen in die CPU Queue packst.

Ich hoffe ich war einigermaßen verständlich, klingt alles ein wenig wirr ich weiß.

Ich würde spontan sagen, das ich ne Semaphore für die Events nutzen könnte (zumindest für das Sleep-Event). Es wird halt ein neues Event erstellt, das einmal feuern soll und in 200ms soll das ganze passieren, der Thread versucht darauf hin die Semaphore zu bekommen (was ja nicht klappt und der wird auf blockierend/wartend gesetzt). Wenn das Event dann feuert, gibt es die Semaphore frei (was den Thread praktisch aufweckt) und "zerstört" sich selbst. Dann hätte ich die Sleep-Funktion über Events gelöst und müsste mir nur noch nen Kopf machen, wie ich das mit anderen Events mache.

Obwohl es gar nicht schlecht wäre das immer über Semaphoren zu machen. Um nochmal das Bsp mit dem Game zu bringen, wenn das Event alle 16ms die Semaphore freigibt und der Thread mal länger brauchen sollte, dann bekommt er die Semaphore ja sofort und kann gleich den nächsten Frame berechnen.

Wenn ich dann noch die Linux Idee von den Futexen nutze, dann kann ich das ganze noch halbwegs effizient im User-Space machen.

Was haltet ihr von der Idee (meine Event Idee und die Sache mit dem PIT)?

Also wenn Dual-Core (nicht Dual-Sockel) vorhanden ist dann sollte auch ein HPET anwesend sein. Auf älteren PCs kannst Du ja den PIT im Periodic-Modus nutzen, dort dürften die CPUs auch nicht so interessante Tiefschlaf-Modi kennen so das dort kein so großes Problem entsteht.

Ich habe hier einige Motherboards mit mehreren CPUs (Slot1, Sockel370, Sockel5/7, SockelA) die keinen HPET haben und die möchte ich ja auch unterstützen!

Du weißt nicht zufällig ab wann ungefähr der HPET auf neuen Boards vertreten war?

Ich hab von dem Ding das erste Mal zu Core2 Zeiten gehört.

782

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 20:37 »

So habs gerade mal getestet. Ich hab das Gefühl das MingW jetzt schneller läuft als noch vorhin. Jetzt hab ich beim kompilieren von meinem OS wieder die selbe Geschwindigkeit (jedenfalls subjektiv) wie gestern noch unter XP. Das einzige was mir aufgefallen ist, dass löschen mit "rm" jetzt mit einmal doch ein ganzes Stückchen schneller ist.

Aber an VMware und VirtualBox muss ich mich früher oder später eh versuchen, wenn ich dann soweit bin, dass das Testen unter Bochs zu langsam wird, aber bisher hab ich auch bei 8 CPUs noch ne vernünftige Geschwindigkeit (es passiert auch einfach noch zu wenig).

783

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 19:45 »

Ich hab einfach mal die zweit neueste Version von MingW drauf gemacht und jetzt läuft es mit aktzeptabler Geschwindigkeit.

Nunja, was den MSVC betrifft hab ich mich zu sehr auf den GCC eingeschossen, da ich ein paar spezifische Erweiterungen nutze.

Mein Laptop wird halt leider auch nicht schneller

Qemu und co müsste ich mir mal anschaueen, aber es müsste schon verdammt viel schneller sein, das es sich lohnt in einer virtuellen Maschine zu entwickeln (was ich jetzt mal nicht glaube, aber ich werds probieren).

Wenn es mir wirklich viel zu langsam sein sollte, muss ich mich halt wieder öfter an den Desktop setzen (nur fällt dann das spontane Proggen flach). Da hab ich dann aber wenigstens genug übersicht bei 1900x1200

784

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 17:31 »

Jetzt ist es passiert, ich hab win 7 und MingW will nicht

Hab zuerst MingW (5.1.6) installiert und dann MSYS (1.0.11) und wenn er das Script zum Schluss ausführen will kommt folgender Fehler:

Code: [Auswählen]

C:\msys\1.0\postinstall>..\bin\sh.exe pi.sh
      0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x70000, State 0x10000
C:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 erro
r 0
Also was kann ich da machen?

Edit::

Habs hinbekommen, indem ich die neueste Version von MSYS runtergeladen habe und einfach selbst das postinstall-script ausgeführt habe. Wieso haben die eigentlich in den neueren Versionen keinen schönen Installer mehr fürs MSYS?

Edit2::

Als hätte ich es geahnt, der Worst-Case ist eingetreten, beide (cygwin + MingW) sind arsch langsam (also so langsam wie cygwin auf meinem Desktop Rechner). Falls keiner mehr einen Tipp hat, dann werd ich wohl oder über morgen wieder WinXP drauf machen

785

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 15:27 »

Erstmal ein Hallo von der neuen HDD von Win7 aus

Würde ich aber trotzdem immer so machen, denn es ist viel einfacher (und eindeutiger) zu schreiben "probier ./foo --bar baz" anstatt "such in der Symbolleiste das Icon mit dem grünen Signifanten und einem Zahnrädchen, wähl im anschließend auftauchenden Fenster für das Feld bar die Option baz aus und klick auf OK".

Ich wahrscheinlich meistens auch, aber der Punkt ist, der durchschnitts User eben nicht.

Und viele Entwicklertools gerade auch für OS-Dev müsste man sich unter Windows erst mühsam zusammenkratzen und anschließend mit Geschwindigkeitsproblemen kämpfen, wie dieser Thread zeigt, (bzw. manche Sachen tun überhaupt nicht, z.B. grub) während sie unter Linux dabei sind und alles ohne größeren Aufwand einfach funktioniert. Neben der Buildumgebung wären Versionskontrollsysteme so ein Punkt, zum Beispiel.

Also ich entwickle gerne und bisher auch sehr "erfolgreich" (in dem Sinne das ich entwickle, was bei rauskommt ist ne ganz andere Geschichte ) unter Windows und jetzt mit MingW auch mit ausreichender Geschwindigkeit.

Also ich nutze bisher die Versionskontrollsysteme (CVS und SVN) nur zum updaten von Projekten (z.B. Bochs) und da funktionieren sie super.

Ich habe auch mal cvs für ein eigenes Projekt von Windows aus genutzt und das hat schon damals super geklappt.

Was ich jetzt nicht weiß ist was du mit grub meinst (den Bootloader)?!

786

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 10:38 »

Wart mal, redest du davon, dass die Leute Konsole und sudo benutzen müssen  oder dass sie es tun?

Schande über mein Haupt, ich weiß es nicht Aber ich weiß wo ich das letzte Mal was für Linux gesucht habe, wie ich was mache, da waren alle Anleitungen nur wie ich es über die Konsole mache und nicht wie ich mich durch die GUI klicke. Letzteres wäre aber viel sinnvoller (wenn vorhanden) um auch neue Nutzer für Linux zu begeistern!

Wenn ich mich an einen Windows-Rechner setzen muss, bekomme ich jedesmal das Grausen, weil die Oberfläche für mich nicht benutzerfreundlich ist. Sie ist für Anfänger gemacht, mit nur wenigen Möglichkeiten, darüber hinauszugehen und mit etwas Kenntnissen Dinge einfacher zu machen. Ich kann damit einfach nicht effizient arbeiten.

Da muss ich dir recht geben, es kommt halt drauf an was man machen will. Ich bin soweit zufrieden, vorallem da ich ja MingW/cygwin habe

Es ist halt einfacher (oder besser nur möglich) bestimmte Sachen unter Windows zu machen, die eigentlich von Linux kommen, als umgekehrt (bestes Bsp. Spiele).

Mich würde ja mal ein Bsp. interessieren was du so machst, was unter Windows so nicht möglich ist (und wenn ich eins hasse dann sind es immer die Bsp. die Shell von Windows kann das und das nicht, dafür gibts in Linux auch unterschiedliche Shells und auch die benutzen dann halt andere Programme, der Vorteil bei Linux ist, die Programme sind schon standardmäßig dabei und müssen nicht noch irgendwoher installiert werden!) und was vielleicht halbwegs Alltags tauglich ist, meinetwegen auch etwas was OS Progging betrifft.

Edit::

Was meint ihr nun lohnt sich für den Laptop mit 2GB RAM die x64 Version oder nicht?

787

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 09:24 »

Du brauchst sudo auf der Konsole, um Dinge zu tun, die unter Windows gar nicht gehen? Ich glaube du hast mich überzeugt, Linux ist Mist.

Da hast du mich jetzt falsch verstanden. Ich meinte jetzt nicht mal das nachgucken wegen meinem USB Problem (war glaub ich irgendetwas wegen dem W-Lan, weil ich ja Internet brauchte um mich zu informieren wie das unter Linux geht), aber wenn ich mir angucke wie oft die Leute zu sudo greifen und die machen außer Einstellungen ändern und programmieren auch nichts groß unter Ubuntu.

Richtig, subjektiv und objektiv macht eben doch manchmal einen Unterschied. Und genau dasselbe Problem diagnostiziere ich bei dir in Hinsicht auf Betriebssysteme. Wink

Bei einer Sache muss ich dir da Recht geben und das ist die Ordnerstruktur unter POSIX Systemen. Damit komm ich gar nicht klar

Mein (und damit meine ich wirklich mein und nicht für jeden) lieblings Bsp. für ein "zugängliches" OS, ist immernoch BeOS. Hat zwar leider auch die POSIX Ordnerstruktur, aber ansonsten war ich damit voll zufrieden, vorallem damals mit der Geschwindigkeit. Die GUI spricht mich heute noch an.

Und was dieses subjektive betrifft, das trifft doch fairerweise auf beide "Lager" zu, oder!? Ich meine die Linuxfreunde behalten Windows wegen den BSOD von damals in Erinnerung und ich weil Linux damals einfach unzugänglich und kompliziert war. Ich habe mir damals Linux auch nur angeguckt, weil es cool war (und habe es dann wegen zu vieler Probleme aufgegeben). Das selbe passiert heute mit dem Appel-Hype. Denn viel mehr ist es aus meiner Sicht nicht.

Um nochmal auf das böse "sudo" zurück zu kommen. Unter Windows nervt es mich auch, das ständige klicken "sind sie sich sicher", einfach nur zum Kotzen, aber wenigstens nicht auf der Konsole.

Ich denke wir können beide damit leben wenn wir sagen, weder Linux noch Windows sind die Eierlegendewollmilchsau

788

Lowlevel-Coding / Re: Konzept für periodische Events

« am: 24. April 2010, 08:52 »

Nur mal dazwischen geschoben, die kleinste Freqeunz die der PIT kann sind 18,2Hz und das sind 54,5ms (Pi mal Daumen ).

Ich überlege schon, den PIT für´s "Grobe" zu nehmen und wenn dann die Zeit zum Warten kleiner 54,5ms ist, dann wird der Thread halt in die Sleep-Queue der CPU gepackt auf dem der PIT IRQ Handler gerade läuft. Damit sollte dann auch der Jitter der Entsteht egal sein. Was haltet ihr von der Variante?
Das einzige Problem damit wäre dann das Reinpacken eines Threads in die PIT-Sleep-Queue. Denn ich müsste den Thread zw. 2 PIT-IRQs reinpacken und dazu müsste ich diesen auslesen, was wiederum nen Jitter von 3*832ns erzeugt und das jedes Mal wenn ich nen Thread reinpacke.

789

Softwareentwicklung / Re: Cygwin unter Win7

« am: 24. April 2010, 08:44 »

Ich habe auch mal Ubuntu "genutzt", weil etwas wofür Linux wirklich gut ist, ist Hardwareprobleme finden! Ich meine Meldungen die ich unter Linux bekomme, wird es bei Windows wahrscheinlich nicht mal für die Entwickler geben (ich musste damals verifizieren das USB auf meinem Mainboard im Arsch ist und nur noch 1.1 fährt und dafür war Linux perfekt).
Ich weiß nicht mehr wieso, aber ich brauchte "sudo" und ganz ehrlich, für ein OS was auch für "allgemeine" User sein soll ist die Konsole ein absolutes NoGo! Meine Freundin z.B. ist eigentlich ganz fit mit dem PC, sie kann auch das ein oder andere Treiberproblem oder sonstige Problem lösen, aber sie weiß nicht mal was eine Konsole ist und wenn man dann für bestimmte Sachen ne Konsole braucht, hast du die alle verloren!

Auch Windows ist nicht perfekt, aber da es nunmal mehr genutzt wird, gibt es halt mehr Treiber und alles läuft "meistens" ein wenig runder bzw. ist einfacher zu erledigen (ich erinnere mich immer wieder gerne daran, wenn Studenten im 1. Semester Informatik meinen sie sind cool weil sie Linux nutzen und wollen dann ihren Laptop an den Beamer anschließen und es funktioniert nicht, obwohl das auch unter Windows manchmal ein ganz schöner Akt ist ).

Warum wird fork()/exec() genutzt... nun, was ist denn der Sinn von Threads? Ein gemeinsamer Adressraum, damit man den Adressraum beim Neuerzeugen von Prozessen nicht komplett aus dem Nichts erzeugen muss - also sind Threads nur beschränkte Prozesse, damit sie schneller starten.

Und ich dachte immer, damit man wenn man Code hat der parallel laufen kann, sich den ganzen Kommunikationsaufwand sparen kann. Denn der große Nachteil ist doch, das mit dem Ändern des PageDirs auch der TLB gelöscht wird und das kostet halt auch Performance.

@Off-Topic

Noch mal zu so´ner Oma. Ich habe bei mir im Bekanntenkreis nun auch mal wieder erleben dürfen wie stur der durchschnitts User sein kann. Eine Bekannte nutzt auf Arbeit Office XP und auf ihrem neuen Laptop ist halt noch kein Office drauf. Anstatt OpenOffice zu nehmen und Geld zu sparen, muss sie sich unbedingt Office 2010 kaufen und das obwohl ich ihr gesagt habe das sie sich da auch neu einarbeiten muss. "Nein, das was ich machen will funktioniert mit dem Ding nicht", sagt sie ohne es auch mal benutzt zu haben! Da kann ich auch nur den Kopf schütteln, vorallem geizig ohne Ende aber Geld für Office ausgeben nur weil sie halt stur ist.

@taljeth

Hat mit meinem Windows "Vorwissen" nicht so viel zu tun, aber wie gesagt, der Zwang bei bestimmten Sachen (ich weiß jetzt nicht welche es sind, aber halt "sudo") sind ein absolutes NoGo!

790

Softwareentwicklung / Re: Cygwin unter Win7

« am: 23. April 2010, 23:17 »

Von der verlang ich das auch nicht, aber die möchte erstens keine Programme benutzen, die so wenig verwendet werden, dass die Distribution nicht selbst fertige Pakete bereitstellt und zweitens verlang ich von der auch gar nicht, dass sie Linux verwenden soll. Du bist aber keine Oma, die Kochrezepte im Internet sucht. Deshalb hinkt der Vergleich ganz leicht. wink

Also darauf muss ich sagen, 1. du sagst nicht wirklich das ich unrecht habe mit den verschiedenen Distros (nur das die das gefälligst selber zur Verfügung stellen sollen, aber die können doch nicht jedes x-beliebige Programm im Angebot haben) und 2. dann sollen doch bitte endlich mal alle zugeben, das Linux eben nicht Einsteiger-freundlich ist. Man muss schon ganz schön was auf dem Kasten haben um mit Linux leben zu können. Und auch ich als Programmierer bin faul

@all

Mensch GCC ist fast durch und das ist ja nochmal schneller als mit cygwin, dann brauch ich mich damit auch nicht mehr rumquählen und die Shell sieht inzwischen auch genauso aus

791

Softwareentwicklung / Re: Cygwin unter Win7

« am: 23. April 2010, 22:55 »

So bin gerade dabei GCC 4.5.0 unter MingW zu kompilieren.

Dann wäre da nur noch eine Frage, lohnt es sich auf nem Laptop mit nem T7200 und 2GB RAM Win7 x64 drauf zu packen oder mache ich mir da wieder das Leben mit MingW schwer?

792

Lowlevel-Coding / Re: Konzept für periodische Events

« am: 23. April 2010, 22:25 »

Es gibt ein paar CPUs bei welchen der TSC "holprig" läuft aber das trifft nur die untersten Bits und auf lange Sicht läuft auch dort der TSC genau mit der richtigen Frequenz, er eignet sich dort nur leider nicht für ganze kurze Timings (um z.B. den Taktbedarf einer kurzen Befehlsfolge zu messen).

Problem ist halt das der TSC mit der Frequenz der CPU zusammen hängt und wenn die sich ändert (wo ich halt davon ausgegangen bin, dass das auf Laptops z.B. automatisch geht) dann ändern sich auch die Rate mit der der TSC aktualisiert wird. Ganz schlecht zum Timen.

Die nutzen den Takt der Sound-Karte, diese "verbraucht" die Audiodaten ja mit einer bestimmten Datenrate (den aktuellen Lese-Pointer bekommt man wimre über das Sound-API vom OS welches diese Info vom Treiber holt) und genau darauf synchronisieren sich solche Programme meistens.

Das hört sich doch gut an, klingt jedenfalls so, als wenn ich mir darüber so schnell keinen Kopf machen brauche. Aber was ist mit "Videos" die ohne Sound laufen bzw wo keine Soundkarte vorhanden ist. Gibt es da ne Art Backup-Methode oder laufen die dann aus dem Ruder?

Du schreibst immer von APIC, erkläre doch mal genauer was Du damit meinst. Es gibt da einen oder mehrere I/O-APICs mit denen man nichts timen kann und dann hat jeder CPU-Thread (bei Hyper-Threading) seinen eigenen Local-APIC welcher zwar einen Timer anthält der aber wimre nur der lokalen CPU Interrupts schicken kann. Den Timer im Local-APIC würde ich nur für die Zeitscheiben benutzten, dafür wurde er auch gebaut. Für Timing-Events die nicht einer bestimmten CPU zuzuordnen sind, dazu gehören periodische Events und auch alle anderen User-Mode-Timings, gibt es den HPET.

Ich meinte halt immer den Local-APIC-Timer (ich dachte das wäre klar, wenn wir von Timern reden ).

Bei mir läuft das im Moment auf SMP Systemen so. Ein Thread sagt er will so und so lange schlafen. Daraufhin kommt er in the Sleep-Queue der CPU auf der er gerade Läuft (ist ne Delta-Queue).

Also gehen wir mal davon aus die Sleep-Queue ist leer. Der Scheduler wird das 1. Mal aufgerufen, wählt nen Thread aus, der darf 60ms laufen, also wird der APIC-Timer auf 60ms gestellt, ich setze dann ne Variable "timerStart" auf 60ms. Wenn der Scheduler das nächste Mal aufgerufen wird, dann liest er als erstes den aktuellen Wert des APIC-Counters aus (bzw. bekommt er ne "Restzeit" zurück) welche von der Variable "timerStart" abgezogen wird, so habe ich die genaue Zeit die der Thread gelaufen ist. Diese ziehe ich von der Zeit vom aktuellen Thread ab und diese ziehe ich vom 1. Thread in der Sleep-Queue ab (wenn denn einer vorhanden ist). Gleichzeitig wird ne Variable "sleepNext" auf die Zeit gesetzt, wenn der nächste Thread aufgeweckt werden soll.
Der Scheduler guckt jetzt ob der aktuelle Thread seine Zeit verbraucht hat oder abgeben will oder ob ein Thread mit höherer Prio bereit ist. Ist irgendetwas davon der Fall wird der Thread in die Run-Queue gepackt und ein neuer Thread wird rausgesucht (aus der Ready-Queue).
Jetzt wird geguckt, was näher (zeitlich gesehen) ist, die Zeit bis zum nächsten Thread der aufgeweckt werden soll oder die Zeit bis der neue Thread seine Zeit aufgebraucht hat.
Diese Zeit wird dann dem APIC-Timer übergeben und der neue Thread darf laufen.

Der "Fehler" in diesem System ist die Zeit zwischen dem Eintritt in den Scheduler und dem Abgeben an den neuen Thread. Dieser "Jitter" summiert sich leider mit der Zeit ziemlich tolle auf. Im Moment braucht mein Scheduler im Worst-Case so ca. 1500ns auf nem K6-3 400MHz (hatte ich mal ausgemesen).

Ich nehme an Du kannst Dir selber denken wie ich darauf antworten würde. Wink

Ja, wäre nur nicht sonderlich hilfreich

Auf nem SMP System (was auch DualCores mit einschließt) habe ich nunmal außer dem PIT nichts brauchbares (für ne absolute Zeitquelle, denn die APIC-Timer sind leider dafür nicht zu gebrauchen)

Zum unterscheiden zwischen Kernel-Mode und User-Mode kann man beim Eintritt und Austritt zum/vom Kernel-Mode immer den Timer-Wert auslesen und die so gemessenen/errechneten Zeiten dem entsprechenden Interrupt zuordnen und vom Zeitscheibenverbrauch des User-Mode-Threads abziehen (außer bei SYSCALLs natürlich, die ordnet man zwar dem Thread zu aber als Kernel-Mode-Zeit).

Würde ich auch so machen. Im Moment weiß ich aber noch nicht wofür ich das gebrauchen könnte, zumal da wieder das nette Problem kommt. Mein OS läuft auch auf PIT-only Systemen und das Auslesen alleine kostet schon Zeit (3*832ns).
Linux macht das zwar auch so, aber naja. Ich hatte mir den Source mal angeguckt und die haben ja auch Code für PIT-only Systeme und die machen das da genau wie ich (und ich habe noch gelernt, das man den PIT nicht ständig neu initialisieren muss wenn man nen neuen Wert reinschreibt und zwischen durch nur ausliest).

793

Softwareentwicklung / Re: Cygwin unter Win7

« am: 23. April 2010, 20:15 »

Ich weiß nicht, was deine Strukturen machen sollen, aaaber wie wärs hiermit:

Dann verstehe ich es nicht wieso man immer zw. verschiedenen Distros wählen muss, wenn man was runterläd.

Zweitens kann ich immer den Quellcode verteilen, dieser sollte auf jedem System kompilierbar sein und sich dabei an die dortigen Gegebenheiten anpassen.

Ähm, ich bin zwar nicht ganz unfit was Linux betrifft, aber hallo. Ich meine du Kannst nicht von irgend einer Oma, die gerade den PC soweit bedienen kann das sie weiß wie sie Kochrezepte im Internet findet, verlangen dass sie weiß wie man Programme kompiliert! Dann kommen noch die ganzen Dependencies dazu, die müssen auch erstmal aufgelöst (also verschiedene Libraries besorgt) werden. Von Treiberinstallation (ich weiß nicht ob man die Treiber von ATI und nVidia immernoch kompilieren muss, damit sie auf dem System laufen) will ich gar nicht erst anfangen. Dann kommt noch hinzu das Linux noch immer zu Konsolenlastig ist, aber ich schweife schon wieder ab.

Um die Sache mal zu beenden, jedem das seine und ich will kein Linux.

Die Situation hat sich schon vor einiger Zeit gebessert.

Na dann werd ich das doch gleich mal ausprobieren, hab MingW hier auch drauf, weil Bochs sich damit besser kompilieren lässt.

794

Softwareentwicklung / Re: Cygwin unter Win7

« am: 23. April 2010, 18:09 »

insofern kann ich deine Argumente nich verstehen.

Ich meine damit, das wenn du ein Programm verteilen willst, eine Version für die Distro, eine für die Oberfläche und das selbe mit den Treibern.

Die müssten sich halt alle mal auf einen Standard einigen, dann wäre das alles net so schlimm.

Aber lieber wieder back to topic ... Ich will halt kein Linux und muss daher damit leben, das cygwin nicht so schnell ist und eventuell weiterhin mit XP arbeiten.

795

Softwareentwicklung / Re: Cygwin unter Win7

« am: 23. April 2010, 16:48 »

... aber zu Mails kann ich nur sagen, dass Linux eine GUI (bzw. mehrere) hat und auch volle TCP/IP-Unterstützung (sowie von HTTP, POP3, SMTP, ...). Es soll auch Webbrowser und E-Mail-Clienten geben. wink

Ja, genau wegen dem Mail-Clienten müsste ich ja wechseln. Ich weiß nicht in wie fern Thunderbird und FireFox aus Linux mit den Daten aus Windows klarkommen und selbst wenn dann müssten beide auf die selben Daten zugreifen und ich denke mal dass das nicht möglich ist.

Was ich als größten Nachteil von Linux zähle sind die ganzen Distributionen. Wenn ich schon ein OS habe was so toll sein soll, dann will ich nicht für jede Distribution nen extra Download haben und dann gibts ja noch unterschiedliche GUIs und unterschiedliche WindowManager. Das ist mir insgesamt zu viel. Da mag ich viel lieber das gute alte BeOS, das habe sogar ich von Anfang an verstanden

796

Softwareentwicklung / Re: Cygwin unter Win7

« am: 23. April 2010, 16:32 »

warum also nicht parallel ein Linux (oder BSD oder...) zum Entwickeln installieren?

Naja, ich stell mir das so vor, gut habe Lust was zu proggen, dauert 30mins, ah Mails nachgucken, umbooten, Mails nachgeguckt war nichts, wieder umbooten, dann weitere 30mins proggen, ach keine Lust mehr, spiele ich mal wieder was, umbooten, während des Spielens fällt mir mit einmal die Lösung für das Proggproblem ein (das ist leider immer so ), wieder umbooten.

Also das ist nicht wirklich eine Lösung für mich. Außerdem mag ich Linux nicht wirklich (auch wenn ich die tools gerne nutze ).

Mit Win7 hat das aber nichts zu tun, bei mir läufts auf jeden Fall auf XP Home und Win7 x64 genauso schnell.

Tja, bei mir ist das aber anders. Ich meine ich vergleiche hier nen Laptop mit 2GHz DualCore mit dem Desktop Rechner 3.4GHz QuadCore und der Desktoprechner ist so arsch langsam, da könnt ich in der Zeit das Makefile auch selber eintippen, nachdem ich alles mit Hand getestet habe, was das Configurescript so macht

Da unter Linux Prozesse mit fork()/exec() gestartet werden ...

Das versteh ich bis heute nicht, warum die das so machen und warum das so toll sein soll. Im Endeffekt ist das doch wie Threads die als Prozesse ausgeführt werden. In meinem (unerfahrenen und nicht erleuchteten Augen ) totaler Schwachsinn. Aber ich lasse mich auch hier gerne eines besseren belehren.

Also ist mein Fazit bisher, einfach ausprobieren und wenn Cygwin dann wieder so langsam ist, einfach XP behalten.

Ich guck mal nebenbei noch ob coLinux was für mich wär. Ich brauche ja ansich nur binutils, gcc, sed, grep, make und ne bash shell. Bei MingW hab ich das mit dem gcc kompilieren nicht hinbekommen (aber das letzte Mal hab ich das auch vor Jahren probiert).

797

Lowlevel-Coding / Re: Konzept für periodische Events

« am: 23. April 2010, 16:22 »

So wie du es beschreibst, gibt es keine Universallösung.

Das ist das "schöne" an der x86 Architektur

Das einzigste ist, ich kenn mich. Wenn ich jetzt davon ausgehe, das sich die Frequenz des TSC nicht ändert und dann mal in 2 oder noch mehr Jahren ACPI und das Runtertakten unterstütze. Dann kann ich wieder stundenland nach dem Fehler suchen, warum mit einmal alles aus dem Ruder läuft, da ich ja vergessen habe, das ich angenomme habe, das der TSC konstant ist

Mich würde jetzt mal interessieren, wie das z.B. Sound und Video Apps machen, das Sound und Video synchron bleiben. Ich meine das funktioniert ja auch auf allen PCs und bei Spielen scheint es ja auch zu klappen.

798

Softwareentwicklung / Cygwin unter Win7

« am: 23. April 2010, 14:23 »

Ich bekomme morgen oder Montag ne Festplatte und wollte dann eigentlich Win7 auf meinem Laptop installieren (momentan noch XP).

Da ich aber eigentlich nur am Laptop programmieren, muss Cygwin funktionieren. Ich habe auf meinem Desktop Rechner Win7 x64 und da läuft Cygwin nicht wirklich, d.h. es läuft, aber arsch langsam. Ich meine ich brauche dort (mit nem Q9550 auf 3.4GHz) alleine für das Configure-Script von den binutils so lange wie auf meinem Laptop (mit nem T7200-Merom) für das Kompilieren von binutils+gcc!

Von daher wäre es nicht schlecht zu wissen ob jemand Cygwin auf Win7 erfolgreich betreibt!?

799

Lowlevel-Coding / Re: Konzept für periodische Events

« am: 23. April 2010, 14:18 »

Was den TSC angeht, kannst du den durchaus verwenden. Da du als Betriebssystem selbst die Herrschaft über die Taktfrequenz hast, kannst du die natürlich auch berücksichtigen (und sei es, indem du bei niedrigerem Takt auf die TSC-Werte einen Faktor draufmultiplizierst).

Ist dem so? Ich war immer der Meinung, zumindest auf Intel CPUs, dass das ganz automatisch passiert.
Ich vermute mal das wird im SMM gemacht und da komme ich als OS ja nicht rein.
Wenn es nicht automatisch passiert, wieso braucht man dann bei AMD nen Treiber für die dynamische Taktung und bei Intel nicht? (Ich frage weil ich es nicht weiß)

Du kannst für genauere Ereignisse den One-Shot-Modus zusätzlich benutzen (gibt ja mehrere getrennte Timer).

Nicht wirklich. Einer ist für den Speaker da und der andere ware mal in Benutzung (DRAM Refresh glaub ich).

Naja, sobald man den APIC nutzen kann, hat man die ganzen Probleme nicht mehr, aber ich will halt auch mit dem PIT ein halbwegs vernünftiges Ergebnis bekommen.

Wenn du mir jetzt allerdings ne Quelle (also ne technische Doku) geben kannst, wo drin steht das solange ich nichts machen, die CPU sich auch nicht runtertaktet. Dann kann ich ganz einfach den TSC als Counter nehmen (auch beim APIC).

Mein großes Problem ist halt, das die meisten Programme (z.b. Spiele) so geschrieben sind, das sie sich den Wert eines Counters (high precision counter) holen, dann ihre Aufgabe erledigen, wieder den Wert des Counters holen und anhand der Differenz wissen wie lange sie noch warten müssen. Das ganze wäre auch nicht so schwierig, wenn die TSCs konstant wären und auf SMP System nicht von einander "weglaufen" würden. So muss ich den PIT als Zeitbasis nehmen (da er die einzige Konstante in einem SMP System ist, auf die du dich verlassen kannst und die einen Counter hat). So bekomme ich immerhin ne Counter mit ner Präzision die halbwegs in Ordnung ist.

Ich bin aber gerne offen für andere Vorschläge, wie man nen konstanten hoch präzisen Counter auf nem SMP System (ohne HPET!!!) umsetzen kann.

800

Lowlevel-Coding / Re: Konzept für periodische Events

« am: 23. April 2010, 08:17 »

Da hast du Recht, aber dafür ist der PIT ja auch garnicht da...

Dem halte ich wieder entgegen, was machst du wenn du nur den PIT hast? Die RTC kannst du knicken, ich weiß nicht mal ob die nen One-Shot-Modus hätte und ansonsten kann die auch nur 2er-Potenzen an Frequenzen.

Da fällt mir doch glatt ein Bsp ein, wo ich dran gescheitert bin mit einem periodischem Timer.
Ein Thread gibt ab und zwar irgendwo zw. 2 PIT Interrupts. Wie wollt ihr da sichern das der neue Thread auch wirklich seine Zeit verbraten darf, die ihm zusteht? Wie wollt ihr dann ausrechnen wie lange der Thread gelaufen ist (was ein generelles Problem ist und erstmal rein gar nichts mit dem periodischem Timer zu tun hat) oder wie lange er im Kernel oder im Userspace war?

Eine Lösung wäre jetzt, da wo man nur den PIT hat, sollte man den TSC nutzen können (obwohl ich mir da auf Laptop CPUs nicht sicher bin, wenn die sich runter takten wird ja die TSC Frequenz geändert) und wenn ihr nen APIC habt, reicht der dafür vollkommen aus.

Ich überlege schon die ganze Zeit wie ich die Zeit. die durch das Lesen/Schreiben des PITs entsteht, in meine Zeit Berechnungen mit einbeziehen kann. Das einzigste was dann noch nen Jitter verursacht ist die Zeit die mein Scheduler verbrät, wenn er nen neuen Thread aussucht.