CPU-Auslastung permanent auf 100% ?

Zitat

Original von chrissi0407
[
@NavScout:
Auch die Screenshots in dem anderen Thread sind doch geeignete Facts, mit denen du dich direkt an Navigon wenden solltest!!!
sehr gute Arbeit

das kann man nur unterstreichen

Wie schon geschrieben:

Die 100% sagen nicht mehr und nicht weniger aus als dass das Gerät voll ausgelastet wird.

Wenn das System ein gutes Ressourcenmanagement hat, also der Programmteil, der dafür verantwortlich ist, die Last bis zum Anschlag hochzutreiben sofort Leistung freigibt, wenn ein anderer Programmteil oder ein anderes Programm diese benötigt, kann auch ein zu 100% ausgelastetes System hervorragend laufen. Warum sollen denn 20% der möglichen Prozessorleistung brach liegen gelassen werden, wenn man sie z.B. noch für eine Erhöhung der Framerate ganz gut gebrauchen kann?

Ein Prozessor, der nur bis 80% Last vernünftig funktioniert, ist gelinde gesagt eine Fehlkonstruktion.

Um es ganz klar zu sagen: Würde sich hier jemand über die 100% Prozessorlast beschweren, wenn es 25FPS gäbe, die während einer Sprachausgabe auf 20FPS absinken?

Ja, die 7.4 scheint für die heutige Gerätegeneration eine Nummer zu groß, aber nur an der Prozessorlast kann man das nicht ablesen.

Zitat

Original von rowdy
Hallo,

evt. 100% der verfügbaren Funktionalität, aber doch nicht 100 % der Leistung.

Kannst du das näher erklären?????
Analogon: ein guter Autofahrer gibt nie Vollgas oder wie.

Allerdings kann es ein Problem sein, eine CPU über lange Zeit ohne Reset laufen zu lassen. Genauso, wie ich mein Notebook mindestens 1x/Woche neu boote sollte man auch seinem Navi ab und an einen Reset verpassen um das Speichermanagement zu "optimieren".
Ich denke aber, das entscheidende in diesem Fall ist, daß keine Reserven für "Events" da sind und, daß eine anscheinend vorhandenen Zusatzhardware einfach nicht verwendet wird.

Zitat

Original von rowdy

Hallo,

evt. 100% der verfügbaren Funktionalität, aber doch nicht 100 % der Leistung.

Gruß
rowdy

Alles anzeigen

Na klar die Leistung, monitore mal verschiedene Betriebssyssteme mit jeweils einer einzigen anspruchsvollen Awendung wie JBoss oder Eclipse unter Volleinsatz (Hochfahren, Kompilieren, etc.) . Immer 100%.

@ilam hat perferkt erklärt, was von der Lastangabe zu halten ist, nämlich gar nichts, wie von diesem Thread hier. Schade, dass viele da einfach jubeln, ohne zu reflektieren.

Zitat

Original von chrissi0407

Allerdings kann es ein Problem sein, eine CPU über lange Zeit ohne Reset laufen zu lassen.

Sorry, das ist Unsinn. Eine CPU braucht keinen Reset, die ist "nur" das Rechenwerk das sich eh nix merkt. Die Register und der Cache wird eh überschrieben, wenn neue Daten kommen.

Zitat

Genauso, wie ich mein Notebook mindestens 1x/Woche neu boote sollte man auch seinem Navi ab und an einen Reset verpassen um das Speichermanagement zu "optimieren".

Das hat nichts mit der CPU sondern mit Mängeln am Betriebssystem zu tun, nämlich dass einmal gebundene Resourcen nicht wieder vernünftig freigegeben werden. Ein Unix kann problemlos Jahre durchlaufen, ob man es rebootet oder nicht, ändert da rein gar nichts.

Zitat

Original von ilam

Das hat nichts mit der CPU sondern mit Mängeln am Betriebssystem zu tun, nämlich dass einmal gebundene Resourcen nicht wieder vernünftig freigegeben werden. Ein Unix kann problemlos Jahre durchlaufen, ob man es rebootet oder nicht, ändert da rein gar nichts.

Natürlich hat das Primär was mit dem verwendeten OS bzw der SW zu tun. Keine SW und kein OS ist bugfree.
Allerdings sind auch SOCs (so wie die SIRFs) nicht bugfree und so würde ich mir an deiner Stelle den "Unsinn" nochmal überlegen.
Ich kenne aus eigener Erfahrung genügend vergleichbae SOCs, die unter bestimmten Bedingungen gerne mal einen "Fehler" machen. Dafür gibts dann für die Entwickler die schönen ErrataSheets.....
Alles andere ist nackte Theorie ;D

Vielleicht hilft uns allen die folgende (grobe, schematische und sehr vereinfachte ) Betrachtung.

Für die Aufbereitung und Aktualisierung EINER Bildschirmdarstellung benötigt eine SW eine bestimmte Anzahl von X Transaktionen, die der Prozessor verarbeiten muss. Sollen 8 Bilder pro Sekunde dargestellt werden, muss der Prozessor in der Lage sein die 8-fache Menge der X-Transaktionen in einer Sekunde zu verarbeiten. Darüber hinaus macht MN ja noch mehr als nur die Darstellungsgenerierung. Es kommen also noch erhebliche weitere Transaktionsanforderungen auf den Prozessor zu. ;D

MN7 bekommt / verarbeitet von der GPS-Schnittstelle jede Sekunde ein GPS-Datensatz. Bei 7 Bildern pro Sekunde werden 7 (bzw. 6) Zwischenpositionen errechnet (interpoliert) und aufbereitet.
Die Obergrenze beim MN sind glaube ich 7 FPS - mehr macht auch keinen Sinn. Die Untergrenze liegt sicher bei 1 FPS (das GPS-Signal hat ja auch den Sekundentakt). Bei 0 FPS hätten wir ja ein Standbild.

Die verschiedenen MapDrawer unterscheiden sich aber erheblich in der Anzahl der erforderlichen Transaktionen, die für eine Bildschirmaktualisierung benötigt werden.

Dem gegenüber steht aber nur eine bestimmte Leistung des Prozessors. Um in dem Beispiel zu bleiben, also eine bestimmte Anzahl von Transaktionen, die der Prozessor in einer Sekunde verarbeiten kann.

Es können sich nun folgende Situationen einstellen:

A - MN7.0.9 bzw. MN7.4.3 OldMapDrawer im 2D-Betrieb
Die Anzahl der Transaktionen bei 7 FPS plus die Anzahl der Transaktionen aufgrund der anderen MN-Funktionen ist geringer als die Anzahl der Transaktionen, die der Prozessor pro Sekunde abarbeiten kann.
Die CPU-Auslastung ist also unter 100% und die FPS ist auf 7

B - MN7.4.3 OldMapDrawer im 3D-Betrieb
Die Anzahl der Transaktionen bei 7 FPS plus die Anzahl der Transaktionen aufgrund der anderen MN-Funktionen ist höher als die Anzahl der Transaktionen, die der Prozessor pro Sekunde abarbeiten kann.
Die CPU-Auslastung ist also 100%. Dennoch werden alle MN-Funktionen "bedient", die für sich alleine eine CPU-Auslastung von sagen wir mal 70% bedeuten würde. Jedoch kann jetzt nur noch zusätzlich die Transaktionsmenge verarbeitet werden, die einer FPS-Rate von 6 entspricht.

C - MN7.4.3 (New)MapDrawer
wie unter B. Jedoch kann hier nur noch eine zusätzliche Transaktionsmenge verarbeitet werden, die einer FPS-Rate von 2 entspricht. Oder besser gesagt, die noch "freie" Transaktionsmenge reicht bei diesem "anspruchsvollen" MapDrawer nur noch für 2 FPS.

Steigen jetzt situativ die Anforderungen (TTS-Ansagen, Landmark, etc.) bleiben immer weniger Transaktionen für die Frame-Berechnung über - die FPS-Rate fällt! Jedoch wird eine FPS-Rate von 0,x bis 1 nicht weiter unterschritten. Sonst hätten wir ja ein Standbild. Daher wird in diesen Situationen die Verarbeitung anderer MN-Funktionen zurückgestellt (Prioritätssteuerung), oder einfach verzögert abgearbeitet.

Die Probleme kann man lösen, indem man einen leistungsstärkeren Prozessor verwendet, oder einen vorhandenen Grafikprozessor nutzt, oder SW mit geringeren spezifischen Transaktionsanforderungen entwickelt/verwendet (insbesondere PV-Algorithmen, Darstellungsalgorithmen ), oder die Anzahl der aufwendigen MN-Funktionen (z.B. Landmark, CityView3D) reduziert.

Die CPU-Auslastung alleine ist nicht aussagekräftig genug. Sie muss immer im Zusammenhang der verfügbaren FPS-Rate gesehen werden. Daher habe ich ja auch beide Angaben in der Tabelle aufgelistet.

Grundsätzlich finde ich es gut, wenn alles zu 100% genutzt wird, wofür ich bezahlt habe. :gap

Aber Fall A ist mir dennoch lieber als Fall C, bei dem keinerlei Reserven mehr vorhanden sind und das System immer kurz vor dem "Abgrund" steht. Und schon im Standardbetrieb eine FPS von 1-2 zu haben ist auch nicht schön anzusehen. Im Fall B stehen immer noch genügend "FPS"-Reserven zur Verfügung die "geopfert" werden können, bevor die Performance ganz einbricht.

P.S.
Zur Messung der CPU-Auslastung habe ich das Programm "ITaskMgr" verwendet. Mir ist nicht bekannt, welche CPU-Anteile da gemessen werden. U.U. ist der "Overhead" mit einbezogen. Dennoch ist er geeignet, da er ja die relativen Unterschiede der einzelnen Betriebssituationen wiedergibt. Für einen CPU/OS-Benchmark ist er sicherlich nicht geeignet.

Zitat

Original von chrissi0407

Seid mir nicht böse, aber nun übertreibt ihr schon wieder!
Ich lasse Prozessoren stundenlang unter 100% laufen (Videocodecs). Das ganze unter Windows und es gibt keinerlei Probleme. Von Neumann in allen Ehren, aber das hat nichts mit dem hier besprochenen Problem zu tun. Wenn vorhandene Hardware nicht genutzt wird, dann ist das peinlich für die Programmierer.
Aber bitte keine neue Verschwörungstheorie.

n8

Das bei dir mit Videocodes ist keine Echtzeit-Applikation, d.h. keine strenge zeitliche Einschränkung für Taskerledigung. Das Navisystem ist aber vom anderen Szenario, das sogenannte Runtimesystem, darf auf keinerfalls dauerhaft unter 100% CPU-Belastung laufen, so der Feststellung nach ist das 8310 System eine absolute Fehlkonstruktion im Sinn des Computer Engineerings. Die 3D-Image Bearbeitung ist sehr rechenintensiv, und der Grafikengine (GPU) ist dafür da, hat enorme Kapazität für Vertex und Mesh Bearbeitung. Wenn Naivgon dies nicht nutzen, und auf anderer Zeit noch 100% CPU auslasten lassen, muss man Navigon hart kritisieren weil sie bewußt auf diese Frechheit gehen wollen.

@NavScout 
Noch mal Danke für die Infos

Zitat

Original von jonywalker
Das bei dir mit Videocodes ist keine Echtzeit-Applikation, d.h. keine strenge zeitliche Einschränkung für Taskerledigung. Das Navisystem ist aber vom anderen Szenario, das sogenannte Runtimesystem, darf auf keinerfalls dauerhaft unter 100% CPU-Belastung laufen, so der Feststellung nach ist das 8310 System eine absolute Fehlkonstruktion im Sinn des Computer Engineerings.

Naja, ich kann dir Beispiele aus der CE nennen. Z.B. Fernseh SOCs, die bei 1080P60 mit allen Zusatzfeatures genauso an der Grenze laufen. Es gibt schon Möglichkeiten, das per Task-Management abzufangen....und sei es durch FrameDrop, wie ja bei Navigon gut zu sehen ist ;D
Ich gebe dir aber vom Grund Recht: Eine GPU (ich kenne sie bis heute nicht) ungenutzt zu lassen und dafür den µP an die Grenzen zu fahren ist grober Unfug.
Leider kennen wir die Beweggünde dafür nicht (und werden sie wohl auch nie erfahren)

Alles schön und gut, aber viele weitere Faktoren wie Ram-Durchsatz, Grafik-Durchsatz und vieles vieles mehr werden hier nicht berücksichtigt.

Am Ende einfach zu sagen, die CPU ist zu lahm für MN7 ist IMHO blauäugig. Da spielen viel mehr Faktoren eine Rolle, sowohl HW als auch SW und auch FW. Dann noch die Sache, dass bei vielen alles rund läuft. Mit der CPU-Theorie nicht zu erklären. Ok Klar, nächste Verschwörungstheorie, einige CPUs wurden in China übertaktet. :gap

Zitat

Original von chrissi0407

Leider kennen wir die Beweggünde dafür nicht (und werden sie wohl auch nie erfahren)

Dazu gehört nicht viel, diese zu erraten. Erinnert Ihr Euch? Für das 8110 war anfangs überhaupt kein Upgrade angekündigt. Es ist ziemlich offensichtlich, dass Navigon nur noch 1-spurig fahren will und die Software nicht zusätzlich auf die GPU anpassen will.
Bei Tests hat sich dann anscheinend herausgestellt, dass die 7.4 auf dem 8110 genauso gut/schlecht wie auf dem 7210 läuft, also kam die 7.4 auch für das 8110 auf den Markt...

Zitat

Original von Zero511
Na klar die Leistung, monitore mal verschiedene Betriebssyssteme mit jeweils einer einzigen anspruchsvollen Awendung wie JBoss oder Eclipse unter Volleinsatz (Hochfahren, Kompilieren, etc.) . Immer 100%.

@ilam hat perferkt erklärt, was von der Lastangabe zu halten ist, nämlich gar nichts, wie von diesem Thread hier. Schade, dass viele da einfach jubeln, ohne zu reflektieren.

Dein JBoss, Eclipse, oder noch irgendwas Java Compiler sind keine Echtzeit-Applikationen, ob früher oder später, hauptsache man kriegt die Aufgabe erledigt.
Das Navi Prozess hat mehrere Threads parallel im Lauf, darunter GPS Empfangsprozess, Ortunsprozess, Mappingsprozess, Imagebearbeitungsprozess, TMC-Prozess und schließlich noch Sprachausgabeprozess, alle dieser Threads müssen noch durch Inter-Thread-Kommunikation (runtime message loop, oder runtime events process) synchroniziert werden. Wenn alle Threads 100% CPU beansprucht wo kriegt noch Rechenzeit für die Interthreadskommuinikationen. Das Framerate für 1-2 fps sagt eindeutlich aus dass das Rendering (Imagebearbeitungsprozess) niedriger Priorität hat, und das System 2 oder 3 mal mehrfach ausgelastet ist.

Zitat

Original von Zero511
Am Ende einfach zu sagen, die CPU ist zu lahm für MN7 ist IMHO blauäugig.

"zu lahm" ist auch mit Sicherheit eine relative Definition.

Immerhin hat Navscout eindrucksvoll nachgewiesen, daß das 8110 mit 7.0 bei weniger Prozessorauslastung mehr Performance(im SInne des Anwenders) hat als mit 7.4.
Kann aber gut sein, daß das nicht für jeden hier interessant ist.
Ich habe auch Zweifel, daß die Mühe irgendwie von Navigon belohnt wird.

.....

Hallo,

bin ja auch im Besitz eines 8110_updatet :-).

Allerdings kann ich das Phänomen mit der 100% Prozessorlast nicht nachvollziehen.

@NavScout: welches Tool dafür hast du benutzt? Damit ich da nen Fehler habe.

Ich habe es mit zweierlei RemoteTolls versucht, habe eine schöne Stadtrundfahrt simuliert, die Prozessorlast der navigon.exe ist nie über 75% gestiegen, im Regelfall eher zwischen 25 und 38%.
Um dies aber auch bei aktiver NAvigation nachzuvollziehen, habe ich die RemoteTolls auf das Nebook gepackt und das gesammte Paket ins Auto geschleift. Hab mich dann einmal quer durch Stuttgart navigieren lassen, aber die Last ist nicht deutlich höher geworden.

Da hat mir der RapiSvr mehr "Sorgen" gemacht.

Michael