ElabNET Technik Forum

Werte Foristen,

vermutlich eine doofe Frage aber weiß jemand was die Buslauslastung bedeutet bzw. wie diese berechnet wird? Wenn ich mir die Werte bei meinen drei Schnittstellen ansehe dann kommt mir das unplausibel vor. 1 Sensor soll eine halb so hohe Auslastung machen wie 28? Grüße
Peter

Ohne jetzt Experte zu sein, würde ich sagen das ganze hat direkt/indirekt zwei Dimensionen. Was davon gemessen und angezeigt wird, wäre zu klären.

a) die elektrische Belastung des Kanals, die halt sehr von Typen und Anzahl der Sensoren abhängt.
b) die Signaldichte welche vom Abfragezyklus und dann natürlich ebenso der Anzahl Sensoren ist. Bei kurzem Zyklus und vielen Sensoren, kann es sein das innerhalb eines Zyklus gar nicht alle Sensoren einmal abgefragt werden können, damit wäre der Kanal für mich bei 100% Auslastung.

Ich hatte mal mit StefanW darüber gesprochen und er sagte, dass der Auslastungswert vom OWFS übernommen wird. Auf Anhieb konnte er damals auch nicht konkretisieren was die Auslastung genau darstellt.

Das ist ein Thema, das auch mir schon seit sehr langer Zeit am Herzen liegt. Du wirst durch Suchen hier im Form auch einige Beiträge von mir mit Screenshots finden. Die sind teilweise noch extremer als Deine Beispiele.

Ohne weitere Erklärung zu der Bedeutung der Auslastungsanzeigen habe ich auch schon dazu plädiert, die Auslastungsanzeigen von der Seite zu nehmen, weil Sie keinen sinvollen Mehrwert bieten und im schlimmsten Fall dazu ermutigen zu niedrige Einstellungen für die Sensor-Regeln zu wählen (man wägt sich im sicheren grünen Bereich). Bei mir sind beispielsweise alle drei Kanäle im grünen Bereich und dennoch schafft der Scheduler (es gibt übringens nur einen für alle drei Kanäle, deshalb beeinflussen sich die drei Kanäle auch auf jeden Fall) die von mir gewünschten Poll-Zyklen einzuhalten (und ich habe den Wunsch schon massiv reduziert und nach dem Import vom Wiregate-Server in der Betaphase auch sehr viele Regeln löschen müssen und können). Für Applikationen, wo ich gewisse Zyklen haben will, nutzte ich inzwischen KNX-Sensoren.

Nur dass es nicht falsch verstanden wird: Ich beschwere mich hier nicht über die Performance des Busmasters. Nur hilft mir die Auslastungs-Anzeige leider überhaupt nicht bei den Fragen: Kann ich noch einen weiteren 1wire Sensor anschließen? Kann ich den Poll-zyklus eines Sensors reduzieren und was passiert dann am Bus? Und dazu sollte eine Auslastungsanzeige meiner Meinung nach eben dienen. [persönliche Meinung]

Ja. Da es nur einen scheduler gibt. Ist diese Anzeige nichtssagend.
Die Frage danach bzw. die Konsequenz daraus ist schon sehr oft angesprochen wurden. Vll gibt's irgendwann Mal dazu eine befriedigendere Lösung.

[Ich habe z.B. mir irgendwann Mal in einer Aktion einen 2. PBM mit endless Option gekauft. Hier war ich der Meinung, dass man pro PBM die Sensoren abfragt. Aber selbst für meine 6 Kanäle gibt es nur einen den Fahrplan macht.]

Guten Morgen,

bin etwas in Eile, hier ein paar kurze Infos:

1. Die Auslastungsanzeige stammt aus dem OWFS. Wie diese den Wert generiert wissen wir nicht genau. In unseren Labortests schien das eine mittelmäßig brauchbare Anzeige zu sein. Das mag bei Euch zum Teil anders aussehen, beruht aber auf den jeweiligen Einstellung und persönlichen Bewertungen und ist nicht leicht vergleichbar.

==> Wir überlegen die Anzeige durch eine bessere Anzeige zu ersetzen, aber kurzfristig wollen wir erst mit anderen Themen vorankommen


2. Es spielt keine große Rolle, dass es nur eine Instanz des OWFS und des Schedulers gibt, das sagt nichts über die Implementierung aus. Beide Komponenten sind in der Lage, mehrere Abfragen parallel auf die Busmaster zu verteilen und auszuführen und nehmen dies auch so vor.

Hier ein Wolf, der mit 170 Sensoren an 17 Busmasterkanälen ausgestattet ist, mit teils heftig kurzen Zyklen bei maximaler 12 Bit Auflösung (und keine Probleme hat):



==> Der eine Scheduler und das eine OWFS können das durchaus alles handeln. Womöglich braucht man bei sehr kurzen Zyklen mehr Busmaster und sicherlich kann man Anzeigen auch noch verbessern, aber es ist nicht so, dass es nicht funktioniert.

FabKNX hat geschrieben: ↑Di Jan 05, 2021 10:58 pm[Ich habe z.B. mir irgendwann Mal in einer Aktion einen 2. PBM mit endless Option gekauft. Hier war ich der Meinung, dass man pro PBM die Sensoren abfragt. Aber selbst für meine 6 Kanäle gibt es nur einen den Fahrplan macht.]

Du hast das völlig richtig gemacht. Mit dem zweiten PBM hast Du die Anzahl der gleichzeitigen Abfragen verdoppelt (bei entsprechender Aufteilung).

An einem Bahnhof können auch mehrere Züge fahren. Das ist hier auch so. Der Scheduler betreut alle Fahrpläne gleichzeitig und startet die Aufträge gegenüber dem OWFS, das mehrere Abfragen parallel gegenüber den Busmastern und den Slaves handelt.

Wir haben also nicht nur einen Fahrplan.... wie auch, jeder Sensor kann seinen eigenen Zyklus haben.


lg

Stefan

Vielen Dank für die Infos!

Ich habe es bisher wie Robosoc gemacht und dachte es ist ausreichend Buskapazität vorhanden und habe daher die Pollzyklen reduziert. Musste aber feststellen dass sie nicht eingehalten werden können obwohl man laut Auslastungsanzeige massig Ressourcen frei hat.

Robosoc hat geschrieben: ↑Di Jan 05, 2021 9:47 pm Nur hilft mir die Auslastungs-Anzeige leider überhaupt nicht bei den Fragen: Kann ich noch einen weiteren 1wire Sensor anschließen? Kann ich den Poll-zyklus eines Sensors reduzieren und was passiert dann am Bus? Und dazu sollte eine Auslastungsanzeige meiner Meinung nach eben dienen. [persönliche Meinung]

Falls es Jemanden interessiert: Es ist möglich sich in Grafana auf relativ einfach Weise eine Auswertung zu schaffen, die ermittelt in welchen Zeitabständen Werte auf den KNX-Bus geschrieben werden. Da ich fest davon ausgehe, dass der zeitliche Versatz (Verzögerung) innerhalb des TWS von 1w zu KNX sehr gering ist, kann diese Auswertung eine Indikation dafür sein, wie ausgelastet der 1-wire Bus, Busmaster oder Scheduler tatsächlich ist und ob die in den Regeln eines Sensors eingestellten Zykluswerte relativ gut eingehalten werden oder eben nicht. Dies reicht meines Erachtens dafür aus sich ein grobes Bild zu machen. Es ging mir dabei nicht um Optimierungen in einzelne Sekunden.

Siehe dazu den Hinweis ganz am Ende des folgenden Posts :
viewtopic.php?f=22&t=998&hilit=busmaster+poll#p10121

In dem Beitrag 1 und 3 dort sieht man auch, dass ich damals Sensoren hatte, die bei einem eingestellten Wunsch-Zyklus von 30s eher nur alle 400s, 200s und später nach Reduktion von Regeln etwa 100s (Schwankend zwischen 70 und 145 s) ausgelesen werden konnte . Der Kanal des Busmasters war in den 30er% ausgelastet angezeigt!

Hallo Stefan

StefanW hat geschrieben: ↑Mi Jan 06, 2021 6:49 am Hier ein Wolf, der mit 170 Sensoren an 17 Busmasterkanälen ausgestattet ist, mit teils heftig kurzen Zyklen bei maximaler 12 Bit Auflösung (und keine Probleme hat):

Das klingt natürlich toll und natürlich ist das dazu auch noch abhängig davon, wie optimal die Verkabelung zu den Sensoren realisiert wurde, die bei mir definitiv leider sehr unvorteilhaft ist was mir durchaus bewusst ist. Aber nur die Anzeigen, die Du gepostet hast, sagen ja leider nichts über die tatsächliche Performance aus. Keine der Anzeigen bestätigt, dass die eingestellten "teils heftig kurzen Zyklen" auch tatsächlich realisiert werden oder zumindest mit welcher Standardabweichung. Meine Anzeigen auf den Seiten des TWS waren auch alle grün und niedrig und dennoch wurden die Sensoren mit einer Standardabweichung von mehreren 100% ausgelesen. Und wenn ich 30 als Zykluszeit vorgebe und ein Wert nur alle 100 s ausgelesen werden kann, dann müssten doch eigentlich auch mindestens 2 Werte nicht angekommen sein und dann müsste nicht nur die Auslastung hoch sein, sondern nach meinem Verständnis auch die Anzeige der Sensor-Qualität und die -Historie müsste doch rote Balken zeigen. Tut Sie aber meines Erachtens nicht (habe ich aber heute nicht neu getestet, entstammt älteren Erfahrungen).

Hallo Stefan,

StefanW hat geschrieben: ↑Mi Jan 06, 2021 6:49 am Es spielt keine große Rolle, dass es nur eine Instanz des OWFS und des Schedulers gibt, das sagt nichts über die Implementierung aus. Beide Komponenten sind in der Lage, mehrere Abfragen parallel auf die Busmaster zu verteilen und auszuführen und nehmen dies auch so vor.

Ich bekomme diese Information noch nicht ganz Zusammen mit einem Informations-Austausch, den wir vor langer Zeit hatten.

StefanW hat geschrieben: ↑Di Okt 01, 2019 9:41 am

Robosoc hat geschrieben: ↑Di Okt 01, 2019 8:43 amDazu kommt, dass ich ja inzwischen merke, dass der im TWS950 verbaute Busmaster nur einen Sensorscheduler für alle drei Kanäle hat und ich somit jetzt schon (verminderter Sensor-Einsatz) die gewünschten Sensorabtastzeiten nicht mehr realisieren kann (habe dazu ja auch einen Threat mit Gabi)

Das ändert sich auch mit weiteren angesteckten Busmastern nicht. Im 1-Wire ist - durch das Plug´n´Play und die Möglichkeit dass der Kunde jederzeit einfach alles beliebig umsteckt EIN (1) Scheduler für das ganze 1-Wire zuständig. Eine Aufteilung in Subsysteme haben wir hier nicht.

Zitat ist aus dieser Diskussion entnommen: viewtopic.php?p=15414#p15414

Mach ich jetzt einen Gedankenfehler oder widerspricht sich das? Vielleicht habe ich es auch damals einfach falsch verstanden. Vielleicht habt Ihr inzwischen aber auch einfach neue Erkenntnisse. Kannst Du dazu noch ein wenig mehr Erklärung schreiben?

Aufgrund dieser Rückmeldung hatte ich damals nicht mal probiert meinen alten PBM (vom Wiregate) zusätzlich anzustecken und damit die Zykluszeiten zu verbessern. Ich habe ihn dann leider damals mit meinem Wiregate-Server an Euch zurückgesendet.