Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 16 bis 30 von 49

Thema: KNX über IP mit 9600 Bit/s ??

  1. #16
    Registriert seit
    Jan 2001
    Ort
    Rickenbach Kt. Zürich - Schweiz
    Alter
    57
    Beiträge
    2.594
    Hallo Kollegen..

    "Dieser Beitrag wurde ausgeglichen bewertet" steht bei der Waage. Was meint der edle Spender der Bewertung damit? Er darf sich gerne dazu äussern. Es besteht immer noch Meinungsfreiheit.

    Gruss Peter
    Smart Building Design GmbH
    Konzeption, Planung, Bauherrenberatung, Baubegleitung, Consulting, Support, Ausbildung, technische Redaktion

    www.eib-home.de - www.knxshop4u.ch - www.smart-building-design.ch

  2. #17
    Registriert seit
    Jan 2004
    Ort
    Österreich, Steiermark
    Alter
    49
    Beiträge
    753
    Zitat Zitat von PeterPan Beitrag anzeigen
    Hallo Kollegen..

    Wasserhahn, Elektronen, .. sind wir Techniker oder was?
    Hallo Peter,

    also ich finde den Vergleich absolut in Ordnung :-)
    Bei meinen Cisco Unterlagen wird das Prinzip ebenfalls ähnlich erklärt (Stadtverkehr, Stau, ...)

    Aber um auf die eigentliche Frage zurück zu kommen:
    Wenn du Daten von einer 9600 Bit/s Quelle über ein Netzwerk sendest, dann hast du auf dem Netzwerk eine Datenübertragung von 9600 Bit/s.

    Kopiere eine Datei auf ein Netzlaufwerk ... wenn du dir die Details der Übertragungsrate anschaust, hast du auf einem 100 Mbit Netzwerk vielleicht 6-7 MB/s.
    Und nicht 100Mbit(12,5 MB/s) wie die Definition dies beschreibt.
    Dadurch wurde die Datei mit einer Geschwindigkeit von 6-7MB/s übertragen.

    Du hast keinerlei Geschwindigkeits-Zuwachs wenn du du 2 KNX Linien direkt mit einem Crossover zusammenhängst.

    Die Vorteile spielt man erst aus, wenn mehrere KNX Gateways/Komponenten das Medium Ethernet nutzen:
    3 Linien, Backbone Ethernet = 3x 9600 Bit/s = 28800 Bit/s (3600 KB/s = 0.003 MB/s)

    Theoretisch müsstest 87189 Gateway in einem Projekte haben, damit eine Übertragungsrate von 100 Mbit/s zustande kommt

    Wie du schon richtig sagtest, ist Kupfer so schnell wie eben Kupfer ist.
    Legt man ein EIB Kabel und ein Netzwerkkabel nebeneinander auf und schickt auf beiden Seiten 1 Bit rein, kommt es nach 100m zur selben Zeit 1 Bit raus an. Habe es damals bei Cisco gelernt, aber leider schon zu lange her, wieviele Nano Sekunden ein Bit dafür braucht.

    Der Unterschied zwischen beiden:
    EIB: kann 9600 Stk solcher Bits in einer Sekunde senden
    Ethernet: kann 838860800 Stk solcher Bits in einer Sekunde senden.

    Zitat Zitat von PeterPan Beitrag anzeigen
    Eine Drosselung der Geschwindigkeit auf IP? Wie soll das denn gehen? Da wären wir ja wieder bei meinem Eingangsthread! IP-Telegramme rasen mit IP-Geschwindigkeit. KNX-TP-Telegramme rasen mit KNX-TP-Geschwindigkeit. Ende.
    indem ein ICMP Befehl zum Sender geschickt wird, wo aufgefordert wird, die Sendeleistung pro Sekunde zu verringern, da die Daten nicht schnell genug verarbeitet werden können:
    http://de.wikipedia.org/wiki/Interne...ssage_Protocol
    (Typ 4, Code 0)
    Aber nicht die Übtragungsgeschwindigkeit wird gebremst, sondern die MENGE die übertragen wird. Dadurch wieder weniger MB/s als das Ethernet kann.
    Oder wie du geschrieben hast: Die Daten rasen immer noch mit IP Speed ... aber eben nicht mehr so viel.

    Gruß

    Hannes

    edit: Habe nochmal deinen Anfangsthread gelesen. Du verwechselst Geschwindigkeit (wie dein Beispiel mit dem Zug) mit Bandbreite (Bandbreite ist 9600 bit/s, bzw 100Mbit/s) http://de.wikipedia.org/wiki/Daten%C3%BCbertragungsrate.
    Geändert von Unique24 (12.09.08 um 17:12 Uhr)

  3. #18
    Registriert seit
    Jan 2001
    Ort
    Rickenbach Kt. Zürich - Schweiz
    Alter
    57
    Beiträge
    2.594
    Hallo Hannes..

    jetzt wird langsam ein Schuh draus.

    a) Übertragungsgeschwindigkeit, Übertragungsrate und Bandbreite wird eben gerne verwechselt. Auch in den Dokus der Hersteller.
    b) Verkehr und Stau ist ein guter Vergleich.

    ABER: Ungeklärt ist immer noch:
    • Wie kommt ein Klemmenhersteller resp. dessen Vertriebsleute auf die Aussage, dass es (die Übertragungsgeschwindigkeit) der Klemmenhersteller besser kann und man die anderen KNX-IP-Router einbremsen müsste?
    ÜBRIGENS: Heute erfuhr ich die Namen
    1.) des Integrators, der Firma und des Mitarbeiters
    2.) des Vertriebsmannes und des Klemmenherstellers.

    Ausserdem regt der Thread ausserhalb des Forums bereits zu regen Diskussionen an. Besser gesagt: "Er sorgt für Aufregung". Aber selbst hierbei wird der Thread nicht unbedingt gelesen, sondern durch "Hören-Sagen" etwas ganz anderes verstanden. Ich wurde heute bereits auf den Thread von Herstellerseite angesprochen.

    Anhang:
    I) WAGO KNX/EIB/TP1-Klemme 753-646; Technische Information/Datenblatt und Handbuch(Übertragungsrate KNX = 9,6 KBaud; Einsatz als Linienkoppler, Bereichskoppler, KNX-Interface; Anzahl Objekt = 253; Anzahl Gruppenadressen = 254; Anzahl Assoziationen = 254)
    II) WAGO KNX/IP Programmierbarer Feldbus-Controller; Technische Informationen
    (Übertragungsrate = 10/100 Mbit/s; Einsatz als Router mit KNX/EIB/TP1-Klemme 753-646; Anzahl Objekt = 253; Anzahl Gruppenadressen = 254; Anzahl Assoziationen = 254)
    KNX-Zertifizierung in Vorbereitung

    Nun die (rethorische) Frage in die Runde:
    a) Wie baut man daraus einen KNX/IP-Router?
    b) Und worin besteht der Unterschied in der Übertragungsrate/Geschwindigkeit/Bandbreite (1. KNX; 2. Ethernet) zu "den anderen" KNX/IP-Routern?

    Gruss Peter
    Smart Building Design GmbH
    Konzeption, Planung, Bauherrenberatung, Baubegleitung, Consulting, Support, Ausbildung, technische Redaktion

    www.eib-home.de - www.knxshop4u.ch - www.smart-building-design.ch

  4. #19
    GLT ist offline Registrierter Benutzer
    Registriert seit
    Jun 2004
    Beiträge
    1.279
    Die TP-Klemme kennt 2 Modi - in Verbindung mit einem KNX-Controller arbeitet die 1. Klemme immer im Routermodus (nicht konfigurierbar)

    Handbuch Routermodus

    weiter Klemmen (oder in Verbindung mit unterstützten Controllern) arbeiten im Gerätemodus

    Handbuch Gerätemodus

    Beachten sollte man auch das Konzept von WAGO
    WAGO KNX Konzept

    jm2c
    die Wagoprodukte sind weniger wegen der Routerfunktionalität interessant, sonder wegen der Möglichkeit Gateways zu bilden und gewisse Sonderfunktionalitäten mit freier SPS-Programmierung realisieren zu können

    Nachtrag:
    Vlt. liegt ein Missverständis darin, dass WAGO 100Mbit und z.B. Siemens für den N146 10Mbit angibt?
    Geändert von GLT (13.09.08 um 16:06 Uhr)
    Gruss
    GLT

  5. #20
    Registriert seit
    Jan 2004
    Ort
    Österreich, Steiermark
    Alter
    49
    Beiträge
    753
    Zitat Zitat von PeterPan Beitrag anzeigen

    Anhang:
    I) WAGO KNX/EIB/TP1-Klemme 753-646; Technische Information/Datenblatt und Handbuch(Übertragungsrate KNX = 9,6 KBaud; Einsatz als Linienkoppler, Bereichskoppler, KNX-Interface; Anzahl Objekt = 253; Anzahl Gruppenadressen = 254; Anzahl Assoziationen = 254)
    II) WAGO KNX/IP Programmierbarer Feldbus-Controller; Technische Informationen
    (Übertragungsrate = 10/100 Mbit/s; Einsatz als Router mit KNX/EIB/TP1-Klemme 753-646; Anzahl Objekt = 253; Anzahl Gruppenadressen = 254; Anzahl Assoziationen = 254)
    KNX-Zertifizierung in Vorbereitung
    Hallo Peter,

    das Thema Bandbreite ist dann geklärt, die Frage warum Router gebremst werden sollen, kann ich dir leider nicht beantworten.

    Aber eine Bemerkung möchte ich noch zu den Wago Klemmen machen.
    Wago und Beckhoff sollen ja ziemlich ähnlich oder gleich sein.

    Ich kenne die Wago nicht, aber die KL 6301 von Beckhoff.
    Bei der KL 6301 musst aufpassen:
    Zwar 256 Gruppenadressem empfangbar, ABER in 4 Quartette unterteilt, wo jeder wiederum eben 64 GA empfangen kann.

    Du kannst also nicht wilkürlich GA´s hinterlegen, sondern must sie in 4 Gruppen von a 64 GA´s (1/0/0-1/0/63, oder 1/5/101 - 1/5/164) eintragen.

    Vielleicht ist das bei der Wago nicht so, aber einen Blick drauf wäre eventuell wichtig!
    Ich konnte im letzten Moment noch ein Projekt umdrehen, wo ich den Einsatz dieser Klemme geplannt hatte.

    Schöne Grüße

    Hannes

  6. #21
    Registriert seit
    Jan 2001
    Ort
    Rickenbach Kt. Zürich - Schweiz
    Alter
    57
    Beiträge
    2.594

    KNX Beckhoff Klemme und Gruppenadressen

    Hallo Hannes..

    zur Beckhoff-Klemme. Bedeutet Deine Aussage, dass man bei den Gruppenadressen auf die genau Zurodnung der vier Gruppen festgelegt ist?

    Gruss Peter
    Smart Building Design GmbH
    Konzeption, Planung, Bauherrenberatung, Baubegleitung, Consulting, Support, Ausbildung, technische Redaktion

    www.eib-home.de - www.knxshop4u.ch - www.smart-building-design.ch

  7. #22
    Avatar von Dieter Koch
    Dieter Koch ist offline KNX-Professionals Firmenmitglied
    Registriert seit
    Nov 2000
    Ort
    Lehrte
    Alter
    61
    Beiträge
    1.727
    Zitat Zitat von Unique24 Beitrag anzeigen
    Zwar 256 Gruppenadressem empfangbar, ABER in 4 Quartette unterteilt, wo jeder wiederum eben 64 GA empfangen kann.

    Du kannst also nicht wilkürlich GA´s hinterlegen, sondern must sie in 4 Gruppen von a 64 GA´s (1/0/0-1/0/63, oder 1/5/101 - 1/5/164) eintragen.
    In meinen Augen ist das ein K.O.-Kriterium.

    Aber wir sind ja kommendes WE bei WAGO. Ich Frage da bestimmt.

    Gruß
    Dieter
    Erfahrung ist die Summe aller Missgeschicke

  8. #23
    Registriert seit
    Jan 2004
    Ort
    Österreich, Steiermark
    Alter
    49
    Beiträge
    753
    Guten Morgen Peter und Dieter,

    ja so ist es ... man kann bei der Beckhoff KLemme nicht willkürlich GA nutzen. Sie müssen hintereinander in 4 Gruppen zu je 64 GA´s sein.

    Würde mich interessieren ob dies bei Wago auch so ist.
    Es hat etwas mit Filtern und Performance zu tun.

    Gruß


    Hannes

  9. #24
    Registriert seit
    Jan 2001
    Ort
    Rickenbach Kt. Zürich - Schweiz
    Alter
    57
    Beiträge
    2.594
    Beckhoff ist somit aus dem Rennen. Es gibt kein mir bekanntes Projekt indem die Gruppenadressen fest zugeordnet werden. Es sei denn der Beckhoff-Planer plant das und schreibt das gleich mal vor. Nun verstehe ich auch, weshalb auf den Projekten Beckhoff-Mitarbeiter die Controller in Betrieb nehmen.

    Bei Wago läuft die Kommunikation zwischen KNX und Controller via "Universalbaustein" für "Alle DTPs". (Laut Doku)

    Aber vielleicht kann das ein Fachmann beantworten? Es lesen bestimmt genug mit.

    PS: Warum soll nun bitte der WAGO-LK schneller sein, als die anderen IP-LK-Produkte? (Nur mal so, die Frage ist immer noch ungeklärt.)

    Gruss Peter
    Smart Building Design GmbH
    Konzeption, Planung, Bauherrenberatung, Baubegleitung, Consulting, Support, Ausbildung, technische Redaktion

    www.eib-home.de - www.knxshop4u.ch - www.smart-building-design.ch

  10. #25
    Registriert seit
    Jan 2004
    Ort
    Österreich, Steiermark
    Alter
    49
    Beiträge
    753
    Hallo Peter,

    keine definitive Aussage, aber eventuell gibt auch hier parallelen:
    Netzwerk: Bei Switchen gibt es mehrere Moden:
    * Store and Forward
    * Cut-Through
    * Fragment-Free

    Je nachdem welcher Switch eingesetzt wird, ist dieser schneller oder langsamer als der andere, weil er eine andere Switching Methode nutzt (Cut-Through ist das schnellste, Fragment-Free das Mittlere und Store and Forward das langsamste)

    Ditto wird es auch bei Router Qualitätsunterschiede geben. Vor allem die Leistung der Geräte hat Einfluss auf die Performance.

    Vielleicht arbeiten die Wago ohne eine Checksum zu prüfen oder haben einfach nur eine bessere Performance.

    Vielleicht auch nur in der Theorie schneller

    Gruß

    Hannes

  11. #26
    Registriert seit
    Jan 2001
    Ort
    Rickenbach Kt. Zürich - Schweiz
    Alter
    57
    Beiträge
    2.594
    Hey Hannes..

    "vielleicht kann man nach wissenschaftlichen Untersuchungen mit an Sicherheit grenzender Wahrscheinlichkeit ausschliessen, dass die Geräte nach besten Wissen und Gewissen nicht mit der gleichen Methode arbeiten - zumindest im Rahmen ihrer Möglichkeiten".

    Mit Vermutungen und Mutmassungen kommen wir nicht weiter. Ich möchte harte Fakten hören, sehen, lesen, verstehen.

    Gruss Peter
    Smart Building Design GmbH
    Konzeption, Planung, Bauherrenberatung, Baubegleitung, Consulting, Support, Ausbildung, technische Redaktion

    www.eib-home.de - www.knxshop4u.ch - www.smart-building-design.ch

  12. #27
    Registriert seit
    Jan 2002
    Beiträge
    2

    Klarstellung zum Thema KNXnet/IP

    Das Thema KNXnet/IP ist sehr komplex. Deshalb ist es auch sehr leicht, aneinander vorbei zu reden. Aber dem Ruf nach Fakten will ich hiermit gerne nachkommen:

    In den vorherigen Beiträgen ist schon Vieles sehr richtig dargelegt worden. Um das auch richtig einordnen zu können, bedarf es leider etwas mehr als „Physik, 5. Klasse“. Grundlegende Voraussetzung ist dabei ein Verständnis des OSI Schichtenmodells (siehe Wikipedia).

    Jetzt von Anfang an:
    Auch KNX Kommunikation folgt einem Schichtenmodell. Das Ziel ist es, eine Nutz-Information (die auch sehr klein sein kann, wie z.B. "aus" als 1 Bit) von einer Anwendung zu einer andern zu transportieren. Im Falle von KNX könnte das Betätigen eines Lichtschalters eine solche "1 Bit" Information von einem Taster an einen Aktor kommunizieren wollen. Auf dem Weg vom Taster zum Aktor durchläuft diese 1 Bit Information den KNX Stack im Taster von oben, dem Application Layer bis nach unten zum Physical Layer und jede Schicht fügt ihrer Schicht zugeordnete Informationen hinzu: Was mit den Daten passieren soll, Adressinformationen, etc. Auf dem Physical Layer (im Deutschen schön Bitübertragungsschicht) ist nun aus dem einen Bit Nutzdaten ein sogenanntes Telegramm von etwa 72 Bit Länge geworden, das Bit für Bit auf das Medium geschrieben wird. Im Falle von TP1 mit 9.600 Bits pro Sekunde. Mit dieser Geschwindigkeit rauscht es auch beim Empfänger, dem Aktor vorbei. Der erkennt, dass das Telegramm an ihn gerichtet ist und leitet es Schicht um Schicht seinen KNX Stack nach oben, bis das Relais klackt und die 1 Bit Nutzdaten wunschgemäß verarbeitet wurden.

    Was hat das mit KNXnet/IP zu tun?
    Das mag man sich fragen. Aber offensichtlich gibt es verschiedene "Übertragungsgeschwindigkeiten" auf den verschiedenen Layern. Will heißen: Niemand kann so schnell Taster drücken (wieviel Bit pro Sekunde gehen da wohl ), dass er die 9.600 bps des TP1 ausreizt und niemand kann so schnell Briefe schreiben, wie der Briefträger, der Post LKW oder das Flugzeug diese transportiert. Und genauso wird mein Internet zu Hause nicht schneller, wenn ich zwischen Router und PC eine Gigabit Ethernet Verbindung anstelle einer 100 MBit Verbindung habe. Die Nutzdaten (der Internetverkehr) werden dabei vielleicht schneller zwischen Router und PC gesendet, aus dem Internet kommen sie aber immer noch "nur" mit meiner DSL Geschwindigkeit.

    Wie sieht es nun mit KNXnet/IP aus?
    Auch hier haben wir ein IP Netzwerk. Je nachdem, auf welchem Medium dieses läuft, hat es unterschiedliche "Übertragungsgeschwindigkeiten" auf den unterschiedlichen Layern. Zum Tragen kommt dabei, dass das gesamte KNX Telegramm (bis zum Data Link Layer) nun die Nutzdaten des IP Stacks sind. Ich habe versucht, das mit dem Diagramm auf Seite 13 links oben im KNX Journal 1/08 zu verdeutlichen. Mit welcher Geschwindigkeit werden nun diese Nutzdaten generiert? Ein IP Router erhält seine Daten ja vom angebundenen KNX Bus. Im Falle eines KNXnet/IP Routers ist es also für die KNX Übertragung unerheblich, ob er mit 10 MBit, 100 MBit oder gar Gigabit angeschlossen ist. Er wird immer maximal 9.600 Nutzbits pro Sekunde oder 50 Telegramme pro Sekunde "aufs IP schreiben" können (die dann weiter unten im IP Stack mit der physikalischen Geschwindigkeit des jeweiligen Mediums übertragen werden). Das ist nur ein sehr marginaler Anteil der theoretisch möglichen "Bandbreite" seiner physikalischen Ethernet Anbindung.

    Wo liegen dann die Vorteile eines IP Backbone?
    Jetzt kommt die Bandbreite ins Spiel und das Analogon der Autobahn: Auf einem TP1 Backbone konnten immer nur alle gemeinsam die verfügbare Bandbreite von 9.600 bps nutzen. Eine einspurige Autobahn, auf der alle brav Kolonne fahren. Wenn viel los ist, steht man schon mal länger auf der Autobahnauffahrt und muss warten bis eine Lücke frei ist. Auf einer vielspurigen Autobahn hingegen wird derjenige, der von A nach B will, nicht mehr von all den Anderen gestört, die nach C, D oder sonst wohin wollen. Sie bietet also Platz, um ungestört mehrere Übertragungen parallel zu fahren.

    Problematisch wird es nur, wenn von der breiten Autobahn plötzlich sehr viele Autos gleichzeitig dieselbe Ausfahrt nehmen wollen. Die ist aber wieder nur einspurig und kann nur (Achtung, jetzt sind wir wieder in der KNX Welt) 9.600 bps übertragen. Hier müssen also Puffer her, um solche Peaks abzufedern. Bei der Dimension der Puffer muss man abwägen zwischen zu kleinen Puffern, die evtl. nicht alle Telegramme eines Schwalls aufnehmen können (und es zu Telegrammverlust kommt) und zu großen Puffern, die zu einer entsprechenden Verzögerung bei der Zustellung führen.

    Können KNX-IP Geräte untereinander mit 100 MBit/s Nutzdaten kommunizieren?
    Leider nein. Und dafür gibt es vielfältige Gründe. Der zentrale Grund ist dabei die spezielle Art der IP Kommunikation, die KNXnet/IP quasi vom KNX Bus geerbt hat: Das Multicasting. Normalerweise ist IP Kommunikation Punkt-zu-Punkt orientiert. Das heißt, dass ein Sender seine Daten an genau einen Empfänger richtet. Niemand sonst im Internet bekommt glücklicherweise etwas davon mit, wenn Sie im Online-Banking ihrer Bank eine Überweisung übermitteln. Beim KNX ist das anders. Eine Nachricht an eine „Gruppe“ (da steckt das schon drin) wird nur ein einziges Mal auf den Bus geschrieben und Jeder am Bus wird sie auch erhalten. Auf IP nutzt man hierfür spezielle Adressen (Class D Adressen), die ein Teilnehmer im IP Netz zusätzlich zu einer bekannten IP Adresse erhält. Telegramme an diese Multicast Adressen werden auch quasi überall hin verteilt, so dass alle Teilnehmer am Netz die Möglichkeit erhalten, diese mitzuhören, denn es könnte ja etwas Interessantes für sie dabei sein.

    Einen entscheidenden Unterschied haben allerdings die Gruppenkommunikation auf dem Bus und die Multicast Kommunikation auf dem IP: Auf dem Bus erfolgt die Datenübertragung quasi synchron. Wenn einer etwas schreibt, bekommen es alle anderen Teilnehmer zeitgleich mit und alle betroffenen Teilnehmer schreiben gleichzeitig (im Takt) ihre Bestätigung für das Telegramm. Auf dem Bus entsteht dabei ein einziges Bestätigungstelegramm als Summe aller Bestätigungen (Fehler wie BUSY oder NACK überschreiben dabei ein positives ACK). Die Übertragung auf dem IP ist aber asynchron. Gäbe es Bestätigungen bei KNXnet/IP, so gäbe es pro Teilnehmer am KNXnet/IP Backbone ein separates Bestätigungstelegramm, die der Sender alle einzeln auswerten müsste. Da so ein Verfahren nicht skaliert, gibt es faktisch keine Telegrammbestätigung im KNXnet/IP Backbone. Außerdem bedingt die Adressierung per Multicast die Verwendung von UDP, so dass die IP-eigene Verbindungssicherung mittels TCP auch nicht zum Einsatz kommen kann. KNXnet/IP Geräte müssen also darauf „vertrauen“, dass das, was sie auf das KNXnet/IP Backbone schreiben, auch wirklich von allen Teilnehmern empfangen und verlustlos verarbeitet wird/werden kann.

    Mit KNXnet/IP Routern gab es nur KNXnet/IP Geräte, die durch ihre KNX Busanbindung quasi eine eingebaute Telegrammratenbegrenzung hatten. Mehr als etwa 50 Telegramme pro Sekunde konnte ein Gerät nicht senden. KNX-IP Geräte ohne Busanschluss haben eine solche „Drossel“ aber nicht mehr. Wenn ein solches Gerät meint, 10, 20 oder mehr Telegramme auf einmal senden zu wollen (Stichwort Zentralfunktion), dann könnte es dies theoretisch mit maximaler Ethernetgeschwindigkeit tun. Andere KNX-IP Geräte hätten vermutlich damit auch keine Probleme, müssen die Telegramme aber auf den Bus, könnten die Puffer der KNXnet/IP Router hingegen auf einen Schlag vollgeschrieben sein und es zu Telegrammverlusten kommen. Es besteht also durchaus ein Interesse daran, potentiell zu routende Telegramme, die auf den KNXnet/IP Backbone geschrieben werden, entweder inhaltlich (ich weiß, was ich tue) oder technisch (es werden nicht mehr zugelassen) so zu beschränken, dass es zu keinem Pufferüberlauf kommt.

    Aber 2 KNX-IP Geräte könnten sich schnell unterhalten, ohne einen Router zu stören?
    Nein. Jetzt kommt der letzte, große Faktor beim Thema KNXnet/IP ins Spiel: Da KNXnet/IP Router keine 5stelligen Beträge kosten sollen und der Schaltschrank nicht zum wassergekühlten 19-Zoll Rack mutieren soll, kommen in den KNXnet/IP Geräten Ethernet Chips und Embedded Prozessoren zum Einsatz, die natürlich leistungsbeschränkt sind. Deshalb hat man auch keinen Cisco 19-Zoll Router zu Hause, sondern eine FritzBox. Systembedingt ist die verarbeitbare Bandbreite in den CPUs über deren Datenleitungen geringer als die theoretisch mögliche Nutzdatenlast ihrer Ethernet Anbindungen. Jedes Telegramm auf dem KNXnet/IP Backbone (nicht jedes Telegramm auf dem Ethernet, das filtert der Ethernet Chip schon grob aus) muss von der CPU entgegengenommen und analysiert werden, ob das KNX-IP Gerät adressiert ist, oder nicht. Das kann man vergleichen mit einer Zählung von Autos. Auf einer einspurigen Landstraße hat man alle roten PKWs mit Flensburger Kennzeichen noch im Griff. Doch auf einer 6-spurigen Autobahn kommt man, auch wenn man die andersfarbigen Autos von vorne herein aussieben kann, schon nicht mehr hinterher, jeden roten PKW anzuvisieren und das Nummernschild zu inspizieren. Selbst wenn man die Zählung in Zürich macht, wo mit sehr wenig Flensburger Autos zu rechnen ist, kann die Anzahl roter Autos schon so hoch sein, dass einem das eine Flensburger dann doch durch die Lappen geht.

    Fazit:
    Das Thema KNXnet/IP ist sehr komplex (Belegung der Einleitung ). Bedingt durch die Eigenheiten des KNX Busses und die Verwendung von UDP Multicast beim KNXnet/IP Protokoll kann es sehr wohl vollkommen unabhängig von der Busverbindung und der Ethernet Bandbreite architekturell bedingte Unterschiede bei den KNXnet/IP Geräten geben. Eine „Gleichschaltung“ unterschiedlicher Systemgeräte ist durch die Rahmenvorgaben der KNX Association zu Gunsten der Systemstabilität aber gewollt und kein Makel .

    Gruß,
    Elwedritsche

  13. #28
    Registriert seit
    Jan 2001
    Ort
    Rickenbach Kt. Zürich - Schweiz
    Alter
    57
    Beiträge
    2.594
    Hallo "ElWeDrItsche"..

    Zuerst hier der Link zum KNX-Journal 01/2008, in welchem die erwähnte Grafik auf Seite 13 des Dokumentes abgebildet ist.

    Es freut mich, dass sich ein Mitglied der KNX-Systemarchitektur-Gruppe hier im Forum zu den Fakten äussert. (Odrrr?)

    Noch dazu, wenn ein so "komplexes" Thema dermassen anschaulich präsentiert und ausführlich mit Beispielen und Vergleichen erklärt wird.

    Ihren Ausführungen entnehme ich resp. fasse ich zusammen, dass die KNXnet/IP-Spezifikation keine unterschiedliche Geschwindigkeit für Telegramme unterschiedlicher Hersteller zulässt. Liege ich da richtig?

    PS: Sie dürfen sich ruhig "outen"; denn wir haben hier keine Geheimnisse und das Forum ist so offen, wie das KNX-System selbst.

    Gruss Peter

    PS: "komplex" oder Komplexität (v. lat.: complectari = umarmen, umfassen; Partizip Perfekt: complexum) bezeichnet allgemein die Eigenschaft eines Systems oder Modells, dass (in) sein(-em) Gesamtverhalten nicht beschrieben werden kann, selbst wenn man vollständige Informationen über seine Einzelkomponenten und ihre Wechselwirkungen besitzt.

    Das Adjektiv "komplex" wird im allgemeinsprachlichem Gebrauch leider häufig fälschlicherweise für die Eigenschaft von Systeme oder Modelle verwendet, auch wenn die Beziehungen zueinander oder die Funktion der Einzelkomponenten sehrwohl klar definiert sind oder abgeleitet werden können. Dies trifft auch im Fall von KNXnet/IP zu; denn das System bzw. die Übertragung von Telegrammen ist genau spezifiziert und nachvollziehbar. Quad erat demonstrandum.
    Geändert von PeterPan (18.09.08 um 22:32 Uhr)
    Smart Building Design GmbH
    Konzeption, Planung, Bauherrenberatung, Baubegleitung, Consulting, Support, Ausbildung, technische Redaktion

    www.eib-home.de - www.knxshop4u.ch - www.smart-building-design.ch

  14. #29
    Registriert seit
    Mar 2008
    Ort
    Binningen
    Beiträge
    12
    Zitat Zitat von elwedritsche Beitrag anzeigen
    Bei der Dimension der Puffer muss man abwägen zwischen zu kleinen Puffern, die evtl. nicht alle Telegramme eines Schwalls aufnehmen können (und es zu Telegrammverlust kommt) und zu großen Puffern, die zu einer entsprechenden Verzögerung bei der Zustellung führen.
    Das verstehe ich nun nicht ganz: Entweder habe ich einen Hardwarepuffer, da wird vielleicht noch durchgereicht. Ein Hardwarepuffer (FIFO) ist aber in der Regel nicht sehr gross und deshalb sind die Laufzeiten verglichen mit z.B. 9600 bit/s vernachlässigbar. Grosse Puffer wird man allgemein in Software in normalem Speicher und als Ringpuffer realisieren. Dann gibt es ein paar Zeigeroperationen ohne Durchreichen und die Geschwindigkeit ist von der Puffergrösse unabhängig.

    Gruss
    Christian

  15. #30
    Uwe! ist offline Registrierter Benutzer
    Registriert seit
    Jan 2007
    Ort
    Neunkirchen
    Alter
    55
    Beiträge
    271
    Verzögerung bei der Zustellung weil die Pakete die mit 100MBit angerauscht kommen sich an der Austobahnausfahrt in den 9.600kBit Stau stellen müssen. Und dann kann es dauern, bis der letzte die Autobahn verlassen hat.

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Lesezeichen

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •