SNAP und SMP - Zwischenbericht
Verfasst: Sa 22. Mär 2014, 11:46
Hallo zusammen,
auf den Hinweis von Sigurd und seinen Problemen mit SNAP bei mehr als 4 Prozessorkernen habe ich mich mal hingesetzt und versucht, das Thema einzukreisen. Ich habe selber nur 2 Kerne und SNAP läuft damit - aber ich hatte auch immer wieder seltsame Verzögerungen beim Umschalten von Fenstern und ich habe mich auch gewundert, warum z.B. der VLC scheinbar nur einen Prozessor nutzt und dabei auch noch ruckelt.
Folgendes habe ich rausgefunden:
- die original GRADD-Komponenten, die SCITECH benutzt hat, sind nicht SMP-safe
- SCITECH hat einen Workaround eingebaut, der die Anzeigethreads auf einen Prozessor bindet (DosSetThreadAffinity). Das mag nicht jedes Programm und ich bin mir auch nicht sicher, ob der Code der den Prozessor auswählt, so korrekt ist.
Ich habe dann den Workaround mal testweise stillgelegt:
Das Ergebnis war eine wesentlich agilere Maschine, auch VLC nutzt jetzt beide CPU-Kerne gleichmäßig. Allerdings gab es auch prompt Hänger und Abstürze.
Ich habe dann die letzte SOM-dll eingespielt (von der ich weis, dass sie im Gegensatz zu der mit ECS-ausgelieferten weitere Semaphoren enthält) und einen neueren GRAD.SYS (aus dem PANORAMA-Paket) probiert.
Ergebnis: WPS stabil, die meisten anderen Programme wie FireFox, OpenOffice, Java Apps usw auch stabil. Instabil dagegen ist DIVE, mit VLC und Flash bleibt das Bild manchmal stehen und das lässt sich ganz klar auf SMP zurückführen (wenn VLC nur auf einer CPU ausgeführt wird, funktioniert alles).
Jetzt versuche ich mal, die DIVE-dll so zu erweitern, dass der Video-Einsprung mit einem Spinlock gesichert ist und hoffe, damit auch den Spuk bei Flash in den Griff zu bekommen. Ich melde mich wieder, wenn ich was brauchbares zum Testen habe.
auf den Hinweis von Sigurd und seinen Problemen mit SNAP bei mehr als 4 Prozessorkernen habe ich mich mal hingesetzt und versucht, das Thema einzukreisen. Ich habe selber nur 2 Kerne und SNAP läuft damit - aber ich hatte auch immer wieder seltsame Verzögerungen beim Umschalten von Fenstern und ich habe mich auch gewundert, warum z.B. der VLC scheinbar nur einen Prozessor nutzt und dabei auch noch ruckelt.
Folgendes habe ich rausgefunden:
- die original GRADD-Komponenten, die SCITECH benutzt hat, sind nicht SMP-safe
- SCITECH hat einen Workaround eingebaut, der die Anzeigethreads auf einen Prozessor bindet (DosSetThreadAffinity). Das mag nicht jedes Programm und ich bin mir auch nicht sicher, ob der Code der den Prozessor auswählt, so korrekt ist.
Ich habe dann den Workaround mal testweise stillgelegt:
Das Ergebnis war eine wesentlich agilere Maschine, auch VLC nutzt jetzt beide CPU-Kerne gleichmäßig. Allerdings gab es auch prompt Hänger und Abstürze.
Ich habe dann die letzte SOM-dll eingespielt (von der ich weis, dass sie im Gegensatz zu der mit ECS-ausgelieferten weitere Semaphoren enthält) und einen neueren GRAD.SYS (aus dem PANORAMA-Paket) probiert.
Ergebnis: WPS stabil, die meisten anderen Programme wie FireFox, OpenOffice, Java Apps usw auch stabil. Instabil dagegen ist DIVE, mit VLC und Flash bleibt das Bild manchmal stehen und das lässt sich ganz klar auf SMP zurückführen (wenn VLC nur auf einer CPU ausgeführt wird, funktioniert alles).
Jetzt versuche ich mal, die DIVE-dll so zu erweitern, dass der Video-Einsprung mit einem Spinlock gesichert ist und hoffe, damit auch den Spuk bei Flash in den Griff zu bekommen. Ich melde mich wieder, wenn ich was brauchbares zum Testen habe.