CapFrameX - Capture und Analyse Tool

[ZeroStrat]

Erstmal über deine Argumente nachdenken, Baal.

 

[ZeroStrat]

@Baal Netbeck Ich habe über deine Argumente nachgedacht und konnte, hoffe ich zumindest, alles soweit nachvollziehen.

Du argumentierst pro:

• Sofern die Ausreißer reproduzierbar sind, sollen diese durch die % Low (Average) Metriken abgebildet werden. Ausreißer gehören zu einem realen Hardware- /Softwareverhalten dazu.
• Nicht reproduzierbare Ausreißer können rausgefiltert werden, indem man "genügend" Runs durchführt und dann die schlechtesten rausschmeißt, wenn die Standardabweichung nicht innerhalb einer definierten Toleranz liegt.
• Der damit verbundene höhere Zeitaufwand wird akzeptiert. Besonders "hartnäckige" Kandidaten können und sollten im Zweifel aus dem Parcours entfernt werden.

Ich argumentiere contra:

• Die Erhöhung der Runs, um genügend Messungen zu haben, die eine angemessene Fehlerbeurteilung erlauben, ist nicht ausreichend praxistauglich. Es besteht immer Zeitdruck. Letztlich weiß der Leser des Testes nicht, wie gewissenhaft der Tester gearbeitet hat. "Normale" Perzentile erlauben eine deutlich bessere zeitliche Optimierung.
• Szenen, die zwar beispielsweise ein mürrisches Speichermanagement aufzeigen, aber dennoch gut worst case Performance abbilden, müssten unter Umständen aus dem Parcours entfernt werden, weil die % Low Metrik sich einfach nicht "einpendeln" will.
• Eigentlich gut geeignete Szenen oder sogar ganze Spiele müssen mitunter aus dem Parcours entfernt werden.
• Ausreißer gehören zu einem realen Hardware- /Softwareverhalten, werden aber nicht durch die % Low Metriken angemessen abgebildet. Der Mittelwert wirkt stark dämpfend, so dass die angestrebte Information nicht genügend scharf abgegrenzt werden kann. Die in CX verwendete Stuttering Time ist dafür besser geeignet.

 

[Taxxor]

Bei Fall B mit den konsistenten Ausreißern sieht man aber z.B. an unseren Threshold Times, dass die FPS nur 0.46% der Gesamtzeit unter 60 waren, aber 3,15% der Zeit unter 75.

Ein 1% low Wert von 58.2 vermittelt da mMn auch ein ebenso falsches Bild, wie ein 1% Perzentil Wert von 72.

Deshalb ist es, egal ob man nun die lows oder die Perzentile benutzt, sowieso ratsam, auch unsere anderen Analysetools miteinzubeziehen^^

 

[ZeroStrat]

Ein 1% low Wert von 58.2 vermittelt da mMn auch ein ebenso falsches Bild, wie ein 1% Perzentil Wert von 72.

Das 1% Perzentil ist weitaus weniger sensitiv gegen Ausreißer.

 

[Taxxor]

Das 1% Perzentil ist weitaus weniger sensitiv gegen Ausreißer.

Sagt einem dadurch in diesem Fall eben weniger über die Realität im Spiel, als die 1% lows.

1% der Frames sind unter 72, aber auf die Zeit sind es über 3% die man unter 75fps ist

Bei einem halben Prozent der Zeit unter 60fps. sind die 1% lows mit 58 schon näher dran.

Die 1% lows sind halt dann schlecht, wenn sie durch ein oder zwei riesige Ausreißer runtergezogen werden, aber wenn man ein oder zwei riesigen Ausreißer hat, sollte man den Run eh wiederholen. Wenn man unsere Ausreißer Erkennung nun nach Perzentilen einstellt, kann es sein, dass sie trotzdem genommen werden, weshalb ich dafür ja auch Anfangs die 1% lows ohne Auswahlmöglichkeit vorgeschlagen hatte.

 

[ZeroStrat]

Bei den Perzentilen geht's ja nicht um Zeiten. Du bringst gerade eine völlig andere Betrachtung ins Spiel. Wenn es um Zeiten geht, kann man sicherlich etwas konstruieren, was nah dran ist, aber ohne Ausreißer auskommt. Es geht ja darum, dass Ausreißer ausgeschlossen werden, wenn keine Kenntnis über die Reproduzierbarkeit vorliegt. Diese Kenntnis kann man natürlich gewinnen, indem man die Anzahl der Runs erhöht. Das löst bei mir indes die Frage nach Praxistauglichkeit aus.

 

[Taxxor]

Ich denke mal mit 1% lows und 5% Toleranz dürften die als valide geltenden Runs eher übereinstimmen als beim 1% Perzentil mit 3% Toleranz.
Sollte die Reproduzierbarkeit gut sein, werden auch die 1% lows innerhalb dieser Toleranz bleiben, sollte sie schlecht sein, würde man es dann dort schneller sehen als bei den Perzentilen.

 

[ZeroStrat]

Ob das immer gilt, wage ich mal zu bezweifeln. Und warum sollte man die Toleranz erhöhen?

Sollte die Reproduzierbarkeit gut sein, werden auch die 1% lows innerhalb dieser Toleranz bleiben, sollte sie schlecht sein, würde man es dann dort schneller sehen als bei den Perzentilen.

Und was will man mit der Info machen? Mit P1 macht man sich doch unabhängiger von so was.

@FormatC @Wolfgang Was haltet ihr eigentlich von den 1% Low Metriken?

 

[Taxxor]

Und was will man mit der Info machen? Mit P1 macht man sich doch unabhängiger von so was.

Naja die Funktion heißt ja "Outlier Detection", da ist es doch im Grunde kontraproduktiv zur Erkennung eine Metrik zu nehmen, die 1% der Frames, die Ausreißer sein könnten, bereits vorab ignoriert.

Du möchtest ja gerade reproduzierbare Runs machen, wenn dann einer davon größere Ausreißer hat, die aber nicht ins P1 fallen, alle anderen gar keine, dann würdest du den einen Run doch eigentlich schon gerne wiederholen.

 

[ZeroStrat]

Also macht du bei Reproduzierbarkeit das und bei Nicht-Reproduzierbarkeit was anderes? Du musst jedoch erstmal u.U. umständlich herausfinden, wo überhaupt der Hase läuft.

 

[Taxxor]

Also macht du bei Reproduzierbarkeit das und bei Nicht-Reproduzierbarkeit was anderes?

Du vergleichst die Runs einfach immer nach ihren 1% lows(Voraussetzung für den Einsatz von 1% lows sind aber dann auch Runs mit mal mindestens 1000 Frames, damit man auch ein paar Werte zum Mitteln hat) und wenn das so passt, dann weißt du, dass du bei keinem Run irgendwelche vereinzelten Ausreißer hattest.

Wenn es so nicht passt, könntest du natürlich die Perzentile nehmen und dann wären die gleichen Runs die vorher nicht zusammen gepasst haben, plötzlich alle valide, aber ist das der Zweck der Sache?

 

[ZeroStrat]

Man sollte schon bei einer Metrik bleiben. Man kann ja die Lows durchaus nehmen, wenn man bereit ist u.U. mehrere Runs zusätzlich zu machen. Am Ende des Tages frage ich mich dann aber immer noch, wie viel Aussagekraft das in Bezug auf reproduzierbare/konsistente Ausreißer hat. Vielleicht hat @Baal Netbeck ein anschauliches Beispiel oder so.

 

[Taxxor]

Man muss doch gar keine Runs zusätzlich machen, wie wäre es denn mit sowas?

Run 1 und 3 sind wie die erste Spalte und dazwischen ist Run 2 so wie die zweite Spalte.

Wenn man nach 1% low erkennt und den einen nun wiederholen muss und danach sind alle drei valide, dann weiß man, dass dieser eine Run die Ausnahme war.
Wenn danach aber wieder einer der drei oder diesmal sogar zwei von den dreien rausstechen, hat man direkt seine Info über die mangelnde Reproduzierbarkeit.

Beim P1 wären sie halt direkt alle drei genommen worden.

Es häng am Ende davon ab wie genau man seine Ergebnisse haben möchte. Den Kingdom Come Bench bei PCGH hätte man mit 1% low glaube ich vergessen können.
Dann muss man sich entweder damit zufrieden geben, dass die Szene nicht so ganz genau reproduzierbar ist und die Perzentile nehmen, um die validen Runs zu bekommen, oder man nimmt die Szene eben nicht.


Dabei darf in der Diskussion aber auch nicht unerwähnt bleiben, dass unsere Perzentile ja nicht so berechnet werden, wie sie @Baal Netbeck in seinem Tool berechnet, sondern im Falle von wesentlich schlechteren Frametimes knapp unterhalb der P1 Grenze diese auch Einfluss auf den P1 Wert haben.

Somit ist unser Perzentil eigentlich schon eine Mischung aus dem "klassischen" Perzentil (wo es laut Wikipedia üblich ist, bei ungeraden Indizes immer den nächst kleineren ganzahligen zu nehmen) und den 1% lows.

 

[ZeroStrat]

 

[Taxxor]

Deshalb nehm ich die custom Descriptions

Wir hatten auch irgendwann mal nen Cloud Upload wo angeblich ne Intel HD verwendet wurde, ich denke mal das wird auch einfach n Gaming Laptop gewesen sein, wo die Intel HD eben an erster Stelle in der Liste stand.

Sowas könnte man theoretisch auch abfangen indem man beim Start prüft, ob derjenige custom Descriptions aktiviert hat oder nicht.
Wenn nicht und das System gibt mehr als eine GPU aus(die nicht identisch sind, um SLI zu ignorieren), bekommt man ne popup Meldung dass man die Karte wählen soll, die man verwendet.
Da steht dann ne Combobox mit den Einträgen von Windows und egal was man wählt, danach wird automatisch die Custom Description aktiviert und bei der GPU das ausgewählte reingeschrieben.
CPU und RAM bleiben beim aktivieren ja sowieso standardmäßig bei der Systembeschreibung.

 

[Baal Netbeck]

Ich bin leider nicht zu Hause.... Ist nicht so einfach am Smartphone zu schreiben.... Sonst hätte ich gerne ein paar Screenshots eingefügt.


Ich fand die Unterscheidung zwischen dem Anwendungsfall...."gucken wie es läuft" und "Messungen für eine Veröffentlichung" wichtig..... Ich beziehe mich jetzt eher nur auf den Fall einer Veröffentlichung.

Nicht reproduzierbare Ausreißer können rausgefiltert werden, indem man "genügend" Runs durchführt und dann die schlechtesten rausschmeißt, wenn die Standardabweichung nicht innerhalb einer definierten Toleranz liegt.

Das mit der Toleranz würde ich nicht machen.
Wo setzt man die an?

Und es ist auch problematisch, wenn eine Konfiguration ein Ergebnis aus drei messwerten ist, und die andere aus 5.

Ich denke man sollte alle gleich behandeln.

Also wie ich beschrieben hatte, zu jeder messung die 0.1% Low berechnen und entsprechend der gemachten Messungen immer eine feste anzahl rauswerfen...

Dafür sehe ich die 0.1%low als geeignet an, da hier definitiv mögliche Ausreißer drin sind.... Bei den Grenzwerten ist wieder die Frage welche man da benutzt usw.

Die Erhöhung der Runs, um genügend Messungen zu haben, die eine angemessene Fehlerbeurteilung erlauben, ist nicht ausreichend praxistauglich. Es besteht immer Zeitdruck. Letztlich weiß der Leser des Testes nicht, wie gewissenhaft der Tester gearbeitet hat. "Normale" Perzentile erlauben eine deutlich bessere zeitliche Optimierung.

Zeitliche Optimierung ist natürlich ein Punkt.

Wenn man mit percentile Werten die Ausreißer wegschneidet und die als "Frametimes" benutzt, bekommt man einfacher mit wenigen Messungen eine gute Reproduzierbarkeit.

Aber man hat eben auch einen Teil vom "Spielgefühl" weggeschnitten.

Und ich hatte Mal eine umfangreiche Analyse zu percentile gemacht....und wie diese sehr kritisch sein können, wenn eben nicht alle Peaks weggeschnitten werden....kann ich in ein paar tagen nachreichen, aber als "Kurzfassung":

Im Heroes of the storm hatte ich eine Szene, die immer 5 peaks hatte.
Und zufällig war die Messedauer und die FPS so, dass mein Percentile Wert dem 5. entspricht.
Dann habe ich das mit etwas OC getestet und obwohl es nur minimal besser lief und sich gleich anfühlte, sprang der percentile Wert auf den 6. Frametime.... Das war kein Peak und es sah so aus, als wären die "Frametimes" von 15 auf 50 gesprungen(genaue Zahlen habe ich nicht mehr im kopf).

Und auch wenn ihr da eine verbesserte methode habt, die diese Grenze weniger hart macht, glaube ich, dass sowas z.B. bei dem AMD vs Intel bezüglich Ram OC Artikel passiert ist.

Guckt Mal die 99.8P von AC: Origins an....den Vergleich, wo Radeon und GeForce unterschieden wird.
Die Radeon Werte sind alle schlecht.... Aber scheinbar sinnvoll gestaffelt... wird mit besserem RAM leicht besser aber alles um die 36-47 1/s.
Mit Intel cpu hohem OC dann 57 1/s... Noch scheinbar logisch und OK.

Aber die Werte mit GeForce gpu springen hart.
Es gibt eine Gruppe von 70-80....und dann der große Sprung auf 95.

Es fällt mir schwer zu glauben, das der 9900K mit etwas CPU OC und RAM von bereits schnellen 3600 CL16 auf 4133CL17 nochmal 30% besser werden kann, obwohl er bei den FPS nur 5% besser geworden ist.

Da müsste man Mal genau in die Messungen gucken, was da passiert ist... Aber ich vermute fast, sowas ähnliches wie bei mir in Heroes...
Nur über euren "Übergangsbereich" etwas abgeschwächt.

Szenen, die zwar beispielsweise ein mürrisches Speichermanagement aufzeigen, aber dennoch gut worst case Performance abbilden, müssten unter Umständen aus dem Parcours entfernt werden, weil die % Low Metrik sich einfach nicht "einpendeln" will.

Wie gesagt.... Dann ist das so.... Man testet ja auch keine Multiplayer Maps für einen Lauch artikel oder einen genauen Technik Vergleich.

Es gibt ja genug Spiele, die sich brauchbar messen lassen.... Ein Anno 1800 wäre nett im parcour, aber es ist nicht nötig..... Auch wenn ich da einen gewissen Ehrgeiz entwickelt habe.

Ausreißer gehören zu einem realen Hardware- /Softwareverhalten, werden aber nicht durch die % Low Metriken angemessen abgebildet. Der Mittelwert wirkt stark dämpfend, so dass die angestrebte Information nicht genügend scharf abgegrenzt werden kann. Die in CX verwendete Stuttering Time ist dafür besser geeignet.

Hmm.
Es stimmt, das der Mittelwert dämpft.

Da die Art der Schwankungen... Die Häufigkeit und Heftigkeit der Peaks von Spiel zu Spiel unterschiedlich ausfällt, sind die nicht unbedingt geeignet um zu sagen:
"Hardware A stellt dieses Spiel definitiv flüssig/ruckelig dar."
Aber sofern es reproduzierbar gemessen wurde, sagt es aus meiner Sicht besser, ob Hardware A oder B weniger stark Ruckelt.... Und auch mit Dämpfung, kann man abschätzen, ob es problemlos läuft oder doch etwas verbesserungswürdig ist.

Die Stuttering Time ist sehr interessant, aber
Ich kann mir da immer wenig drunter vorstellen.

Das schöne an percentile oder XLow ist ja, dass man es in 1/s aussrücken kann und sie dann die gleiche Einheit wir avg FPS haben.

Deshalb ist es, egal ob man nun die lows oder die Perzentile benutzt, sowieso ratsam, auch unsere anderen Analysetools miteinzubeziehen^^

Mehr verschiedene Statistik Werte runden das Gesamtbild ab.... Aus meiner Sicht sind mehr immer besser.

Aber das passt eher zum Fall einer Beurteilung der Spielbarkeit für rein private Zwecke.

Bei einer Veröffentlichung ist es oft gewünscht, dass da ein Wert für "die Frametimes" genannt wird.

Da die verschiedenen Kandidaten alle vor und Nachteile haben, ist die Entscheidung ja so schwer.

Und warum sollte man die Toleranz erhöhen?

Finde ich auch unlogisch.

Dabei darf in der Diskussion aber auch nicht unerwähnt bleiben, dass unsere Perzentile ja nicht so berechnet werden, wie sie @Baal Netbeck in seinem Tool berechnet, sondern im Falle von wesentlich schlechteren Frametimes knapp unterhalb der

Wie genau berechnet ihr die eigentlich?

Groß abweichen tun sie bei ein paar Vergleichen meinerseits nicht.


Also mein Programm macht gerade einen Neuanfang... Keine Konkurrenz zu capframeX...
Aber viel mehr "Quality of life" Anpassungen... Ich habe mit multithreading gespielt und auch einige neue Funktionen eingefügt oder in Planung.

Mein dümmster Plan ist es, eine autokorrelierte Zusammenfassung der frametime Verläufe zu erschaffen.

In meiner Vorstellung bringe ich die Verläufe zur Deckung.... Auch wenn die Mal etwas später gestartet sind oder beim Ablaufen kleine Variationen aufweisen.

Das wird noch viel Arbeit aber ich bin zuversichtlich.

Die Frage ist, was ich damit mache.

Einfach mitteln würde einen moving avg Verlauf geben, den man besser vergleichen kann, als das schwankende Etwas, dass sonst ein einzelner Verlauf ist.

Aber es nimmt die Info über die Schwankungen raus.
Ein zweiter Graph, der die Größe der Schwankungen anzeigt wäre sinnvoll.
Und Markierungen, wo einzelne Messungen Peaks hatten, aber andere nicht.

.... Naja....mal sehen ob das je was wird.

Das menschliche Gehirn ist halt in der Lage einen frametimeverlauf (mit gleicher Skalierung) sehr gut qualitativ mit einem anderen zu vergleichen.
Aber liegen die übereinander wird es schwer.... Und welchen Run aus den gemachten wählt man für den Vergleich aus? Ich habe immer den mit den zweitbesten 0.1low genommen, aber so ganz glücklich war ich damit nicht.

Daher die Idee mit der Autokorrelation.... Was meint ihr dazu?

 

[Taxxor]

Finde ich auch unlogisch.

Wie genau berechnet ihr die eigentlich?

Groß abweichen tun sie bei ein paar Vergleichen meinerseits nicht.

Die Toleranz erhöhen macht aus sicht der Aggregation für mich Sinn, da mit 3% Toleranz und 1% Low Werten bei mir so gut wie kein Spiel drei valide Runs hinbekommt, ohne dass ich 3-4mal wiederholen muss, eben weil sie so anfällig gegenüber Ausreißern sind.
Mit einer 5% Toleranz würden sie aber immer noch eher relevante Ausreißer erkennen als P1 mit 3% hätte ich geschätzt.

Wie die Perzentile berechnet werden das kann dir @ZeroStrat verständlicher erklären als ich.

Ich kann dir z.B. schon mal sagen dass wir gestern einen Test mit synthetischen Daten gemacht haben, 990x 100fps und 10x 10fps.
Das P1 daraus war 40.33fps.

Ergänzung (1. Juni 2020)

Das mit der Toleranz würde ich nicht machen.
Wo setzt man die an?

Und es ist auch problematisch, wenn eine Konfiguration ein Ergebnis aus drei messwerten ist, und die andere aus 5.

Ich denke man sollte alle gleich behandeln.

Also wie ich beschrieben hatte, zu jeder messung die 0.1% Low berechnen und entsprechend der gemachten Messungen immer eine feste anzahl rauswerfen...

Wo man sie ansetzt liegt ja in der Entscheidung desjenigen der den Test macht, aber 2-3% Messungenauigkeit sind doch idR akzeptiert, also sagen wir du nimmst 2% um ganz genau zu sein.

Damit ist es bei uns dann auch egal ob man 3 oder 5 Runs zusammenfasst, wenn keiner der Runs mehr als diese 2% vom Median aller Runs ( der weder der Wert des besten noch des schlechtesten sein kann) abweicht, wird sich an den aggregieren Werten nichts ändern.

Du wirfst ja auch den schlechtesten und den besten Run einfach vorsorglich raus, weil das potenzielle Ausreißer nach oben oder unten sein könnten, die nicht reproduzierbar sind.

Wenn diese beiden in ihren Werten aber nur jeweils 1% nach oben bzw. unten vom Median aller Runs abgewichen sind, ändert sich das Ergebnis doch nicht wirklich im Vergleich wenn du sie drin gelassen hättest.
Wenn sie so gut oder schlecht gewesen wären, dass es etwas geändert hätte, dann hätte die 2% Toleranz gegriffen und der Run wäre sowieso nicht genommen worden.

 

[Esenel]

Und auch wenn ihr da eine verbesserte methode habt, die diese Grenze weniger hart macht, glaube ich, dass sowas z.B. bei dem AMD vs Intel bezüglich Ram OC Artikel passiert ist.

Guckt Mal die 99.8P von AC: Origins an....den Vergleich, wo Radeon und GeForce unterschieden wird.

Aber die Werte mit GeForce gpu springen hart.
Es gibt eine Gruppe von 70-80....und dann der große Sprung auf 95.

Es fällt mir schwer zu glauben, das der 9900K mit etwas CPU OC und RAM von bereits schnellen 3600 CL16 auf 4133CL17 nochmal 30% besser werden kann, obwohl er bei den FPS nur 5% besser geworden ist.

Ist doch relativ einfach warum hier der Sprung passiert.
Da hast du die Settings nicht richtig gelesen. Erwischt ;-)

9900K/G/3600 CL16
VS
9900K(OC)/G/4133 CL17

Na ;-)
Genau.
Erst beim 4133er RAM wurde die CPU übertaktet.

Und da ACO ein Spiel ist welches über Kerne gut skaliert ist es ja auch klar, dass hier das mehr an Takt UND vor allem die Aufhebung des TDP Limits nochmal einen guten Schub zusätzlich zum RAM OC bringt.

Mystery solved :-)

 

[Baal Netbeck]

Da hast du die Settings nicht richtig gelesen. Erwischt ;-)

Lies nochmal meinen Beitrag... Ich habe durchaus verstanden, das die CPU mit übertaktet ist.

Und da ACO ein Spiel ist welches über Kerne gut skaliert ist es ja auch klar, dass hier das mehr an Takt UND vor allem die Aufhebung des TDP Limits nochmal einen guten Schub zusätzlich zum RAM OC bringt.

So eine Skalierung mit OC wäre mir noch nicht untergekommen.

Meiner Erfahrung kommen an fps oder frametime steigerungen nur 80% des CPU Takts und 40% des Ramtaks bei komplett gleichen Timings an.

Selbst wenn wir hier davon ausgehen, das es unrealistische 100% sind, wird es knapp

14,9% durch den RAM...6% durch den CPU Takt und 9% durch den Cache....da ist man noch knapp unter 30%.
Und es ist aus meiner Sicht völlig unrealistisch, dass alle drei zu 100% in Spieleleistung umgesetzt werden.... Mit der Radeon waren es doch sogar 43%?? Wo kommt die Steigerung her?

Und warum verbessern sich die avg FPS nur um 5%?
Da ist wohl doch ein GPU Limit am Werk, denn ansonsten sollte das ähnlich steigen.

Also für mich ist das nicht durch das OC zu erklären.... eventuell durch eine Eigenart des Spiels, wo mehr Zeit im GPU Limit, doe Frametimepeaks glättet oder so.

Aber es bleibt für mich ein komisches Ergebnis.

Edit: selbst wenn der 9900K stock eventuell ins power Limit läuft....denn wenn die avg nur um 5% besser werden wegen einem teilweisen GPU Limit, sollte das die CPU in dieser Zeit entlasten und so wie das Intel PL funktioniert dann eigentlich wieder ein paar Sekunden mehr boost zulassen.

 

[ZeroStrat]

Also mein Programm macht gerade einen Neuanfang... Keine Konkurrenz zu capframeX...
Aber viel mehr "Quality of life" Anpassungen... Ich habe mit multithreading gespielt und auch einige neue Funktionen eingefügt oder in Planung.

Mein dümmster Plan ist es, eine autokorrelierte Zusammenfassung der frametime Verläufe zu erschaffen.

In meiner Vorstellung bringe ich die Verläufe zur Deckung.... Auch wenn die Mal etwas später gestartet sind oder beim Ablaufen kleine Variationen aufweisen.

Das wird noch viel Arbeit aber ich bin zuversichtlich.

Die Frage ist, was ich damit mache.

Einfach mitteln würde einen moving avg Verlauf geben, den man besser vergleichen kann, als das schwankende Etwas, dass sonst ein einzelner Verlauf ist.

Aber es nimmt die Info über die Schwankungen raus.
Ein zweiter Graph, der die Größe der Schwankungen anzeigt wäre sinnvoll.
Und Markierungen, wo einzelne Messungen Peaks hatten, aber andere nicht.

.... Naja....mal sehen ob das je was wird

Baal, du solltest zum Team stoßen, so dass wir das in CX integrieren können. Gemeinsam übernehmen wir die Weltherrschaft.