Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Aber was bedeutet denn der Error? Ich denke mal das hat sicher was mit dem raustabben zu tun.
Dass sie nicht dargestellt wurden, kann es ja nicht bedeuten, dann stände da ja einfach eine 1.
Dass sie nicht aufgenommen wurden, auch nicht, sonst hätten sie ja keinen Wert.
Ich denke mal, dass da eher irgendwelche abgefangenen Ausnahmen stattgefunden haben.
Ergänzung ()
Taxxor schrieb:
Und noch mal zu den low Werten: Kann man es denn einfach umsetzen, dass er rundet? Also bei einem 0.1% low Wert von 6300 Frames den Schnitt der schlechtesten 6 Frames und bei einem von 6700 Frames den Schnitt der schlechtesten 7 Frames.
Bei einem Wert von 6,3 direkt 7 Werte zu nehmen, wie es das FRAPS Tool macht, ist nicht so optimal.
Aber bei einem Wert von 6,7 trotzdem nur 6 Werte zu nehmen, verfälscht den Wert ja genau so, nur in die andere Richtung.
Aber ich runde doch gar nicht. Hast du den Code oben gesehen? Ich berechne das p-Quantil auf Basis der kubischen Interpolation (bei nicht-ganzzahligen Indizes) und verwende das als Schranke für den Average der Teilmenge.
Nach vielem rumtesten räume ich den Post hier mal etwas auf das wesentliche auf.
Insgesamt scheint es so, als wäre mein Wunsch mit dem Auf- und Abrunden bereits genau so im Programm, es fiel nur nicht auf, weil alle meine getesteten Spiele bei den 0.1% Werten blöderweise eine Anzahl an Frames haben, die die erste Dezimalstelle <5 haben und das Programm da logischerweise immer abgerundet hat.
Da das FRAPS Tool immer alles aufrundet, gibt es auch überall diese Unterschiede.
Wäre dort ein Bench mit einer Anzahl an 1% oder 0.1% Frames >x,5 gewesen, hätten die Ergebnisse vermutlich zusammengepasst.
Hier der Vergleich mit dem enthaltenen Witcher 3 Bench
1319 Frames
1% ist der 13,19. Frame
0.1% ist der 1,319. Frame
Der Wert vom Fraps Tool ist exakt der Schnitt der aufgerundeten Menge(14 bzw. 2), der von CapFrameX exakt der Schnitt der abgerundeten Menge(13 bzw. 1).
Für mehr Genauigkeit hier auch noch mal direkt aus dem Programm
Die Werte passen bis auf die 7. Nachkommastelle genau zu einem Schnitt aus den 13 bzw. 1 schlechtesten Werten. Die 13,19 und die 1,319 wurden also definitiv erst abgerundet und dann aus dieser Anzahl der Schnitt gebildet.
Dann wollte ich die andere Seite testen mit einem Bench, wo der 0.1% Wert näher an der größeren Zahl ist.
Insgesamt 4812 Frames, 0.1% ergeben also 4,812.
Hier passt der Wert exakt bis auf die 7. Nachkommastelle, zum Schnitt der 5 schlechtesten Frames.
Die 4,812 wurden also definitiv erst aufgerundet und dann aus dieser Anzahl der Schnitt gebildet.
Edit: Einen gibt es sogar in meiner Benchmark Liste, ESO hat 5762 Frames, also für 0.1% eine 5,76 und der 0.1% Wert von ESO ist der einzige, der mit dem FRAPS Wert übereinstimmt, weil hier ebenfalls aufgerundet wurde.
Ok, verstehe. Es ist ja kein Runden, sondern Ceil und Floor (Gauß-Klammer). Aber ein Vorschlag zur Güte: ich nehme nicht den Wert des nächst größeren Index mit rein in den Mittelwert, sondern das (interpolierte) p-Quantil selbst. Was meinst du?
Also am Beispiel meines letzten Witcher 3 Benches mit 4812 Frames, nicht den Schnitt der schlechtesten 5 Frames
= 3,916fps
Sondern den Schnitt der schlechtesten 4 Frames(1172,708ms)+ deines 0.1% Quantil für den Wert zwischen 4 und 5(101,759ms)
Teilst du dann trotzdem durch 5? Dann kommen 3,923fps raus, was komisch ist, denn eigentlich sollte man erwarten, dass der Wert schlechter wird, wenn man nicht den nächst besseren Frame nimmt.
Sowieso sind die 101ms für das interpolierte p-Quantil merkwürdig, eigentlich müsste der Wert doch irgendwo zwischen dem 4. und 5. Frame liegen, also zwischen 104ms und 108ms.
Allgemein würde das die Sache aber natürlich noch mal um einiges genauer machen(hier jetzt nicht so sehr, aber wenn man mal einen Wert von 4,5 hat und die Frametimes drum herum stärker abweichen), genauer ginge es ja dann eigentlich schon gar nicht mehr.
Wenn es vom Code her kein massiver Aufwand ist, warum nicht?
Aber noch mal zum Verständnis für mich, ob man es jetzt Runden nennt oder nicht(so wie sich das für mich liest, ist Ceil ein Aufrunden und Floor ein Abrunden):
Es ist momentan schon so, dass bei einem 6,4 Wert die 6 schlechtesten und bei einem 6,6 Wert die 7 schlechtesten Frames genommen werden oder?
Denn das ist zumindest exakt so bei meinen beiden Nachtests oben rausgekommen und wird auch dadurch bestätigt, dass der 0.1% low des ESO Bench als einziger mit den Fraps Werten(die immer aufgerundet sind) übereinstimmt und gleichzeitig als einziger für den 0.1% Wert eine Dezimalstelle >5 hat.
@Taxxor Ich mache gerade mal einen kleinen Patch fertig. Probier' das bitte mal aus, ob sich das wie gewünscht verhält.
Edit1: Hier schon mal der Code dazu.
C#:
public double GetPAverageHighSequence(IList<double> sequence, double pQuantile)
{
var pQuantileValue = sequence.Quantile(pQuantile);
var subSequence = sequence.Where(element => element > pQuantileValue).ToList();
subSequence.Add(pQuantileValue);
return subSequence.Average();
}
Edit2: Einfach die Datei ins Installationsverzeichnis kopieren. Die Low Average Werte werden insgesamt größer dadurch, weil ein größerer Wert mit aufgenommen wird in die Teilsequenz.
Beim ersten Witcher 3 Bench werden sie größer(0.1% low von 8,24 auf 8,53), hier ist es auch richtig, da hier vorher abgerundet wurde(von 1.319 auf 1 Frame). Jetzt ist es näher am FRAPS Ergebnis, welches einfach mit 2 Frames gerechnet hat.
Aber sie müssten ja eigentlich auch kleiner werden, sofern vorher aufgerundet wurde.
Der 0.1% Low Wert von meinem zweiten Witcher 3 Bench war oben 3,915fps und das ist ja der Schnitt der schlechtesten 5 Frames(aufgerundet von 4,812), also ist der Wert durch das komplette Dazunehmen des 5. Frame schon etwas besser.
Da 0.1% aber genauer genommen eben diesen 4,812 entsprechen, würde ich doch annehmen, dass der Wert hier dann etwas kleiner werden muss, wenn man es genauer machen möchte.
Nach dem Patch sind es 4,351fps
@ZeroStrat
Okay den Fehler habe ich gefunden.
Du wolltest ja das p-Quantil statt dem nächst größeren Index mit reinnehmen, hast aber nun teilweise beides zusammen drin.
Das Programm "rundet" weiterhin vorher und macht erst mal eine ganze Zahl draus(also von 1,319 auf 1, aber auch von 4,812 auf 5)und nimmt zusätzlich noch das Quantil hinzu.
Im ersten Fall funktioniert das, da man erst auf den nächst niedrigeren Index gegangen ist und dann das Quantil drauf gepackt hat.
Aber im zweiten Fall hat man dann noch mehr Abweichung als vorher, weil man ja vorher schon auf den nächst höheren Index gegangen ist. Man landet quasi nicht beim 4,8. sondern beim 5,8. Frame
Für den zweiten Witcher 3 Bench gilt:
Summe der 5 Frametimes: 1276,886ms
Plus 0.1% Quantil(101,759ms): 1378,645ms
1378,645ms/6 = 229,774ms = 4,35fps
4,35fps ist das was Capframe ausgibt.
Hier musst du dann darauf achten, dass wirklich immer der nächste niedrigere Index genommen wird und da dann das Quantil dazugerechnet wird. Denn jetzt wurden aus exakten 4,8 Frames statt vorher 5 Frames nun 5 Frames + 0.1% Quantil(also 6 Werte) gemacht, richtig wären 4 Frames + 0,1% Quantil
Ich kann da jetzt keinen "Fehler" (ist ja eigentlich eine Definitionssache) mehr sehen. Die Zeile
var subSequence = sequence.Where(element => element > pQuantileValue).ToList();
sorgt dafür, dass immer die nächst größeren (wir sind ja noch bei den Frametimes) Werte genommen werden. Es gibt zwei Fälle:
1. pQuantileValue entspricht einem ganzzahligen Index i. Dann werden alle Werte ab i+1 genommen wegen der echt größer Relation (>). Zu diesen Werten kommt dann noch sequence(i) dazu und es wird gemittelt.
2. pQuantileValue entspricht einem nicht-ganzzahligen Index zwischen i und i+1. Dann werden ebenfalls alle Werte ab i+1 genommen wegen der echt größer Relation (>). Zu diesen Werten kommt dann noch pQuantileValue dazu und es wird gemittelt.
Anscheinend nicht immer, denn bei meinem Witcher 3 Bench mit 4812 Frames wurden für 0.1% low 5 Frames + das Quantil genommen und durch 6 geteilt, was 4,35fps ergibt.
Der nächst größere Wert wäre aber ja der 4. Frame gewesen, und der plus das Quantil und durch 5 geteilt müsste 3,923fps ergeben.
Ich füge mal die Datei an, dann kannst du ja mal reinschauen.
Edit: @Taxxor Alles konsistent hier soweit. Das 0.1% Quantil liegt zwischen Index 4 und 5. Es werden also 0-4 genommen, was 5 Werte sind und dann kommt das p-Quantil nochmal dazu. Somit sind es insgesamt 6 Werte.
Ich bin etwas verwirrt wegen dem Umdenken mit den Frametimes, der höhere Index ist dann der größere und damit schlechtere Wert? Also Index Nr 0 ist die beste Frametime und Index Nr. 4811 die schlechteste?
In deinem Screenshot von der letzten Seite ist Index 0 die schlechteste Frametime.
Wenn du dann bei 4,812 i+1 rechnest, kommst du doch auf 5 und damit der nächst kleineren Frametime und packst dann noch das Quantil drauf.
Ergänzung ()
ZeroStrat schrieb:
Alles konsistent hier soweit. Das 0.1% Quantil liegt zwischen Index 4 und 5. Es werden also 0-4 genommen, was 5 Werte sind und dann kommt das p-Quantil nochmal dazu. Somit sind es insgesamt 6 Werte.
Warum beginnt der Index überhaupt mit 0 und nicht mit 1?
Wenn ich den 4,8. Frame will, dann nehme ich insgesamt 4 Werte, nämlich den ersten bis vierten Frame. Einen "Nullten" Frame gibt es ja nicht.
Ich habe bei meinen Vergleichsmessungen doch auch bei 1 angefangen und kam damit immer auf die Ergebnisse von Capframe.
So rein von der Logik her, vorher wurde bei 4,8 mit 5 Werten gerechnet und das FPS Ergebnis war daher mit 3,912 logischerweise etwas zu hoch, weil der 5. Wert ja in Wirklichkeit nicht ganz erreicht wurde.
Jetzt ist es aber mit 4,35fps noch viel höher als vorher, obwohl es niedriger werden müsste.
Ich bin etwas verwirrt wegen dem Umdenken mit den Frametimes, der höhere Index ist dann der größere und damit schlechtere Wert? Also Index Nr 0 ist die beste Frametime und Index Nr. 4811 die schlechteste?
In deinem Screenshot von der letzten Seite ist Index 0 die schlechteste Frametime.
Wenn du dann bei 4,812 i+1 rechnest, kommst du doch auf 5 und damit der nächst kleineren Frametime und packst dann noch das Quantil drauf.
Ist ein bisschen Brainfuck gerade. Index 0 ist das schlechteste Frame hinsichtlich der Frametime. Vergiss erstmal die FPS. Durch die echt größer Relation wird immer der Index i-1 genommen, wenn das p-Quantil zwischen i und i-1 liegt. Das gilt auch, wenn es genau bei i liegt. In dem Beispiel ist es die 4. Runtergezählt bis 0 sind das 5 Werte.
Also noch mal ganz langsam, das 0.1% Quantil bei 4812 Frametimes liegt bei 4,8.
Also 0.1% der Werte sind schlechter als der 4,8. Wert.
Wir suchen also den 4,8. Wert.
Der befindet sich in deiner Liste, wenn Index 0 der 1. Wert ist, aber doch zwischen Index 3 und 4, nicht zwischen 4 und 5.
Vor den Patch war das Ergebnis ja auch der Schnitt der schlechtesten 5 Werte, also in deiner Liste Index 0-4.
Jetzt müsste es der Schnitt der schlechtesten 4 Werte + p-Quantil sein, also Index 0-3+ p-Quantil als 5. Wert.
Es macht ja keinen Sinn, wenn der FPS Wert am Ende durch einen 6. Wert noch höher wird als vorher, wo er durch den Schnitt der schlechtesten 5 Werte bei eigentlich 4,8 bereits etwas höher ausgefallen ist.
Ergänzung ()
@ZeroStrat Mal so als Beispiel:
Wenn wir genau 7000 Frames hätten, dann müssten die 0,1% low doch auch exakt der Schnitt der 7 schlechtesten Frametimes sein, genau wie das p-Quantil genau der 7. schlechteste Wert sein müsste.
Bei dir wäre das dann Index 7 und damit(0-7) der Schnitt der 8 schlechtesten Werte und das p-Quantil auch der 8. schlechteste Wert.
Da du in diesem Fall ebenfalls i-1 nimmst, kämen wir aber dann auf Index Nr. 6 und damit tatsächlich auf den 7. Wert.
Im oberen Fall mit 4,8(allgemein bei allen Zahlen mit Dezimalstelle) müsstest du hingegen erst mal auf den nächst kleineren ganzen Index runden, also auf die 4, dann i-1, also auf die 3(jetzt sind wir bei 4 Werten) und dann dein p-Quantil dazu(um einen theoretischen 4,8. Wert zu bilden), womit es wieder 5 Werte sind, deren Schnitt aber etwas schlechter als der der normalen 5 Werte [0-4] liegen dürfte, genau wie es sein sollte, wenn das p-Quantil eben etwas kleiner als 5 ist.
Das gleiche gilt übrigens für das Quantil selbst.
Wenn das Quantil bei 4,8 liegt, sollte der Wert zwischen der 4. und 5. schlechtesten Frametime liegen, also zwischen Index 3 und 4.
Ich hatte mich nämlich auch schon gewundert, wie denn hier das 0.1% Quantil, welches bei 4,8 liegen soll, einen besseren Wert(101ms) haben konnte, als die 5. schlechteste Frametime(104ms).
Nur, wenn man unter 1000 Frames hat und das Quantil somit bei 0,x ist, würde das nicht so einfach funktionieren, hier müssten min, 0.1%low und 0.1% alle auf die schlechteste Frametime verweisen, denn was darunter gibt es nicht.
Dann ist der Ansatz über das p-Quantil als Schranke + p-Quantil nicht der richtige. Zwischen dem Index und der Anzahl p*n gibt es immer eine Differenz von 1.
Index 4-5 liefert 6 Werte, wenn man entweder den Wert bei 5 oder das p-Quantil mit aufnimmt. p*n liefert 5 Werte, so dass man bis maximal Index 4 gehen darf.
Wir müssen uns schon entscheiden...
Taxxor schrieb:
Wenn das Quantil bei 4,8 liegt, sollte der Wert zwischen der 4. und 5. schlechtesten Frametime liegen, also zwischen Index 3 und 4.
Ja, aber du dürftest mir doch sicher zustimmen dass wir eigentlich zwischen den 4. und 5. Wert müssten.
Das 0,1% Quantil bei 5000 Frames ist 5 und sagt damit ja schließlich, dass 4 Frametime Werte schlechter sind als dieser wert. Wenn es bei dir der Index 5 ist, sind aber 5 Werte schlechter
Bei den 0.1% Low vom Witcher 3 Bench reicht es immerhin, um die FPS von eigentlich schon zu hohen 3,9 auf 4,25 zu heben. Klar, ist nicht viel, aber sie sollten eigentlich irgendwo um 3,8 liegen.
Und das Quantil wird auch schwer beeinflusst, weil der 5. Index 89ms und der eigentliche 5. Wert 104ms beträgt.
Das Programm müsste also bei einem p-Quantil >1 erst mal n-1 rechnen um auf den passenden Index zum wert zu kommen und dann wie gehabt weitermachen.
Dann haben wir bei einem p-Quantil Wert von 4 auch wirklich den 4. Wert und nicht den 5.
Oder liege ich da völlig daneben und die Werte sind so okay und wir hätten uns die letzten 20 Posts sparen können?^^
Es ist Definitionssache. Aber es ist manchmal besser, wenn man sich vom Gewohnten nicht zu weit entfernt. Deshalb hier noch ein Ansatz über knallhartes Abzählen. Wenn die Anzahl nicht ganzzahlig ist, wird einfach auf den nächst kleineren Wert gegangen. Einfacher geht's nicht.
C#:
public double GetPAverageHighSequence(IList<double> sequence, double pQuantile)
{
int count = (int)(sequence.Count * (1 - pQuantile));
var orderedSequence = sequence.OrderByDescending(x => x);
return orderedSequence.Take(count).Average();
}
Index 0 ist das schlechteste Frame hinsichtlich der Frametime. Vergiss erstmal die FPS. Durch die echt größer Relation wird immer der Index i-1 genommen, wenn das p-Quantil zwischen i und i-1 liegt. Das gilt auch, wenn es genau bei i liegt. In dem Beispiel ist es die 4. Runtergezählt bis 0 sind das 5 Werte.
