Das stimmt, aber spannend dürfte die Realtime-Unterstützung nur da sein wo sie auch gebraucht wird (im Industrie-/Steuerungsbereich). Auf dem Desktop kann man damit nicht viel anfangen.
Also ich hätte nix gegen einen Realtime-Desktop. Das wären glorreiche Zeiten...Drag&Drop funktioniert immer, kein Warten mehr, wenn man ein Menü haben will... *träum*
Das ist ein Missverständnis. Die meisten glauben Echtzeit wäre gleichbed. mit "wahnnsinnig schnell". Das ist es nicht. Es werden nur Antwortzeiten für best. Vorgänge garantiert.
Wieso Missverständniss, man kann auch die Interaktion mit einem Desktop unter Echtzeitpriorität ausführen lassen. Das geht zwar unter Gnome im wesentlichen nicht dank der Glib mainloops, aber bei einem Desktop mit massivem Multithreading ginge das.
In der Enterprise und im Office nutzen wir das highgeratete Linux, durch die top performance ist der Point of investment return sehr speedy erreicht. Durch die Option den Workspace perfect zu customizen, erzielen wir unbelievable intangible assets.
Das es insgesamt schneller wird wenn man den Kindprozess nicht direkt nach dem Erzeugen durch fork laufen laesst, stimmt so nicht. Nur die parallelitaet wird in den meisten Faellen erhoeht. Im Falle von
while (1) { if (fork()) { calculation_with_blocking_io(); } }
Waere es eher suboptimal. Es wurde aber festgestellt, dass viele Sachen wie make oder Server mit Sockets genau anders herum funktionieren. Hier gibt es einen Vaterprozess, der viele Kindprozesse erzeugt, die dann blockierende IO bei der vorher noch Berechnungen gemacht werdenhaben. Wenn nun der Vaterprozess ersteinmal viele Kinder erzeugen kann ohne vorher vom Scheduler vom CPU gerissen zu werden, dann koennen die Kinder parallel laufen und im Falle von zu wenigen Cores deren Berechnungen und blockierende IO einfach interleaved werden. Besonders beim parallelen make merkt man diese Aenderung oder wenn man einen Webserver mit vielen neu eroeffneten Verbindungen hat (und der Webserver beim Verbindungsaufbau neue Kindprozesse erzeugt).
wie weit wäre linux, wenn die industrie usw. es genauso gut unterstützen würde( zb treiber usw.) wie windows? stattdessen legt man ständig irgenwelche steine in den weg.
Von Sheriff Donnerknall am Do, 3. Dezember 2009 um 14:47 #
Ja, sehr schlauer Kommentar.... Schau mal in die Liste, wer wieviel Code zu Linux beträgt. Der allergrößte Teil kommt von Firmen. Studenten und Freizeitentwickler sind mit ihren Beiträgen absolut in der Minderheit. Es mag sein, dass einzelne Firmen die Unterstützung für Linux nicht so bieten, wie sie könnten oder sollten. Aber daraus eine allgemeine Vernachlässigung durch "die Industrie" zu konstruieren ist völlig an der Realität vorbei.
Genau. Und ausserdem laeuft ja meistens alles was desktoptechnisch da ist - OK, die Grafikkarten-treiber sind manchmal Mist, aber Linux ist ja leider nicht vorne im Spielemarkt. Wifi ist auch noch scheisse. Aber das meiste geht doch. Wir haben viel erreicht.
Das ein Gerät so mir nicht dir nicht läuft, ok. Das hat es auch vorher schon gegeben.
Das wirklich erstaunliche: Der Verkäufer wusste, was Linux überhaupt ist. (Sofern er nicht einfach so "jaja" gesagt hat, ohne es überhaupt zu wissen. Solls ja auch geben) _DAS_ sah vor ein paar Jahren definitiv anders aus!
Besteht das Problem der Speicherreservierung für Peripheriegeräte wie z.B. Soundkarten bei einem 64 Bit Kernel immer noch oder wurde das inzwischen behoben?
In Kernel 2.6.28 war dieses Problem nämlich noch vorhanden.
Eine Soundkarte wie z.B. die Audigy 2 von Creative Labs hat nämlich nur eine Verbindung zum Rechner über eine 31 Bit große Datenleitung, das letzte Bit bei 32 Bit wird nicht verwendet. Das führt dazu, daß sie nur auf den Speicher unterhalb von 2 GB zugreifen kann, was z.B. notwendig ist, wenn Soundfont Dateien für den Synthesizer geladen werden sollen. Bei einem reinen 32 Bit Kernel führt dies in der Regel zu keinerlei Probleme, da immer der Speicher unter 2 GB für die Hardware verwendet wurde, worauf die Audigy 2 ja zugreifen kann.
Bei einem 64 Bit Kernel gilt dies nicht mehr. Hier kann es passieren, daß bei einer Speicherreservierungsanfrage Speicher oberhalb von 2 GB für die Karte reserviert wird, da sie aber nicht darauf zugreifen kann, führt dies zu einem Fehler und die Soundfontdatei kann nicht geladen werden, der Syntheizer bleibt tot bzw. ohne Töne.
Zwar kann man das Problem zwar durch eine Änderung im Quellcode des Kernels und eine Neukompilierung von diesem beheben, aber da man dadurch ständig seinen Kernel selber backen muß ist das auf Dauer keine Lösung.
Daher war im Gespräch dieses Problem durch eine optional nutzbare Kerneloption zu lösen. Hat sich hier in letzter Zeit etwas getan? Es wäre toll, wenn ein Kernelentwickler hierzu mal Stellung geben oder auf der Mailingliste nachfragen könnte.
Unter Ubuntu 9.04 war die Audigy 2 mit einem 64 Bit System jedenfalls deswegen nur eingeschränkt nutzbar, ob es sich bei Ubuntu 9.10 mit aktuellerem 64 Bit Kernel gebessert hat, weiß ich nicht. Auf 32 Bit kernel tritt dieses Problem übrigens nicht auf.
Der 64bit Kernel unterstuetzt Speicherreservierung fuer "dumme" Devices mit limitiertem Addressraum, wie deine Soundkarte, allerdings muss der Treiber das explizit machen. Fuer 31bit wird es etwas schwierig, da muss der Speicher dann in die 16MB ISA Zone passen (normal sind die Stufen 16MB, 4GB, unendlich), sollte aber immer noch gehen.
An sich sollte der Treiber das auch unterstuetzen, aber warscheinlich ist irgendwas kaputt. Am besten du schreibst einen Bugreport and die entsprechenden Entwickler.
> Fuer 31bit wird > es etwas schwierig, da muss der Speicher dann in die 16MB ISA Zone passen (normal > sind die Stufen 16MB, 4GB, unendlich), sollte aber immer noch gehen.
Hm, das könnte ein Problem sein, denn so eine typische gute Soundfontdatei paßt nicht in einen Speicherbereich von nur 16 MB. Meine Soundfontdateien die ich hier nutze sind ca. 128 - 256 MB groß.
Kann man mehrere 16 MB Zonen eventuell verketten?
> An sich sollte der Treiber das auch unterstuetzen, aber warscheinlich ist irgendwas kaputt.
Der verwendete Treiber ist der emu10k1 bzw. snd_emu10k1_synth (für den Synthesizer)
Eine alternative waere noch beim booten entsprechenden Speicher zu reservieren, dafuer braucht man aber einen speziellen Kernelpatch.
Oder wenn du ein System mit IOMMU benutzt (zB Intel VT-d) kann die IOMMU das unmappen. Muss aber auch vom Treiber richtig unterstuetzt werden und die IOMMU muss explizit an sein im BIOS und im Kernel. IOMMU braucht wohl auch einen relativ neuen Kernel.
gestutzt, verwirrt, sprachlos...
> Ganz korrekt ist die Aussage streng genommen jedoch nicht, denn das virtuelle Dateisystem devtmpfs kam neu hinzu.
erleichtert...
Realtime wird die wohl spannendste Erweiterung sein die bald komplett Einzug halten wird.
Auf dem "Standard-Desktop vielleicht nicht, aber Realtime-Fähigkeiten sind für Musiker genauso wichtig wie für die Industrie.
Musikern kommt es "nur" auf allgemein niedrige Latenzzeiten und garantierte maximale Reaktionszeiten an.
[/Klugscheißmodus]
Die meisten glauben Echtzeit wäre gleichbed. mit "wahnnsinnig schnell". Das ist es nicht. Es werden nur Antwortzeiten für best. Vorgänge garantiert.
Muss es nicht "gehighrated" heißen?
>
>Muss es nicht "gehighrated" heißen?
Nein, es heißt ja auch "downgeloaded".
Nur Winzigweich verwendet "gedownloadet" (brrrr).
Ja, wir Deutschen sind schon furchtbar doof.
while (1) {
if (fork()) {
calculation_with_blocking_io();
}
}
Waere es eher suboptimal. Es wurde aber festgestellt, dass viele Sachen wie make oder Server mit Sockets genau anders herum funktionieren. Hier gibt es einen Vaterprozess, der viele Kindprozesse erzeugt, die dann blockierende IO bei der vorher noch Berechnungen gemacht werdenhaben. Wenn nun der Vaterprozess ersteinmal viele Kinder erzeugen kann ohne vorher vom Scheduler vom CPU gerissen zu werden, dann koennen die Kinder parallel laufen und im Falle von zu wenigen Cores deren Berechnungen und blockierende IO einfach interleaved werden. Besonders beim parallelen make merkt man diese Aenderung oder wenn man einen Webserver mit vielen neu eroeffneten Verbindungen hat (und der Webserver beim Verbindungsaufbau neue Kindprozesse erzeugt).
Es mag sein, dass einzelne Firmen die Unterstützung für Linux nicht so bieten, wie sie könnten oder sollten. Aber daraus eine allgemeine Vernachlässigung durch "die Industrie" zu konstruieren ist völlig an der Realität vorbei.
Neulich beim Druckerkauf im Pro-Markt:
Ich:"Bietet der Hersteller für dieses Multifunktionsgerät eine Linuxunterstützung an?"
Verkäufer:"Ja, das läuft problemlos unter Linux!"
Ich schaue überrascht und kaufe das Gerät. Der Verkäufer hatte nicht gelogen!
http://de.software.canon-europe.com/software/0031329.asp?model=
Vor ein paar Jahren hätte das noch anders ausgesehen.
Das wirklich erstaunliche: Der Verkäufer wusste, was Linux überhaupt ist. (Sofern er nicht einfach so "jaja" gesagt hat, ohne es überhaupt zu wissen. Solls ja auch geben) _DAS_ sah vor ein paar Jahren definitiv anders aus!
Bei Canon-Druckern aber sehr selten.
oder wurde das inzwischen behoben?
In Kernel 2.6.28 war dieses Problem nämlich noch vorhanden.
Eine Soundkarte wie z.B. die Audigy 2 von Creative Labs hat nämlich nur eine Verbindung zum Rechner über eine 31 Bit große Datenleitung,
das letzte Bit bei 32 Bit wird nicht verwendet.
Das führt dazu, daß sie nur auf den Speicher unterhalb von 2 GB zugreifen kann, was z.B. notwendig ist, wenn Soundfont Dateien für den Synthesizer geladen werden sollen.
Bei einem reinen 32 Bit Kernel führt dies in der Regel zu keinerlei Probleme, da immer der Speicher unter 2 GB für die Hardware verwendet wurde, worauf die Audigy 2 ja zugreifen kann.
Bei einem 64 Bit Kernel gilt dies nicht mehr. Hier kann es passieren, daß bei einer Speicherreservierungsanfrage Speicher oberhalb von 2 GB für die Karte reserviert wird,
da sie aber nicht darauf zugreifen kann, führt dies zu einem Fehler und die Soundfontdatei kann nicht geladen werden, der Syntheizer bleibt tot bzw. ohne Töne.
Zwar kann man das Problem zwar durch eine Änderung im Quellcode des Kernels und eine Neukompilierung von diesem beheben, aber
da man dadurch ständig seinen Kernel selber backen muß ist das auf Dauer keine Lösung.
Daher war im Gespräch dieses Problem durch eine optional nutzbare Kerneloption zu lösen. Hat sich hier in letzter Zeit etwas getan?
Es wäre toll, wenn ein Kernelentwickler hierzu mal Stellung geben oder auf der Mailingliste nachfragen könnte.
Unter Ubuntu 9.04 war die Audigy 2 mit einem 64 Bit System jedenfalls deswegen nur eingeschränkt nutzbar, ob es sich bei Ubuntu 9.10 mit aktuellerem 64 Bit Kernel gebessert hat, weiß ich nicht.
Auf 32 Bit kernel tritt dieses Problem übrigens nicht auf.
Wenn es interessiert, hier gibt's dazu auch nen passenden Bug Report:
https://bugs.launchpad.net/ubuntu/+source/awesfx/+bug/183456
wie deine Soundkarte, allerdings muss der Treiber das explizit machen. Fuer 31bit wird
es etwas schwierig, da muss der Speicher dann in die 16MB ISA Zone passen (normal
sind die Stufen 16MB, 4GB, unendlich), sollte aber immer noch gehen.
An sich sollte der Treiber das auch unterstuetzen, aber warscheinlich ist irgendwas kaputt.
Am besten du schreibst einen Bugreport and die entsprechenden Entwickler.
> es etwas schwierig, da muss der Speicher dann in die 16MB ISA Zone passen (normal
> sind die Stufen 16MB, 4GB, unendlich), sollte aber immer noch gehen.
Hm, das könnte ein Problem sein, denn so eine typische gute Soundfontdatei paßt nicht in einen Speicherbereich von nur 16 MB. Meine Soundfontdateien die ich hier nutze sind ca. 128 - 256 MB groß.
Kann man mehrere 16 MB Zonen eventuell verketten?
> An sich sollte der Treiber das auch unterstuetzen, aber warscheinlich ist irgendwas kaputt.
Der verwendete Treiber ist der emu10k1 bzw. snd_emu10k1_synth (für den Synthesizer)
Eine alternative waere noch beim booten entsprechenden Speicher zu reservieren, dafuer braucht man aber
einen speziellen Kernelpatch.
Oder wenn du ein System mit IOMMU benutzt (zB Intel VT-d) kann die IOMMU das unmappen. Muss aber
auch vom Treiber richtig unterstuetzt werden und die IOMMU muss explizit an sein im BIOS und
im Kernel. IOMMU braucht wohl auch einen relativ neuen Kernel.