[vz-dev] Zeitstampfer - was: Re: Fwd: watchcat.c und Hardwareansteuerung

[Jens Wilmer]

Hallo zusammen,

Am 01.05.2010 21:14, schrieb Justin Otherguy:
> Lasst uns das doch mal wie folgt ausprobieren:
> - der Controller sammelt die eingehenden Impulse für ein konfiguriertes Intervall, z.B. 1s, 1 min, 15 min, 1 Tag...
>    
So etwas ähnliches sollte ja die "HighVolume" Version des "Watchasync", 
allerdings ist dies erst einmal nur mir 2^n Sekunden Intervallen möglich.
>    auf diese Weise lassen sich verschiedene Fälle abdecken:
>    - wir brauchen keine Auswertung der ms
>    - wir ahmen das Verhalten der Smart Meter der grossen EVU nach
>    - wir schonen unsere Internet-Anbindung
>    - wir haben einen Zähler, der kontinuierlich Impulse rausspuckt und wandeln das so in eine zeitkontinuierliche Folge
> - bei der Übermittlung verwenden wir dann einen zusätzlichen Parameter "count"
>    - dieser ist optional (so können wir auch den bisherigen Modus weiter laufen lassen)
>    - das Default ist count=1
>    
Bei mir würde sich allerdings das format der Anfragen ändern, da alle 
Impulse eines Intervalles von allen Eingängen gesendet würden. Es sollte 
aber kein Problem sein, dies auf dem Server zu sortieren.
> - bei der Auswertung können gibt es ja derzeit bereits 2 Modi:
>    - den "Direktmodus":
>      hier wird aus allen Zeitstempeln Zeitstempel-/Leistungs-Tupel berechnet und an den Browser übermittelt
>      Das ist wunderbar für eine Darstellung, bei der die Anzahl Impulse/Pixel in der Darstellung sehr gering würde (derzeit ist dieser Schwellwert (Variable "$schwelle") auf 10 eingestellt: weniger als $schwelle Impulse im Intervall ->  "Direktmodus"; sonst: "Zählmodus"
>    
Da dieser Modus nur leider immer falsche Werte Anzeigt, außer bei 
konstantem Verbrauch ab dem zweiten Intervall, würde ich ja gern bei der 
Darstellung schon auf diesen Modus verzichten.
>    - den "Zählmodus":
>      hier werden bereits nicht mehr alle einzelnen Impuls-Intervalle ausgewertet und übermittelt, sondern hier wird pro Intervall nur noch die Anzahl Impulse bestimmt; daraus wird dann die Leistung berechnet (Impulse/Zeit)
> ->  der Direktmodus würde nun also entfallen; das bedeutet:
> - wir müssen uns mal anschauen, wie sich das auf Darstellungen mit "hohem Zoom" auswirkt (also: wenig Impulse für das darzustellende Zeitfenster)
>    
Die Darstellung wird dann auch in diesem Bereich richtig. Ob "richtig" 
jetzt auch "schön" ist, darüber ließe sich noch streiten. Ich würde es 
bekanntlich sehr willkommen heißen.
> - bei der Auswertung können nicht mehr nur die Einträge gezählt werden:
>    SELECT * from public.pulses where id='$id' and servertime>  '$schritt_anfang' and servertime<  '$schritt_ende'
>    sondern man müsste pro Eintrag das Feld "count" aufsummieren
>    
Das sollte für die Datenbank fast keinen Unterschied ergeben, falls es 
keinen Index für "id" und "servertime" gibt, andernfalls würde ich es 
ihr aber trotzdem noch zutrauen.
> ->  die DB-Struktur müsste man also um das Feld "count" ergänzen
>    
Ja.
> Das wär's schon ;-)
>
> Das bedeutet, dass man mit der Wahl des Intervalls eben die Auflösung festlegt. Eine "bulk"-Übertragung ("1 impuls kam zu $zeitpunkt1; 1 impuls kam zu $zeitpunkt2; ...) halte ich für zu aufwändig. Wer eine höhere Auflösung haben möchte, sollte das Intervall entsprechend wählen.
>    
Genau meine Meinung, Du scheinst in unserer Diskussion die Seiten 
gewechselt zu haben.
> Ich finde es sehr schick, eine möglichst fein aufgelöste Darstellung zu haben - vielleicht sollte man das aber auch nicht überbewerten. Im Anhang zu Folien zum DFN-Workshop sind Graphen mit unterschiedlicher zeitlicher Auflösung zum Vergleich abgebildet. Wenn man sich das anschaut wird klar, dass 15 Minuten fast schon ausreichen; die reale Aussagekraft steigt m.E. damit nicht mehr besonders durch eine höhere Auflösung. Wenn man also 1 oder 5 Minuten wählt, sollte das wunderbar sein.
>    
Für nicht Zweierpotenz Sekunden Intervalle würden auch im Interrupt Code 
einige extrem schnell ausgeführte binäre Verundungen durch sehr langsame 
Divisionen ersetzt. Hier wäre noch zu schauen, ob man dadurch wieder 
Impulse verliert, oder sogar die Funktionsfähigkeit des Ethernets 
verliert. Zur Not müsste man hier noch einen zweiten Puffer einfügen, 
der wie bisher Zeitpunkte sammelt und dies dann in der Hauptschleife 
"konsolidieren"
Ein Nachteil ist der höhere Speicherverbrauch. Bei der 
Einzelimpulsvariante kann sich ein 644 64 Pufferspeicherplätze leisten. 
Wenn jetzt durchschnittlich alle 10 Sekunden ein Impuls kommt, können 
damit 640 Sekunden sekundengenauer Daten abgelegt, und Netzausfälle 
damit überbrückt werden. Die Sammelvariante ist derzeit noch auf die 
Überwachung von 8 Portpins ausgelegt (Und ich warte noch auf ein wenig 
M4 Unterstützung aus der Ethersex Ecke um dies zu ändern), damit bekomme 
ich mit etwas mehr Speicherbedarf 32 Pufferspeicher hin, damit lassen 
sich 32 Sekunden sekundengenauer Impulse speichern und damit 
Netzausfälle bis zu 32 Sekunden überbrücken. Das könnte unter Umständen 
für DSL Zwangstrennungen zu wenig sein.
Dafür würden bei der Einzelimpulsvariante die nicht mehr pufferbaren 
Impulse ignoriert, bei der Sammelmethode würden sie dem Intervall 32 
Sekunden später zugeschlagen. Damit bliebe die Summe bei einer Auflösung 
unter 64 Sekunden wieder korrekt, nur im "Nahbereich" gäbe es eine 
Verschiebung und die auch direkt um 32 Sekunden.

Gibt es jetzt pro Sekunde zehn Impulse lassen sich mit der 
Einzelimpulsvariante 6,4 Sekunden Puffern, mit der Sammelmethode bleibt 
es bei 32 Sekunden. Dazu käme noch, das die Sammelmethode auch nur 1 
Paket pro Sekunde verschicken müsste, das sollte gehen. Die 
Einzelimpulsmethode müsste 10 Pakete pro Sekunde verschicken, das geht 
nicht. Diese Impulsfrequenz darf also nur 5 Sekunden andauern, dann 
bräuchte sie erstmal 30 Sekunden, um sich zu "erholen".

Dreht man die Auflösung herunter gibt es auch direkt eine Entspannung: 
wenn man mit einer Auflösung von 64 Sekunden zufrieden ist, reicht der 
Puffer auch direkt für 32 * 64 = 2048 Sekunden. (Bei 10 Impulsen pro 
Sekunde müsste man hier allerdings die Zähler erweitern und käme nur 
noch auf 16 * 64 = 1024 Sekunden)

Die Auswahl hängt hier von zwei Kriterien ab: Wie genaue Daten möchte 
ich sammeln und preisgeben? (Den Einzelimpulszähler könnte man auch 
mühelos um die entsprechende "Unschärfe" ergänzen.)
Wieviele Impulse kommen in diesem Intervall durchschnittlich an? Sobald 
dies mehr als 2 sind, ist der Sammelzähler besser.
Ich bin noch mit dem Einzelimpulszähler zufrieden (Auflösung 1 Sekunde, 
ca. 1 Impuls/ 2 Sekunden)... Sehe aber auch, dass die Sammelvariante in 
vielerlei Hinsicht sehr schnell besser ist.

> Einverstanden?
>    
Schon lange!
> Hat jemand Lust, das im Controllercode zu implementieren?
>    
Für Watchasync ist es fast schon fertig...

  Bis bald,
   Jens Wilmer