Archiv verlassen und diese Seite im Standarddesign anzeigen : KNX über IP mit 9600 Bit/s ??
Hallo Kollegen..
was mich mal so nebenbei interessieren würde: Wer setzt eigentlich so dämliche Gerüchte in die Welt, welche allein schon nach den physikalischen Gesetzen ohne menschlichen Verstand zu wiederlegen wären. Nein, eigentlich denke ich eher darüber nach, wer den Krampf glaubt. Aber egal. Ich bin ganz hin- und hergerissen.. Aber der Reihe nach.
Neuester Gag des Tages:
Da erzählte mir doch tatsächlich ein Kunde so nebenbei am Messestand, allen Ernstes und voller Überzeugung, dass bei den KNX/IP-Geräten die Telegramme nur mit 9600 Bit/s über Ethernetkabel übertragen werden! Das hätte ihm ein Mitarbeiter eines namhaften Klemmenproduzenten erzählt.
So, jetzt versuchen wir uns einmal ganz flux und simpel vorzustellen, wie alle anderen KNX-Hersteller es dem Netzwerk und den Administratoren, sowie den Routern, Switches, Netzwerkdosen und Netzwerkendgeräten überall auf diesem 8 Milliarden-Einwohner-Planeten klar machen sollen, dass sie bitte sehr NUR die eben einen IP-Telegramme, welche nicht von besagtem Klemmenhersteller kommen doch bitte auf den Kupfer-, Plastikfaser- und Glasfaser-Leitern auf die 9600 Bit/s herunterbremsen sollen und alle anderen IP-Telegramme (HTTP, SMTP etc.) mit der sonst üblichen Geschwindigkeit (10 MB/ 100 MB / Gigabit / Terrabit) übertragen sollen?
Hallo! Aufwachen! Auf Kupfer läuft die Übertragung mit Elektronen! Das sollte eigentlich jeder in Physik 5. Klasse gelernt haben, auch wenn er nicht berufsmässig mit Elektrotechnik zu tun hat. Ja, ich weiss das ist lange her! Deshalb erklär' ich es nochmal:
Schiebt man "vorne" ein Elektron in ein Kupferkabel rein, so fällt hinten eines "raus" (ganz "blöd" erklärt). Dem Kupfer ist es vollkommen egal, wer es "reinschiebt". Auch ist es dem Kupfer total Wurst, wie das Elektron heisst - nennen wir es "Heinz". Ebenso dem POF oder Glasfaserkabel. Nur dort schiessen keine Elektronen durch, sondern Photonen sog. "Lichtteilchen". Und die haben sich schon seit dem Urknall darauf geeinigt mit Lichtgeschwindigkeit zu reisen. Egal welcher Hautfarbe sie angehören.
Wenn man auf einen Zug mit 100 aufspringt, dann fährt man nach dem Festhalten am Zuggeländer mit Hundert, zwar mit kurzzeitig längeren Armen, aber man fährt so schnell wie der Zug! Wie alle anderen in dem Zug auch! Schaut Euch um im Zug. Die fahren mit, die da sitzen! Da fährt keiner mit sagen wir mal "25 km/h" und der auf der anderen Sitzbank mit "58,2 km/h", weil es ihm grad Spass macht sich den vorbeiziehenden Wald genauer anzusehen. Alle fahren gleich schnell. Bis auf die, welche mit Lichtgeschwindigkeit nach vorne fliegen und so die Grundlage für Einsteins Relativitätstheorie waren. Aber das erkläre ich Euch später.
Oh, Mann..
Und wie soll das bitte technologisch werden, wenn man einzelne Telegramme gesendet von einzelnen Herstellern nun abbremsen soll? Mit einem Knoten in der Leitung? Sagen die Telegramme dann "Hey! Ich bin von Hersteller xyz! Ich darf auf der Gigabyte-Leitung nur mit ner Pferdekutsche transportiert werden?" Ja, klar. Das andere KNX/IP-Telegramm meint zur Feier des Tages, dass es eigentlich heute gar keine Lust hat via Satellit mit all den anderen über den halben Erdball zu reisen, verschränkt die Arme und bockt! Und Weihnachten fällt dieses Jahr auf Ostern, um Feiertage einzusparen. Ausserdem hat sich Petrus überlegt den Schnee diesen Winter aus Cornflakes zu basteln.
Irgendwo hab ich mal ein Werbeplakat gesehen, darauf stand in grossen Lettern "Think!". War das Apple? Ach Leute.. ich könnte drüber lachen, wenn es nicht so traurig wäre.
:Prost:
Gruss Peter
PS: Ich hätte da noch zwei/drei Gerüchte auf Lager. Interesse?
Jürgen Sporleder
07.09.08, 09:06
Mal wieder amüsant, ich dachte erst, Du hast schlecht geträumt, nachts um 03Uhr00 !:D
Naja Peter, ist halt wie mein Lieblingsbeispiel, welches fast jeder in D kennt. Dort sitzen in einer Hotline bei der Telek.. halt auch mal fähige und ganz viele unfähige..........ist halt nur der first Level Support unter der bekannten 0800 xxxxxxx Nummer.
Hat sicher auch jeder mal erlebt.
Aber auch die Frage der richtigen Kommunikation, da gibt es doch auch ein Sender/Empfängermodell welches mich fragen läst ob evtl. auch der Empfänger (hier der Kunde) alles richtig verstanden hat und evtl KNX TP mit KNX IP verwechselt ?
:beer:
Immer raus mit den WAHREN techn. Gegebenheiten :D
eigentlich tut mir schon der Bauch vom Lachen weh
Hallo Peter,
man könnte es auch anders interpretieren oder zwischen den Zeilen lesen:
Das was auf der einen Seite reinkommt, kommt auch auf der anderen Seite wieder raus (und nicht mehr).
Wenn man also mit 9600 Bit/s Daten empfängt (KNX), werden auch nicht mehr als 9600 Bit/s am Ethernet Port rauskommen.
Wenn ein Telegramm 16 Bit lang ist, können theoretisch (ohne Overhead oder sonst was) 600 Telegramme gesendet werden, in einer Sekunde.
Dadurch wirst auch nur max. 600 Telegramme auf einem 10GB Netzwerk pro Sekunde senden.
Nicht weils nicht schneller geht, sondern weil im "Puffer" nicht mehr Daten zur Verfügung stehen.
Schöne Grüße
Hannes
@GLT: Kommt Zeit - Kommt nächste Story.
@Unique: Bitte lese nicht zwischen meinen Zeilen, sonder erkläre es mir klar und deutlich! Speziell: Wie Du verstehst, wo der Unterschied zwischen der Geschwindigkeit der KNX-IP-Telegramme des Klemmenherstellers ist und der andern KNX-IP-Telegramme der restlichen Hersteller. Wo soll da bitte ein "Puffer" sein oder nicht? Am Ende des Gleises meines Zuges? 16-Bit lange Telegramme gibt es nicht. Weder auf dem KNX noch auf IP. Daher ist jede theoretische Betrachtung über die Anzahl pro Sekunde mit 16-Bit-Telegrammen Makulatur. 16 Bit ist der Nutzinhalt. Sozusagen der "Inhalt des Päckchens". Die Umverpackung zählt auch. Aber was soll das? Wie wirkt sich die Länge des Telgrammes auf die Geschwindigkeit aus? Ist der Postbote ob der Grösse des Päckchens langsamer, als wenn er einen Brief transportiert? Was passiert, wenn er Päckchen und Briefe transportiert?
Gruss Peter
Hallo Unique..
ich wunderte mich schon ob des Inhalts des Beitrags von Dir. Er deckte sich nämlich interessanter Weise mit dem, was mir der Kunde mitgeteilt hat. Dies liess mich vermuten, dass Du eventuell etwas mit dem von mir nicht genannten "namhaften Klemmenhersteller" zu tun hast. Daraufhin sah ich in Deinen bisherigen Posts (http://www.knx-professionals.de/forum/search.php?searchid=363279) nach. Und siehe da, Du setzt zu 70% Beckhoff-SPS (http://www.knx-professionals.de/forum/showthread.php?p=78645#post78645) (bei Heizung und Kühlung?) ein.
Deshalb kannst Du sicherlich kompetent Aussagen treffen zu der Thematik. Würde mich über eine aufklärende Diskussion freuen.
Zum Beispiel erwähnte ich im Eingangsthread nichts von einem "Puffer". Der werte Kunde am Messestand erwähnte jedoch einen "fehlenden Puffer" - neben noch ein paar anderen für mich nicht ganz verständlichen getroffenen Aussagen. Der Zusammenhang "Puffer und Geschwindigkeit" ist übrigens noch offen.
Nun bin ich sehr gespannt. Besonders gespannt bin ich im Anschluss auf die Zusammenhänge und auf den Informationsfluss zwischen der Steiermark und Zürich. Eventuell existiert hierzu sogar eine Dokumentation oder Argumentation des Herstellers - eine Powerpoint oder ein Rundbrief, den Du mir zur Verfügung stellen kannst.
Vielleicht hat das von mir bisher als "Gerücht" aufgefasste Thema ja doch einen durchaus ernst zu nehmenden technischen Aspekt, der mir bisher verborgen geblieben ist und sicherlich die Allgemeinheit speziell im Forum interessiert.
:beer:
Gruss und Dank im Voraus
Peter
Hab schon oft im Forum stillschweigend Deine Beiträge gelesen, aber hier möchte ich auch ein bischen mitreden.
Der EIB Bus läuft ja soweit ich weiß mit 9600 bps. Wenn man nun eine bestimmteTelegrammlänge annimmt, und wenn ich dann noch wüsste wieviel Overhead es drumherhum und zwischen den Telegrammen gibt, dann käme man auf die max. Anzahl Telegramme in einer Sekunde auf einer Linie, das könnten ev. 600 Telegramme/sec sein wie Unique24 schreibt.
Wenn man diese Telegramme nun über ein 100Mbit Ethernet überträgt und sich die Kommunikation mit einem Sniffer ansieht, dann wird man sehen, das die einzelnen Telegramme mit 100Mbit übertragen werden, dazwischen jedoch immer eine Riesenpause ist, da das serielle Input Interface immer noch mit dem langsamen Einsammeln der Bits des nächsten Telegrams beschäftigt ist.
Deswegen kann ich die Aussage des Klemmenherstellers in gewisser Weise verstehen, wenngleich das etwas SEHR vereinfacht ausgedrückt ist.
Das über 10/100/1000 Ethernet nur mit 9600 kommuniziert wird stimmt physikalisch natürlich nicht, aber wenn man die End-to-End Telegrammübertragungsrate betrachtet stimmt es doch. Am anderen Ende des Ethernet kommen auch nur 600 Telegramme/sec an. Und da ist kein kontinuierlicher Datenstrom sondern da purzelt ein Telegramm mit 100Mbit raus, dann ist lange nix, dann kommt wieder eins...
Ich nehme an, das hat er gemeint.
Franz
Hallo Franz..
schön, dass Du vom stillschweigenden Mitleser zum aktiven Schreiber übergegangen bist. Und ebenso Gruss nach Österreich.
Wie soll ich es anders ausdrücken, als geschrieben. Ich würde mich wiederholen.
Versuch: Es steht das Gerücht im Raum, dass
KNX/IP-Telegramme über Ethernet mit 9600 Bit/s übertrage werden.
Das ist faktisch nachweislich unwiederlegbar falsch. Auf dem Ethernet gilt die jeweilige Netzübertragungeschwindigkeit. Punkt.
nur der "namhafte Klemmenhersteller" dafür sorgt, dass dessen KNX-Telegramme mit Ethernetgeschwindigkeit übertragen werden und alle anderen mit der Geschwindigkeit von Punkt 1 übertragen.
Das ist faktisch nachweislich unwiederlegbar falsch. Denn es gelten für alle KNX-spezifizierten Produkte die gleichen Regeln.Dabei ist vollkommen unerheblich und nebensächlich
wieviele Telegramme pro Sekunde via Ethernet übertragen werden (können). (Weil es sich um die Übertragungsgeschwindigkeit handelt).
Wie die Telegramme beim Sender/Empfänger verarbeitet werden. (Weil beide Seiten per KNX-Spezifikation festgelegt sind)
ob ein Telegramm 16Bit lang ist. (Weil es faktisch keine 16Bit lange Telegramme gibt).Einfach deshalb, weil es nicht um "Telegramme/Sekunde" geht, sondern um die Aussage "Bit/Sekunde" und "der eine kann es besser als der andere".
Darüber hinaus ist weiterhin ungeklärt
was ein eventuell vorhandener / nicht vorhandener "Puffer" mit der Übertragungsgeschwindigkeit "Bit/Sekunde" und "Übertragung via Ethernet" zu tun hat; denn egal wieviel Busklemmen bzw. Linien angeschlossen sind im System: Durch den Einsatz von Ethernet als Backbone ändert sich nichts an der maximal verarbeitbaren Anzahl der Telegramme und der Übertragungsrate innerhalb der jeweiligen Linie respektive im Liniensegment. Das ist bei allen Herstellern so, weil es die Spezifikation nicht anders zulässt. Die Daten werden im Ethernetbackbone jedoch nachweislich mit der entsprechenden Ethernetgeschwindigkeit übertragen.
woher diese Aussage kommt, die einen Kunden zur Frage drängt, ob es stimmt, dass nur der namhafte Klemmenhersteller das kann und andere nicht; denn das fällt ihm nicht einfach über Nacht ein.
ob es darüber Unterlagen gibt, die diese Aussage herstellermässig argumentatorisch unterstützen.Desweiteren möchte ich niemanden im Forum direkt oder indirekt weder persönlich noch unpersönlich für irgendetwas im Zusammenhang mit dem mutmasslichen Gerücht verantwortlich machen. Klar oder?
Der Thread hat lediglich aufklärerische Wirkung - hoffentlich. Damit andere, welche etwas falsch auffassen oder ähnliche Aussagen meinen zu hören sensibilisiert sind.
Gruss und Dank an alle die bisher mitgewirkt haben den mysteriösen Fall aufzuklären.
Gruss Peter
Hallo Peter und Kollegn,
ich kann die Aussage 9,6kb/s schon etwas nachempfinden, wenn man die End-to-End Kommunikation zwischen einer TP1 Linie und KNX/IP betrachtet.
Denn wie schon geschrieben und allen bekannt, funktioniert eine "konventionelle" Linie (TP1) mit 9,6kb/s. Wird diese mit einem IP Router an ein 10BaseT Netzwerk angeschlossen, bleibt die Geschwindigkeit innerhalb der TP1 Linie ja konstant (pysikalisch).
Aber, zum einen ist es völlig aussreichend und zum anderen muss man sich die Konstellation von mehreren Linien welche an ein 10BaseT gekoppelt sind ansehen. Der große Vorteil von Netzwerk als Backbone ist, die Übertragungsgeschwindigkeit, welche mit 10MB/s funktioniert. Sprich, es können sehr viele Linien an ein Netzwerk angeschlossen werden, ohne das es zu Leistungseinbrüchen oder Telegrammverlusten kommt. In anbetracht einer Visualisierung oder zentraler Datenverarbeitung sehr hilfreich und mitlerweile gängige Praxis.
Nun gibt es ja noch KNX/IP fähige Endgeräte die direkt über KNX/IP miteinander kommunizieren. Hier wird die Geschwindkeit in der tat 10MB/s sein.
Hallo Peter,
ich meinte weniger deine Zeilen, sondern die deines Kunden ;-)
Wir haben leider an einem Punkte vorbei geredet:
Ein 100Mbit/s Ethernet Netz überträgt Daten, egal woher sie stammen, mit 100Mbit/s (theoretisch).
Wenn du aber versucht, von einem KNX Bus zu einem anderen, Daten mit 100Mbit/s zu übertragen, wirst du keine 100% Busauslastung bekommen.
Wenn das IP Gateway nur 9,6Kb/s liefert, wirst du auch nur in einer Sekunde 9,6Kb übertragen.
Die Daten werden zwar mit einer höheren Geschwindigkeit übertragen, aber in Summe schaffst du nicht mehr Daten über ein Lan zu senden, als 9,6Kb/s.
Ich beschrieb die Menge von Daten, die Pro Sekunde übertragen werden, deine Sicht war, das die Daten mit einer physikalischen Übertragungsrate von 100Mbit/s übertragen werden.
Wir haben beide Recht :o
Schönen Arbeitsbeginn euch allen
Hannes
Du setzt zu 70% Beckhoff-SPS (http://www.knx-professionals.de/forum/showthread.php?p=78645#post78645) (bei Heizung und Kühlung?) ein.
Hardware JA, Software NEIN.
Wir nutzen eine Linux Version auf der Beckhoff Hardware, die Objekt Orientiert Live auf dem System arbeitet.
Gruß
Hannes
Wenn man ganz spitzfindig sein möchte, könnte man sagen, dass bei einem 100MBit Netzwerk 100 Megabit pro Sekunde die maximale Bruttodatenrate ist, die das System zur Verfügung stellen kann. Wie groß die Datenrate letztlich ist, die Netto genutzt werden kann, wird von vielen Faktoren beeinflußt. Von daher ist schon allein der Begriff der Übertragungsgeschwindigkeit eher als schwammig zu betrachten. Eigentlich ist für die jeweilige Punkt-zu-Punkt-Verbindung letztendlich allein der Datendurchsatz und ggf. die Latency relevant. Und ersteres kann u.A. durch die Datenrate der Quelle oder der Senke bestimmt werden. Trotzdem ist es denkbar, dass auf der Ethernetstrecke nicht mal die 9,6kbps erreicht werden können.
Ich glaube, die Konfusion ist letztlich entstanden, weil hier einfach viele Begriffe durcheinandergebracht oder fälschlicherweise synonym verwendet wurden.
Ich hoffe meinen Beitrag zur allgemeinen Verwirrung geleistet zu haben!! ;)
Ich verweise hier mal auf das KNX Journal (http://www.knx.org/fileadmin/downloads/07%20-%20News%20&%20Press/01%20-%20KNX%20Journal/2008/KNXJournal%202008-n1.pdf)
Das KNX Protokoll hat erst mal nichts mit der Geschwindigkeit zu tun. Erst wenn es auf die Physik geht, wird die Geschwindigkeit interessant.
D.h. Wenn in einem KNX Netzwerk der TP1 ("das grüne Kabel") verwendet wird, hat man die Begrenzung auf 9600 Baud. Bei KNX/RF sieht es auch wieder anders aus.
Über KNX/IP können Endgeräte nicht nur über einen KNX/IP Router und TP1 ("grünen Kabel") angebunden werden, sondern auch direkt über das CAT5/7 Ethernetkabel. D.h. Das Ethernet Netzwerk geht bis zu dem Taster/Dimmer/ whatever. Statt einem Busankoppler hat man hier einen KNX/IP Koppler. (Sehr schön zu sehen als "KNX/IP Only Device" auf Seite 2 bzw. Seite 11 als "KNX IP Device" des KNX Journals)
KNX/IP ist nicht nur Routing/Tunneling sondern auch direkter Zugriff auf die Endgeräte (die dies unterstützen) und da sind natürlich 10M/100M/1GB möglich
--Thomas
Hallo,
genau wie Alex und Unique24 kann ich die Aussage mit den 9600Bit/s nachvollziehen.
Es geht doch um die Datenübertragungsrate und nicht darum, wir lange ein einzelnes Telegramm unterwegs ist. Anhand der Datenübertagungsrate kann man erkennen, wie viele Telegramme max. pro Zeit übertragen werden können.
Das Beispiel mit den Elektronen die auf der einen Seite rein und auf der anderen Seite heraus kommen ist völlig aus dem Zusammenhang gerissen.
Die Frage ist, was passieren kann, wenn auf der einen Seite ein sehr schnelles Medium IP existiert und auf der anderen Seite ein "langsames" Medium. Wenn z.B. mehrere KNX IP Geräte mit 100MBit Geschwindigkeit senden, dann können die IP Router die Daten nicht schnell genug an die TP1 Linie absetzen. Dies würde zum Überlauf des Telegrammpuffers im Router führen.
Man kann das auch anschaulich mit einem Wasserhahn vergleichen, der voll aufgedreht wird der Abfluss aber nur einen Durchmesser von einem Millimeter besitzt. Die Folge wäre, dass das Waschbecken überläuft. Man kann das Problem auf zwei Wegen lösen. Entweder man drosselt die Wasserzufuhr (auf 9600Bit/s) oder man sorgt dafür dass der Abfluss größer wird.
Da die Übertragungsrate auf TP1 nicht erhöht werden kann, muss die Übertragungsrate auf IP gedrosselt werden.
Peter ich gebe zu, dass ich in der 5.Klasse Physik nicht immer geistig anwesend war. Ich denke der Zusammenhang ist ist mir aber trotzdem klar geworden, ohne mir über Elektronen und Photonen Gedanken machen zu müssen...;)
Gruß
C. Mak
Hallo Kollegen..
Wasserhahn, Elektronen, .. sind wir Techniker oder was?
Also, nur mal so nebenbei. Es hat deutlich grössere Projekte mit KNX/IP als mit KNX/TP-Kopplung. (London Heathrow und Wallgreens). Also bleibt mal auf dem Boden.
"Es kann zu Verstopfungen kommen". Ja, es kann auch zu einem Meteoriteneinschlag kommen. "Man kann sich vorstellen". Momentan stellt man sich "Die Erzeugung Schwarzer Löcher und den Untergang der Erde samt Menschheit vor (http://www.focus.de/wissen/wissenschaft/technik/large-hadron-collider-geht-heute-die-welt-unter_aid_332205.html)". Siehe auch GOOGLE-Header von heute. (Auf das Teil einfach mal draufklicken).
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.
Aber Deine Stellungnahme mit dem Wasserhahn bringt mich auf die Idee "Flaschenhals" und Flaschhals heisst für mich "Visualisierung" oder "Anbindung Leitsystem" - HAHAAAAaaaaH!
Also versucht doch der Kollege Mitbewerb seinen Controler als Visuserver zu verwenden; denn nur dann kommt es bei Statusabfragen oder zentralen Befehlen zu einem "Stau" auf der IP-Leitung Richtung Controler! Tja, da hat er leider Pech gehabt. Es gibt hier bessere Lösungen. (Nur mal so nebenbei). Denn genau DAS Problem existiert schon sehr lange. Eben so lange wie man Visualisierungen über einen "Flaschenhals" anbindet. In der Steinzeit des EIB mit RS232. Wir erinnern uns kurz und springen wieder in das Hier und Jetzt in die Welt von KNX/IP. Aber das ist eben UNSER Wettbewerbsvorteil. Alles klar!?! Zum Beispiel mit KNX2S7 (http://www.knx.ch/siemens/instabus/data/ip_anbin/KNX_SIMATIC_S7_Schnittstelle.pdf). Wer hat's erfunden?
Gruss Peter
PS: Sollte das mit den "Schwarzen Löchern" im Large Hadron Collider (http://de.wikipedia.org/wiki/Large_Hadron_Collider) funktionieren, wird sich nicht nur ganz sicher das US-Millitär dafür interessieren, sonder auch Hollywood. Es folgt bestimmt bald ein Kassenschlager-Movie, in welchem sich Freund und Feind mit tragbaren MINI-CERN-Teilchenbeschleunigern beschiessen und gegenseitig in Schwarze Löcher ziehen.
Ich sehe schon Arni Schwarzenegger in seiner letzten grossen Hauptrolle. Sein Standardsatz "Don't move! I suck you into my black hole!"
Hallo Kollegen..
"Dieser Beitrag wurde ausgeglichen bewertet (http://www.eib-userclub.de/forum/showthread.php?p=79148#post79148)" 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
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 :D
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.
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/Internet_Control_Message_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.
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 (http://www.wago.com/wagoweb/documentation/753/ger_dat/dp64600d.pdf); Technische Information/Datenblatt und Handbuch (http://www.wago.com/wagoweb/documentation/753/ger_manu/modules/mp64600d.pdf)(Ü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 (http://www.wago.com/wagoweb/documentation/750/ger_dat/d084900d.pdf); 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 (http://www.ecrmarine.com/wago_KNX.pdf)) 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
Die TP-Klemme kennt 2 Modi - in Verbindung mit einem KNX-Controller arbeitet die 1. Klemme immer im Routermodus (nicht konfigurierbar)
Handbuch Routermodus (http://www.wago.com/wagoweb/documentation/753/ger_manu/modules/mp64601d.pdf)
weiter Klemmen (oder in Verbindung mit unterstützten Controllern) arbeiten im Gerätemodus
Handbuch Gerätemodus (http://www.wago.com/wagoweb/documentation/753/ger_manu/modules/mp64600d.pdf)
Beachten sollte man auch das Konzept von WAGO
WAGO KNX Konzept (http://www.wago.com/wagoweb/documentation/753/ger_info/tp64600d.pdf)
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?
Anhang:
I) WAGO KNX/EIB/TP1-Klemme 753-646 (http://www.wago.com/wagoweb/documentation/753/ger_dat/dp64600d.pdf); Technische Information/Datenblatt und Handbuch (http://www.wago.com/wagoweb/documentation/753/ger_manu/modules/mp64600d.pdf)(Ü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 (http://www.wago.com/wagoweb/documentation/750/ger_dat/d084900d.pdf); 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
Hallo Hannes..
zur Beckhoff-Klemme. Bedeutet Deine Aussage, dass man bei den Gruppenadressen auf die genau Zurodnung der vier Gruppen festgelegt ist?
Gruss Peter
Dieter Koch
15.09.08, 17:52
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
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
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
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 :D
Gruß
Hannes
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
elwedritsche
18.09.08, 19:21
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 :rolleyes:.
Gruß,
Elwedritsche
Hallo "ElWeDrItsche"..
Zuerst hier der Link zum KNX-Journal 01/2008 (http://www.knx.org/fileadmin/downloads/07%20-%20News%20%26%20Press/01%20-%20KNX%20Journal/2008/KNXJournal%202008-n1.pdf), 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 (http://de.wikipedia.org/wiki/Komplexit%C3%A4t) (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.
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
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.
Hallo ihr zwei..
@hennessy und @uwe!
Von was redet Ihr? Ein "Nicht-KNX-Gerät", welches auf Ethernet angeschlossen ist, muss so im Telegrammverkehr gedrosselt werden, dass es nicht mehr wie 50 Telegramme auf das Ethernet schiebt. Ob dabei ein "Puffer" hardwaretechnisch oder softwaretechnisch überhaupt zum Einsatz kommt, ist Sache der Produktarchitektur. Wobei "50 Telegramme" bereits oberes Limit ist. Ende.
"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."
Gruss Peter
@hennessy und @uwe!
Von was redet Ihr?
von dem Versuch diese Zeile hier in Bezug auf "Verzögerung" zu interpretieren:
Zitat von elwedritsche http://www.knx-professionals.de/forum/images/buttons/viewpost.gif (http://www.knx-professionals.de/forum/showthread.php?p=79257#post79257)
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.
Dieter Koch
21.09.08, 11:03
Aber wir sind ja kommendes WE bei WAGO. Ich Frage da bestimmt.
Für alle, die es interessiert:
Bei der WAGO-Klemme kann man alle 32.000 GrpAdr. verwenden.
Der Vortrag war sehr interessant und nachvollziehbar. Ich hatte erst meine Schwierigkeiten zu verstehen, daß es sich bei einem KNX/IP kontroller mit 2 TP-Klemmen um zwei KNX-Geräte handelt. Zwei phys. Adressen, zwei unterschiedliche Linien usw.
WAGO bietet im nächsten Jahr wieder bundesweit Kurse zu dem Thema an. Meiner meinung lohnt sich die Zeit.
Gruß
Dieter
Für alle, die es interessiert: Bei der WAGO-Klemme kann man alle 32.000 GrpAdr. verwenden.
Der Vortrag war sehr interessant und nachvollziehbar. Ich hatte erst meine Schwierigkeiten zu verstehen, daß es sich bei einem KNX/IP kontroller mit 2 TP-Klemmen um zwei KNX-Geräte handelt. Zwei phys. Adressen, zwei unterschiedliche Linien usw.
WAGO bietet im nächsten Jahr wieder bundesweit Kurse zu dem Thema an. Meiner meinung lohnt sich die Zeit. Gruß Dieter
Hoi Dieter..
hast Du gefragt, wieso die Kopplung über WAGO die Telegramme über IP schneller übertragen (kann), als alle andere? ;)
Gruss Peter
Dieter Koch
22.09.08, 15:19
hast Du gefragt, wieso die Kopplung über WAGO die Telegramme über IP schneller übertragen (kann), als alle andere?
Hallo Peter,
das wurde erklärt und ich habe es auch verstanden. Leider kann ich es nicht nachvollziehbar erklären, weiss aber, daß die WAGO-Leute hier mitlesen. Vielleicht schreiben die Mitarbeiter mal.
Es gibt bei WAGO einen Haken, der in der Software gesetzt werden muss, damit die normale IP-Geschwindigkeit benutzt wird. Brüssel hat darauf bestanden und als Bedingung für die Zertifizierung gemacht.
:rolleyes::rolleyes:Oder habe ich es doch nicht richtig verstanden:rolleyes::rolleyes:
Es können sich zur gleichen Zeit mehrere Kontroller miteinander unterhalten. Nur wenn sich zwei unterschiedliche mit dem 3. ......
Bitte liebe WAGO-Leute, erklärt es noch einmal
Gruß
Dieter Koch
PS: Es war ein interessanter Tag und ein gelungener Abend.
Meudenbach
22.09.08, 15:50
Zitat:
Zitat von PeterPan http://www.eib-userclub.de/forum/images/buttons/viewpost.gif (http://www.eib-userclub.de/forum/showthread.php?p=79311#post79311)
hast Du gefragt, wieso die Kopplung über WAGO die Telegramme über IP schneller übertragen (kann), als alle andere?
... weil die "Junx" was von Protokollen verstehen :-) ...
LG
Jürgen Sporleder
22.09.08, 15:54
Ich versuchs mal, auch auf die Gefahr das ich auf die Schnauze falle.......
Es hängt damit zusammen, das insbesondere der Linienübergreifende Datenverkehr zwar in voller Bandbreite und Geschwindigkeit die Daten übertragen kann, jedoch die untergeordneten Linien welche auf KNX-TP basieren, nur 9,6k zulassen, im Vergleich der KNX-IP mit 10M bzw. 100M gefahren werden kann. Die Daten welche in der übergeordneten Linie von mehren Stellen kommen könnte, da ja dort vor allem Linienkoppler sitzen, müssen die Datenflut auch verarbieten können. Dieses können sie jedoch nicht in der Art, da der Datenabfluss in die Linie nur mit 9,6k erfolgen kann. Also ist und bleibt hier ein "Flaschenhals" der sozusagen dann auch auf der übergeordneten Linie, welche über KNX-IP kommuniziert, "künstlich" aufrecht erhalten werden muss, um die LKs nicht zu überfordern. Somit ist innerhalb der KNX Welt immer von 9,6k auszugehen, selbst in der KNX-IP Welt. Wenn jedoch KNX-IP Geräte mit Webservices arbeiten, parallel zum KNX-IP Protokoll, so werden diese Dienste die vollen 10M oder 100M nutzen. Um jedoch eben keinen Datenstau vor den LKs (die untergeordnet mit 9,6k zwangsläufig arbeiten, da KNX-TP) zu erzeugen, wird eben insgesamt nicht mehr als 9,6k in die KNX Welt zugelassen.
Wenn jedoch Beispielsweise 2 oder mehr Knoten auf KNX-IP Basis ohne KNX-TP Linie arbeiten, also ohne 9,6k KNX-TP Geräte auskommen, kann der Haken den Dieter beschrieben hat, entfernt werden, da es ja zu keinem Datenstau auf dem Niveau einer 9,6k KNX-TP Linie kommen kann.
Ich habe es bewusst so einfach wie möglich beschrieben !:eek: Und bei Fehlern bitte ich insbesondere die Wago-Leute mich zu korigieren.
[quote=Jürgen Sporleder]
Wenn jedoch Beispielsweise 2 oder mehr Knoten auf KNX-IP Basis ohne KNX-TP Linie arbeiten, also ohne 9,6k KNX-TP Geräte auskommen, kann der Haken den Dieter beschrieben hat, entfernt werden, da es ja zu keinem Datenstau auf dem Niveau einer 9,6k KNX-TP Linie kommen kann. quote]
Hoi Junx..
was soll das bitte für einen Sinn haben? "KNX-Knoten" arbeiten auf KNX-IP-Basis ohne KNX-TP-Linie?
Ach und: Es darf ruhig jemand von WAGO mitschreiben und das erklären. Schliesslich lesen die Herren ja mit und es geht um deren Produkte, odrrr?
Gruss Peter
Jürgen Sporleder
22.09.08, 22:42
Hoi Junx..
was soll das bitte für einen Sinn haben? "KNX-Knoten" arbeiten auf KNX-IP-Basis ohne KNX-TP-Linie?
Einen ganz einfachen, warum sollte KNX auf Linien mit 9,6k beschränkt bleiben?
Es kann so sein, muss es aber nicht. Es ist so also eine KNX Welt vorstellbar die ausschliesslich auf derzeit 10M/bit läuft. Also bisher wohl nur Wago und evtl. Beckhoff aber es sollen ja noch weitere dran arbeiten.
Ein Knoten besteht aus zentral angeordneten Ein- und Ausgabemodulen, dies kann bei Wago bis zu 64 Stück dieser Module sein. Diese Knoten lassen sich auf 10M/bit verbinden und dann betreiben, sofern der "Haken" im Webinterface entfernt wird. Dann läst sich solch ein Knoten auch über die ETS sicher mal alleinig progen, was derzeit aber bei Wago nur über die "Knotensoftware" Codesys möglich ist.
Aber auch ein anderer Ansatz ist denkbar. Eine Übergeordnete Visu kann bei entfernen des "Hakens" mit 10M/bit bedient werden, sofern von der Visu zurück nicht viel Datenverkehr (bezogen auf einen einzelnen LK mit 9,6 Linie untergeordnet) gehen muss, und es dann wieder zu Engpässen kommen kann.
Hallo Jürgen..
also, nun stellen wir uns mal ganz dumm:
Wir ersetzen:
- KNX/TP durch KNX/IP
- BCU durch WAGO-Controller
- Anwendungsmodul durch WAGO-Klemmen
- Max. 64 BCU2 durch 64 WAGO-Controller
Ist es das, was Du meinst?
Gruss Peter
Jürgen Sporleder
22.09.08, 23:16
Wieso stellst Du dich da jetzt dumm ?
Es ist dann die Schreibe von "KNX-IP only Device" !
Diese können dann eben klar und ohne Überlauf eines Telegrammpuffers von 10-40 Telegrammen wie in 9,6k LKs mit 10Mbit bei reinem IP-Protokoll betrieben werden.
(Und "schon" (:rolleyes:) geht den aus der LON Seite kommenden Kritikern die Puste aus in Bezug auf das alte und immer wieder unnütz durchgekaute Thema Geschwindigkeit auf einem Feldbus ! :D)
Jaja...
schöne heile Wago-Welt...
Frage: Was kostet so ein "Wago"-TCP/IP-Knoten im Vergleich zu einer BCU?
Und warum nimmt man dann nicht gleich Profibus? SPS und STEP7?
Was passiert, wenn ich eine DALI-Klemme verwende? (mit 1200 bit/s)?
Warum ist die Erde keine Scheibe?
Sieht die Zukunft wieder so aus? Zentraler Controller und Sensor/Aktor-Verkabelung sternförmig dorthin?
Gruss Peter
Jürgen Sporleder
22.09.08, 23:37
Frage: Was kostet so ein "Wago"-TCP/IP-Knoten im Vergleich zu einer BCU?Imho, falsche Frage, da ja bei einem Knoten nicht der Controller mit einer BCU vergleichbar ist, sondern bis zu 64 BCUs in Form von Modulen anreihbar sind. Ansonsten kann ich nur sagen, das bei genauer Betrachtung die Kostenseite für einen solchen Knoten sehr vielversprechend ist.
Und warum nimmt man dann nicht gleich Profibus? SPS und STEP7?Weil Siemens Imho kein Dali, enoceon Mbus, KNX-TP und weitere in einen Knoten vereinen kann ! (?) Andererseits kann zum Beispiel ein solcher (Wago-) Knoten aber eben nicht nur KNX-IP sondern parallel !!! auch andere Protokolle bedienen, z.B. Modbus.
Sieht die Zukunft wieder so aus? Zentraler Controller und Sensor/Aktor-Verkabelung sternförmig dorthin?Ist das mal abgesehen von der Sensor Anordung nicht inzwischen der Anwendungsfall schlechthin ? Auch wenn die Instabusgruppe das vor 18Jahren mal anders gesehen hat !
Ich spreche hier nicht vom EFH sondern vom Zweckgebäude.
Warum ist die Erde keine Scheibe?Warum hat Siemens kein quasi Weltmonopol ala Microsoft in der Gebäudetechnik ? :rolleyes:
Hoi Jürgen..
schöne Antworten. Aber die DALI-Frage ist noch offen. Kannst aber auch für Modbus oder Enocean antworten. Bei KNX-TP(-Klemme) dürfte es ja denn das gleiche sein.
Das mit den "64 Modulen" hab ich noch nicht ganz verstanden aus dem ersten Teil Deiner Antwort. Kann ich nun 64 KNX/IP-Controller verwenden oder 64 "Module" (Modul ist mir zu allgemein. Klemme oder Controler oder KNX-TP-Gerät)
PS: Die Beziehung zwischen "flacher Erde" und "Weltmonopol Siemens" ist mir auch nicht ganz klar. :confused:
Gruss Peter
Dieter Koch
23.09.08, 06:07
Der WAGO-Kontroller ist nun einmal das erste KNX-Gerät, daß nur über IP erreichbar ist. Klemmen dahinter brauchen nur Zusätze zu sein
Ich bin mir ziemlich sicher, daß wir auf der nächsten L&B weitere IP-Geräte sehen werden.
Zu der Kostenseite kann ich nur soviel sagen, daß wir mal ein großes BV kalkuliert haben (ca. 3.000 Schaltgruppen). da hat sich für uns kein Preisvorteil ergeben, weil ja auch der höhere Integrationsaufwand mit kalkuliert werden muss.
Wenn dann noch eine Reihe von AI und AO dazukommen, sieht die Kostenrechnung bestimmt ganz anders aus.
Gruß
Dieter
Jürgen Sporleder
23.09.08, 07:46
Die Antwort auf die Frage der Anzahl der möglichen Module ist relativ, da es insbesondere auf die Art und Weise des einzelnen Moduls ankommt. Also 64 Dali Klemmen ranzuhängen ist sicher nicht nur Praxisfern, also das es auch nicht funktionieren würde. Der Controller ist zum einen was den internen Hardwareaufbau (Speicher, Rechenleistung, interne Übertragunsgeschwindigkeit, usw) angeht nicht unendlich. Wago vergleicht das mit einem PC, was ist auf einem PC alles an Software installierbar ? An einen Controller lassen sich sicher 64 O/I Module anhängen, jedoch bei "Sondermodulen" schaut es ganz anders aus. Da kommt insbesondere das Thema Erfahrung ins Spiel.
Aber ein genanntes Beispiel: An einem Kontroller lassen sich auch mehrere KNX-TP1 Klemmen anschliessen, somit wird der Knoten zum Router, Lienkopler und A/I Aktor mit vielen EIN-Ausgängen inkl. Dali Klemme/n und enocen Klemme/n zu einem interesanten KNX Teilnehmer.
Und je nach dem wie ein solcher Knoten nun konfiguriert wird, entweder als einzelner KNX-TLN oder als Router oder als Router mit mehreren KNX-TP1 Klemmen ergibt sich die maximale Zahl von Controllern in einer KNX-IP Welt. Aber sicher mehr als 64 mögliche Geräte, denn die 64 bezog sich auf die Anzahl der Module (Klemmen) welche an einem Kontroller anreihbar sind.
Die Kostenseite läst sich sicher nicht mit wenigen Worten beantworten, da einfach zu viele Dinge zu berücksichtigen sind. Der zusätzliche Verdrahtungsaufwand, noch fehlende Module wie Jalousie und Dimmer, der "andere" und evtl erhöhte Integrationsaufwand durch Verwendung der Codesys und und und.......Es ist der einzelne Anwendungsfall zu betrachten, wie fast immer.
Hallo Kollegen..
halt.. nicht ablenken :-)
Aber die DALI-Frage ist noch offen. Kannst aber auch für Modbus oder Enocean antworten. Bei KNX-TP(-Klemme) dürfte es ja denn das gleiche sein.
Zur Erinnerung: Die Frage steht im Zusammenhang mit dem "Häkchen" für 10MB oder nicht 10MB. Und dem eventuell daraus resulierenden Vorteil im Vergleich zu KNX/IP-Kopplern anderer Hersteller.
Gruss Peter
Jürgen Sporleder
23.09.08, 19:16
Aber die DALI-Frage ist noch offen. Kannst aber auch für Modbus oder Enocean antworten. Bei KNX-TP(-Klemme) dürfte es ja denn das gleiche sein.Nein, das ist nicht das gleiche:
Der Wagokontroller kann 15 gleichzeitige Modbus Verbindungen bedienen, aber nur eine dazu gleichzeitge KNX-IP Verbindung. Dazu 3xPFC, 3xHTTP, 10xFTP und weitere. Welche nun in welcher Reihenfolge, das kann ich Dir auch nicht beantworten. Zur Daliklemme geht es dann eben weiter auf den internen Bus. Die Geschwindigkeit diesen ist mir nicht bekannt.
Anzumerken wäre noch, das an einem Knoten max. 5 Dali Klemmen montiert werden dürfen.
Hallo Jürgen..
neinnein.. ich meine nicht intern. Es geht wie in der Überschrift angedeutet um die Kommunikation zwischen Teilnehmern via IP.
Also, ich hab 4 WAGO-Controler. Daran ist jeweils eine DALI-Klemme (DALI-Leuchten) und eine KNX-Klemme (Jalousieaktoren) montiert. Schaltkanäle laufen über ein paar Ausgangsklemmen. An einem weiteren Controler hängt eine KNX-Klemme mit KNX-Sensoren dran, über welche die DALI-Beleuchtungen geschaltet und gedimmt werden (es dürfen auch KNX-Präsenzmelder mit integrierter Helligkeitssteuerung sein). Alle Controller unterhalten sich via KNX/IP.
Wo liegt der Unterschied bei der Telegrammübertragung via IP im Betrieb zu Controlerlosen Lösungen?
Gruss Peter
Powered by vBulletin® Version 4.2.4 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.