<div dir="ltr">Ich denke jetzt nochmal laut...<br><div><div class="gmail_extra"><br><div class="gmail_quote">2013/10/28 Andreas Goetz <span dir="ltr"><<a href="mailto:cpuidle@gmail.com" target="_blank">cpuidle@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Moin,<br><div class="gmail_extra"><br><div class="gmail_quote">2013/10/28 Thorben Thuermer <span dir="ltr"><<a href="mailto:r00t@constancy.org" target="_blank">r00t@constancy.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
...<div class="im"><br><div>
> Im Ergebnis führt das dazu, dass das FE hässliche "Rampen" an den Stellen<br>
> anzeigt wo von 0-Werten (bzw. Stellen in der DB mit längeren Intervallen)<br>
> wieder auf Daten übergegangen wird.<br>
<br>
</div>beschraenkt sich das problem nicht drauf, jeweils die erste UND die letzte<br>
null drinzulassen?<br>
wenn du die letzte loescht, kann die middleware halt nichtmehr sagen, in<br>
welchem zeitraum die naechste aenderung stattgefunden hat,<br>
und verteilt sie halt auf den gesamten zeitraum seit dem letzten wert.</div></blockquote><div> </div><div>Schon getestet- tut es leider nicht. Das Problem ist "so gross", wie Tupel zusammengezählt werden. Wenn z.B. 2 Tupel am Ende vom Vortag aus 0 und x auf x/2 aggregiert werden und die ersten beiden Tupel vom Foleetag (0 und y) auf y/2 aggregiert, dann bedeutet das schlimmstenfalls eine Rampe von x/2 bis y/2 ohne dass die 0 jeweils im FE angezeigt wird. Je mehr Tupel aggegiert werden desto größer die Abweichung.<br>
</div></div></div></div></blockquote><div><br></div><div>Das Problem ist dass wir im Moment (wenn das FT tupels=xyz übergibt) Pakete schnüren. Seit dem entsprechenden Patch macht das die Datenbank:<br><br>    $sql = 'SELECT MAX(aggregate.timestamp) AS timestamp, SUM(aggregate.value) AS value, COUNT(aggregate.value) AS count '.<br>
           'FROM ('.<br>           '    SELECT timestamp, value, @row:=@row+1 AS row '.<br>           '     FROM data WHERE channel_id=?' . $sqlTimeFilter . <br>           ') AS aggregate '.<br>
           'GROUP BY row DIV ' . $packageSize .' '.<br>           'ORDER BY timestamp ASC';<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>In Griff kriegen liesse sich das nur wenn das FE einen irgendwie einen Hinweis bekommen wird dass zwischendurch die 0 "steht"  und die Daten ausgedünnt sind.<br>
<br></div></div></div></div></blockquote><div><br></div><div>Was spräche denn jetzt dagegen, stattdessen äquidistante Stücke zu schneiden, also nach timestamp DIV $packageSize zu gruppieren? und den entsprechenden Timestamp im Select hochzuzählen? Das Ganze noch mit IFNULL Statements ergänzt sollten wir in der Lage sein, fehlende (Null-)Werte zu ergänzen. Performance to be tested.<br>
</div><div>Dann besteht natürlich wieder die Gefahr, dass wir zwischen zwei Zählerwerten eine Null erfinden falls sich da kein weiterer Messwert anfindet- Tuples darf also nicht granularer werden als Messwerte wirklich vorliegen.<br>
<br></div><div>Wär hätte Lust einen Prototyp zu bauen und Performance zu testen??<br><br>vg<br></div><div>Andreas <br></div></div><br></div></div></div>