Hi, hab hier ne Windows-Software liegen (leider nicht den Source-Code) welche mittels QT programmiert worden ist. Diese besteht aus insgesamt fünf Threads, die mir alle im Taskmanager angezeigt werden. Innerhalb der Software befinden sich viele Felder mit Beschriftungen, die über die Daten, welche über die USB-Schnittstelle ankommen, kontinuierlich umbenannt werden. Liegen an der USB-Schnittstelle neue Daten an, so dass ständig upgedated werden muss, kommt das GUI-Interface nicht mehr hinterher und die Beschriftungen bleiben die alten -> kein einziges Update erfolgt. Die CPU-Auslastung der beiden Kerne liegt bei gerademal 60%. Hatte eher eine Auslastung von nahezu 100% erwartet. Mehr Arbeitsspeicher (4GByte) hatte keinen Erfolg gebracht. Zum Einsatz kommt ein DualCore 1.6GHz. Ein ähnliches Szenario habe ich bei einem DualCore 2.7GHz. Erst bei einem QuadCore mit jeweils 2.1GHz läuft das Programm ohne Probleme (wobei der vierte Kern nicht in Anspruch genommen wird). Das gleiche Programm gibt es auch für Debian in einer Kioskanwendung. Im Taskmanager sind hier nur die fünf Prozesse so sehen, wobei der Prozess fürs Updaten der GUI stets bei 80-90% Auslastung liegt - egal ob Daten an der USB-Schnittstelle anliegen. Wie kann man sowas erreichen? Wird dann im idle process wieder dieser Prozess aufgerufen oder existiert möglicherweise in diesem Fall gar kein Idle Process? Das System besteht aus einem DualCore 2.5GHz. Der Rest der Konfigurationen ist immer die gleiche. Kennt jmd ein solches Szenario zwischen Windows und Linux? Irgendwie muss das Programm doch auch unter Windows auf einem DualCore 2.5GHz oder ähnlich flüssig laufen können. Gruß Ingo
60% eines Dualcores fuer einen Serialport ... 80-90% fuer das Updaten des GUI ... Scheint mir Pfusch zu sein. Eine Poll-schwarte ? Die Anwort auf die Frage waere nun : 42.
Selbst wenn du wüßtest, auf welche Art das Programm verbockt wurde, würde dir das ohne Sourcecode nicht viel bringen.
Rolf Magnus schrieb: > Selbst wenn du wüßtest, auf welche Art das Programm verbockt wurde, > würde dir das ohne Sourcecode nicht viel bringen. das ist in der Tat richtig. Was mich allerdings interessiert ist, ob man irgendwo / irgendwie die max. CPU-Inanspruchnahme eines solchen Programs / Prozess regeln kann?
im taskmgr kannst bei Prozesse die "priorität" festlegen (auf niedrig z.b.) bzw. auch auf die einzelnen Kerne aufteilen das problem liegt aber vermutlich wo anders.. wenn "nicht mehr updated" wird, heißt das vorallem eines: die messageqeue wird nicht abgearbeitet, das ist eher ein programmfehler..
>Diese besteht aus insgesamt >fünf Threads, die mir alle im Taskmanager angezeigt werden. im taskmanager werden übrigens Prozesse angezeigt, keine Therads...
Robert L. schrieb: > im taskmanager werden übrigens Prozesse angezeigt, keine Therads... es werden auch Therads angzeigt, zumindest du einzahl je Prozess.
Robert L. schrieb: > wenn "nicht mehr updated" wird, heißt das vorallem eines: die > messageqeue wird nicht abgearbeitet, das ist eher ein programmfehler.. ok, das hat nichts mit der Systemauslastung zu tun, sondern lediglich damit, dass das Programm nicht in der Lage ist, die ankommenden Messages entsprechend in der dafür vorgesehenen Zeit abzuarbeiten. Unter Umständen kann es dann auch sein, dass diese Messagequeue voll bzw. überläuft. Und beim Einsatz von einem QuadCore kann diesem Dilemma entgegengewirkt werden, indem dieser eine PRozess auf den dritten Core ausgelagert wird. Gibt es eigentlich zwischen Windows Embedded und Windows große Unterschiede in dieser Messagequeue hinsichtlich der Performance? Bzw. gibt es unter WinEmbedded die Möglichkeit so einen Fehler auszubügeln? Und ist diese Messagequeue in Linux performanter als in Windows, da wir hier einen DualCore ohne Performanceprobleme einsetzen können.
ich versteh deine Frage nicht, macht aber nix: den Programmfehler durch mehr Rechenpower auszugleichen ist irgendwie Käse.. nachdem es keinen Sinn macht, irgendwas öfter als 25 mal in der Sekunden zu aktualisieren. macht man das sowieso anders: einfach einen Timer, der alle 1/25 Sekunde die aktuellen werte anzeigt (meist genügt jede sekunde) dann hast du keine "unmengen" an messages in der Qeue
Peter II schrieb: > zumindest du einzahl je Prozess. ist halt die Frage, wie es der TO gemeint hat wenn es wirklich ein Prozess ist mit 5 Threads, kann man im Taskmgr auch nicht die Prioritäten einstellen... irgendwie schaut es aus, als würden sich die threads gegenseitig zu Tode synchronisieren..
Robert L. schrieb: > irgendwie schaut es aus, als würden sich die threads gegenseitig zu Tode > synchronisieren.. oder 4 Thread sind systemthreads die gar nicht bewust gestartet wurde und die anwendung läuft nur in einem Thread.
Robert L. schrieb: > macht man das sowieso anders: einfach einen Timer, der alle 1/25 Sekunde > die aktuellen werte anzeigt (meist genügt jede sekunde) ich danke euch für die Antworten. Das die Message-Queue nicht schnell genug abgearbeitet werden kann, hört sich sehr plausibel an. Ich glaub, wie ihr schon richtig erwähnt habt, kann man das Problem im Detail nur mit dem Source-code angehen und von Außen gibt es keinerlei Einstellmöglichkeiten dieses Verhalten zu verbessern.
>die x86 Assembler können.
und die können dann natürlich ein mehrere MByte großes Programm, einfach
so mal schnell umschreiben..
;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.