SNAP und SMP - Zwischenbericht

(DE) System, Installation, Konfiguration, Hardware, Treiber, Netzwerk, Virtualisierung, etc.
(EN) System, Installation, Configuration, Hardware, Drivers, Network, Virtualisation, etc.
Antworten
Holger
Beiträge: 54
Registriert: Sa 28. Dez 2013, 19:30

SNAP und SMP - Zwischenbericht

Beitrag von Holger »

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.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Super. Wenn du was hast zum Testen her damit. Ich habe zwar auch nur 2 Kerne, funktioniert soweit alles außer wenn ich Videos schaun möchte mit smplayer dann hab ich immer wieder harte Hänger. Scheint damit zusammenzuhängen, daß ich andere Fenster verschiebe. Oder Cursor.... Bin mir ziemlich sicher, daß dies ein SNAP/Video Problem ist. Wenn das auch mal gelöst wäre...
Holger
Beiträge: 54
Registriert: Sa 28. Dez 2013, 19:30

Beitrag von Holger »

Hallo zusammen,

sorry, es hat deutlich länger gedauert und es wird noch etwas dauern. Die skizzirten Lösungsansätze haben sich auch als Holzweg erwiesen. Das Problem ist nichtmal der SNAP und auch nicht die dive.dll - das Problem liegt tatsächlich in den IBM-Komponenten vom Presentation Manager. Da ist einiges nicht wirklich SMP-sicher, was im Prinzip auch bei anderen GRADD-Treibern durchschlagen dürfte (mehr oder weniger). Der Kernel ist ok, aber in der pmmerge.dll sieht es an manchen Stellen düster aus - z.B. RAMSEMREQUEST32 - was direkte Auswirkungen auf die vman.dll (VideoManager) hat. Ich habe inzwischen alles soweit gefixt, dass nichts mehr abstürzt. Was ich aber noch lösen muss ist das Thema, dass wenn mehrere Prozesse in der Video-Semaphore geblockt werden, diese in der richtigen Reihenfolge wieder loslaufen müssen. Sonst gibt es Grafikfehler - nicht fatal aber sieht doof aus. Allerdings hat IBM da gar nicht daran gedacht, muss mir was einfallen lassen.

Was VLC angeht - dort scheint es auch noch ein Problem in irgendeiner dll oder der gcc Runtime zu geben: Wenn ich mit einer CPU an den Start gehe, läuft VLC sauber. Nehme ich 2 Kerne und schalte einen ab, bleibt trotzdem das Bild manchmal stehen (der Ton läuft weiter, das Programm lässt sich aber nur "hart" beenden).
Wenn ich den Kernel so ändere, dass er trotzdem nur einen Kern an VLC meldet (auch wenn zwei Kerne laufen) dann funktioniert das Ganze wieder.

Fazit: Das Thema ist komplexer als gedacht, aber so wie es im Moment aussieht lösbar. Betroffen ist nicht nur der SNAP, sondern im Prinzip jeder GRADD-Treiber mit SMP (es kann natürlich sein, dass deren Autoren Workarounds eingebaut haben - das löst aber das grundsätzliche Problem nicht).

Ich melde mich hier, sobald ich etwas neues habe.
Benutzeravatar
Sigurd
Beiträge: 995
Registriert: Mo 23. Dez 2013, 08:35
Kontaktdaten:

Beitrag von Sigurd »

Hallo Holger,

wie schön, dass Du an dem Thema dran bleibst! Und es erstaunt mich immer wieder, welch fundiertes Wissen Du da hast! Weiter so!
OS/2 versus Hardware - Maximum Warp!
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hallo Holger,

super, ich schließe mich Sigurd an!

Wenn Du mal was zum testen hast, sag Bescheid.

Btw, wie könnten denn ggf. solche Bugfixe an OS2 Komponenten wie dem PM überhaupt legal zur Verfügung gestellt werden? Das würde ja wahrscheinlich nur über Mensys offiziell gehen, bzw. über einen anderen 'offiziellen' eCS oder OS" Distributor. Oder Rapidshare ;) Kleiner Scherz, bitte nicht als Aufforderung verstehen.

Oder sehe ich das zu kompliziert. ich frage nur weil ich es schade findne würde wnen sowas am Ende nur unter eCS v2.fantasy läuft, wie hatten da ja schon künstliche Abwärts-Inkompatibilität.
Andi B.
Beiträge: 742
Registriert: Di 24. Dez 2013, 16:40
Kontaktdaten:

Beitrag von Andi B. »

Einen Patch erstellen und verteilen wäre sicher nicht illegal. Gepachte os/2 Files eher schon. Auch wenn sich wohl kaum wer darüber aufregen würde.

Wenn man mal weiß wo welche Dateien wie geändert werden müssen, dann wird sich sicher jemand finden der dies benutzergerecht verpacken kann, sodass die entsprechenden Dateien auf den Benutzerrechner geändert werden. Der älteste Patch solcher Art der mir gerade einfällt ist z.B. newcalls. Mensys braucht man dazu sicher nicht.

@Holger - wäre toll wenn du deine Erkenntnisse auch auf os2dev weitergeben würdest.
Benutzeravatar
wdsibyl
Beiträge: 96
Registriert: Di 14. Jan 2014, 23:24
Wohnort: Wien, Österreich
Kontaktdaten:

Beitrag von wdsibyl »

Hallo Holger!

Auch vielen Dank für Deine Arbeit und ich würde dies auch gerne testen.
Also falls Du was hast, dann schicke es mir. Vielen Dank,

lg,
Wolfgang
--
Firma:
HP: http://www.wodrsoftware.at/
eMail: office@wodrsoftware.at
Antworten