-> Hier kostenlos registrieren
Hallo Jochen,
so wie du schreibst, hast du natürlich recht, in dem Fall kommt man auf eine maximale sinnvolle Lücke von 10 Bytes. Dann passen 17 Antworten in eine PDU.
Bei mir ist der Fall etwas anders gelagert. Hier werden ca. 10.000 Variablen gelesen. Diese sind bunt im Speicher verteilt und haben unterschiedlichste Länge und Abstände. Statistisch gesehen habe ich dann Lücken zwischen 0 und 20 Bytes, welches im Mittel 10 ist. Es muss natürlich schon bei der Anfrage sichergestellt sein, daß die Länge der Antwort nicht überschritten ist. Die Prüfung muss sowieso stattfinden, da auch einzelne Bereiche mit einer Länge von z.B. 100Bytes gelesen werden.
Wenn auf diese Weise zwei nahe beieinander liegende Tags in einen Request gepackt werden, dann kann ich sogar mehr als 17 Tags in eine PDU packen.
Das ganze funktioniert aber nur effektiv, wenn ich die Tags in einer übergeordneten Klasse entsprechend vorsortiere.
Ein Rechenbeispiel:
Normalerweise bekomme ich in eine PDU (240-18)/12=18 Requests. In der Antwort braucht das 18*(4+data) =108 Bytes. Damit ist aber noch massig Reserve für weitere Daten. Wenn ich nun noch ein paar Tags finde, die mit einer Lücke von z.B. 20 Bytes mitgelesen werden können, dann kann ich mit der selben Anzahl Requests noch >=4 weitere Tags mitlesen.
Fazit:
Im worst case, wenn die Lücken immer genau 20Bytes sind, mache ich natürlich Verlust. Im statistischen Mittel habe ich jedoch das Optimum, wenn ich Lücken bis zu 20 Bytes zulasse. Die 20 Bytes sind empirisch ermittelt für meinen Anwendungsfall das Optimum. Ich will nicht behaupten, daß das allgemeingültig ist.
so wie du schreibst, hast du natürlich recht, in dem Fall kommt man auf eine maximale sinnvolle Lücke von 10 Bytes. Dann passen 17 Antworten in eine PDU.
Bei mir ist der Fall etwas anders gelagert. Hier werden ca. 10.000 Variablen gelesen. Diese sind bunt im Speicher verteilt und haben unterschiedlichste Länge und Abstände. Statistisch gesehen habe ich dann Lücken zwischen 0 und 20 Bytes, welches im Mittel 10 ist. Es muss natürlich schon bei der Anfrage sichergestellt sein, daß die Länge der Antwort nicht überschritten ist. Die Prüfung muss sowieso stattfinden, da auch einzelne Bereiche mit einer Länge von z.B. 100Bytes gelesen werden.
Wenn auf diese Weise zwei nahe beieinander liegende Tags in einen Request gepackt werden, dann kann ich sogar mehr als 17 Tags in eine PDU packen.
Das ganze funktioniert aber nur effektiv, wenn ich die Tags in einer übergeordneten Klasse entsprechend vorsortiere.
Ein Rechenbeispiel:
Normalerweise bekomme ich in eine PDU (240-18)/12=18 Requests. In der Antwort braucht das 18*(4+data) =108 Bytes. Damit ist aber noch massig Reserve für weitere Daten. Wenn ich nun noch ein paar Tags finde, die mit einer Lücke von z.B. 20 Bytes mitgelesen werden können, dann kann ich mit der selben Anzahl Requests noch >=4 weitere Tags mitlesen.
Fazit:
Im worst case, wenn die Lücken immer genau 20Bytes sind, mache ich natürlich Verlust. Im statistischen Mittel habe ich jedoch das Optimum, wenn ich Lücken bis zu 20 Bytes zulasse. Die 20 Bytes sind empirisch ermittelt für meinen Anwendungsfall das Optimum. Ich will nicht behaupten, daß das allgemeingültig ist.