Forum: Mikrocontroller und Digitale Elektronik UDP Broadcast mehrere Switches


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Nxitimi (nxitimi_tol)


Lesenswert?

Hallo zusammen

Eine Frage an die Experten. Ich habe 14 Switches, die ich über Daisy 
Chain Topology verbunden sein müssen. Die Frage, die ich mir stelle, ist 
halt "Broadcasting" und Performanz?

1) Ist Broadcasting mit mehrere Switches über Daisy Chain Topology 
überhaupt möglich? Es sind ja mehrere Switches . . .

2) Performanz: Hat jemand Erfahrung mit so viele Switche?

Danke & Grüsse
Nxitimi

von (prx) A. K. (prx)


Lesenswert?

Innerhalb einer verbundenen Gruppe von Layer-2 Switches werden 
Broadcasts über alle Switches verteilt. Egal wie die verbunden sind.

Wenn die Kaskadierung in gleicher Technik erfolgt, wie die Ports der 
Switches, also z.B. alles 1 Gbit/s, ist der Flaschenhals natürlich die 
Verbindung der Switches untereinander.

von Harry L. (mysth)


Lesenswert?

Nxitimi schrieb:
> 1) Ist Broadcasting mit mehrere Switches über Daisy Chain Topology
> überhaupt möglich? Es sind ja mehrere Switches

Wenn das "dumme" unmanaged Switches sind, werden auch Broadcasts einfach 
so durchgereicht.

Nxitimi schrieb:
> 2) Performanz: Hat jemand Erfahrung mit so viele Switche?

So Viele hab ich noch nie hintereinander gehängt, aber am besten, du 
misst selbst nach.

iperf ist dein Freund.
https://iperf.fr/iperf-doc.php

Ansonsten ist der Performance-Verlust bei einzelnen Switches 
normalerweise vernachlässigbar.

von Hmmm (Gast)


Lesenswert?

Nxitimi schrieb:
> Ist Broadcasting mit mehrere Switches über Daisy Chain Topology
> überhaupt möglich?

Ja.

Nxitimi schrieb:
> Performanz: Hat jemand Erfahrung mit so viele Switche?

Daisy Chaining riecht nach Flaschenhälsen, sofern die nicht dafür 
schnellere Ports haben.

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> Broadcasting

Womit du hoffentlich kein Radio/Fernsehbetrieb meist. ;-)

von (prx) A. K. (prx)


Lesenswert?

Harry L. schrieb:
> Wenn das "dumme" unmanaged Switches sind, werden auch Broadcasts einfach
> so durchgereicht.

Managed Switches müssen das an eine Broadcast-Adresse notwendigerweise 
auch. Was sollen sie damit denn sonst machen?

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> "Broadcasting" und Performanz

Wenn du vorhast, hohe Last per Broadcasts zu verschicken, dann Vorsicht: 
Während zielgerichtete Frames per Hardware durchgereicht werden, 
geschieht das bei Broadcasts u.U. zu Fuss über einen langsamen 
Steuerprozessor. Der Durchsatz wird dann durch ebendiesen begrenzt.

Bei intelligenten Switches kann dir zudem eine Schutz einen Strich durch 
die Rechnung machen. Die machen dann den Port dicht, der das Netz mit 
Broadcasts flutet.

: Bearbeitet durch User
von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Innerhalb einer verbundenen Gruppe von Layer-2 Switches werden
> Broadcasts über alle Switches verteilt. Egal wie die verbunden sind.
Natürlich wird die Information verteilt. Aber sagen wir mal so ich habe 
Switches mit 2 Ports die so verkettet werden und ich denke schon dass 
die Frames von jedem Switch angeschaut werden und weiter gereicht 
werden. Das müsste schon Zeit in Anspruch nehmen??? Das heisst ob ich 
Broadcaste oder nicht bei meinem Fall bekomme ich die Information doch 
nicht parallel??
>
> Wenn die Kaskadierung in gleicher Technik erfolgt, wie die Ports der
> Switches, also z.B. alles 1 Gbit/s, ist der Flaschenhals natürlich die
> Verbindung der Switches untereinander.

von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Nxitimi schrieb:
>> "Broadcasting" und Performanz
>
> Wenn du vorhast, hohe Last per Broadcasts zu verschicken, dann Vorsicht:
> Während zielgerichtete Frames per Hardware durchgereicht werden,
> geschieht das bei Broadcasts u.U. zu Fuss über einen langsamen
> Steuerprozessor. Der Durchsatz wird dann durch ebendiesen begrenzt.
>
> Bei intelligenten Switches kann dir zudem eine Schutz einen Strich durch
> die Rechnung machen. Die machen dann den Port dicht, der das Netz mit
> Broadcasts flutet.

Es sind maximal 200 Bytes die aber so eine Art HartBit Funktion spielen 
müssen sprich jede 300 ms an alle Teilnehmern - Sicherheitsrelevante 
Funktionen.

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> Das müsste schon Zeit in Anspruch nehmen??? Das heisst ob ich
> Broadcaste oder nicht bei meinem Fall bekomme ich die Information doch
> nicht parallel??

Natürlich kommt das nacheinander. Von einem Ende der Kette zum anderen 
dauert es länger. In üblichen Gebrauch spielt das keine Rolle, aber wenn 
du um Mikrosekunden kämpft, dann ist die Daily Chain Topologie 
ungünstig.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> HartBit

Du meinst vmtl Heartbeat (Herzschlag).

Die Laufzeit von Broadcasts Ende zu Ende ist nicht theoretisch 
ermittelbar, weil die im Switch u.U. auf völlig andere und weit weniger 
effiziente Art berhandelt werden.

: Bearbeitet durch User
von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Nxitimi schrieb:
>> HartBit

Sorry.
>
> Du meinst vmtl Heartbeat (Herzschlag).
Yes. Danke dir.

von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Nxitimi schrieb:
>> Das müsste schon Zeit in Anspruch nehmen??? Das heisst ob ich
>> Broadcaste oder nicht bei meinem Fall bekomme ich die Information doch
>> nicht parallel??
>
> Natürlich kommt das nacheinander. Von einem Ende der Kette zum anderen
> dauert es länger. In üblichen Gebrauch spielt das keine Rolle, aber wenn
> du um Mikrosekunden kämpft, dann ist die Daily Chain Topologie
> ungünstig.

Innerhalb von 300[ms] muss die Information da sein, sonst geht alles in 
die Hose.

Und wir haben mit mehrere Kollegen diskutiert und konnte die nicht 
überzeugen dass Broadcasting in dem Fall einfach nichts bringt. Weil 
eben die Information nacheinander fliesst.

von Hmmm (Gast)


Lesenswert?

Warum überhaupt Broadcasts? Muss jeder den Status von jedem direkt 
erfahren?

von Nxitimi (nxitimi_tol)


Lesenswert?

Hmmm schrieb:
> Warum überhaupt Broadcasts? Muss jeder den Status von jedem direkt
> erfahren?
Das ist auch eine Anforderung. Status muss überall bekannt sein.

von Hmmm (Gast)


Lesenswert?

Nxitimi schrieb:
> Das ist auch eine Anforderung. Status muss überall bekannt sein.

Gibt es einen Master, oder sind alle Teilnehmer gleichberechtigt?

von Nxitimi (nxitimi_tol)


Lesenswert?

Hmmm schrieb:
> Nxitimi schrieb:
>> Das ist auch eine Anforderung. Status muss überall bekannt sein.
>
> Gibt es einen Master, oder sind alle Teilnehmer gleichberechtigt?
Wir könnten einen Master definieren. Es wäre möglich.
Wird uns dabei helfen?

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> Innerhalb von 300[ms] muss die Information da sein, sonst geht alles in
> die Hose.

Sehe ich nicht als Problem. Aber wenn dir ein Patient verreckt, wenn der 
Broadcast einmal dank Volllast 301ms braucht, oder ganz absäuft, dann 
wirst du wohl oder übel eine länger Mess-Sitzung einplanen müssen. Wie 
gesagt, nicht alle Switches sind gleich, besonders nicht bei Broadcasts.

: Bearbeitet durch User
von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Nxitimi schrieb:
>> Innerhalb von 300[ms] muss die Information da sein, sonst geht alles in
>> die Hose.
>
> Sehe ich nicht als Problem. Aber wenn dir ein Patient verreckt, wenn der
> Broadcast einmal dank Volllast 301ms braucht, oder ganz absäuft, dann
> wirst du wohl oder übel eine länger Mess-Sitzung einplanen müssen. Wie
> gesagt, nicht alle Switches sind gleich, besonders nicht bei Broadcasts.

Was würden Sie von dem halten? Haben Sie evtl. Erfahrungen in der 
Richtung.

https://www.mouser.ch/datasheet/2/609/adin2111-2891062.pdf

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> Was würden Sie von dem halten?

Moooment - in Zeiten von Switches mit 10 Gbit/s geht es hier um 
archaische 10 Mbit/s? Das kommt etwas überraschend.

> Haben Sie evtl. Erfahrungen in der Richtung.

Mit Ethernet unter Echtzeitbedingungen nicht.

von Hmmm (Gast)


Lesenswert?

Nxitimi schrieb:
> Wir könnten einen Master definieren. Es wäre möglich.
> Wird uns dabei helfen?

Mein Ansatz wäre, dass die Slaves sich per Unicast beim Master melden 
und der Master periodisch einen Broadcast rausschickt, in dem er 
mitteilt, welche Slaves am Leben sind.

Das hat den Vorteil, dass die Heartbeat-Meldungen zuverlässiger 
ankommen, nicht alle Ports zugemüllt werden, die Slaves weniger Pakete 
verarbeiten müssen und jeder Slave anhand des Master-Broadcasts auch 
noch herausfinden kann, ob sein Heartbeat-Paket vom Master empfangen 
wurde.

von Manu (Gast)


Lesenswert?

Dein Vorgehen ist für eine Sicherheitsrelevante Anwendung gefährlich! 
Wenn dir ein Switch in der Kette abraucht, sind alle nachfolgenden 
Geräte ebenfalls weg. Besser wäre, wenn du eine Baumstruktur aufbaust. 
Bei hohen Distanzen dann eventuell auch via Multimode oder Singlemode 
Glasfaser. Deine 300ms sind in keinem Fall ein Problem, deine Pakete 
werden viel schneller sein solange die Leitungen nicht ausgelastet sind.

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> Was würden Sie von dem halten?

Kann immerhin cut through switching. Das reduziert die Latenz, weil die 
Frames nicht zwingend in jedem Hop zwischengespeichert werden. ABER: Ob 
das auch für Broadcasts und Multicasts gilt? Ggf Hersteller fragen.

: Bearbeitet durch User
von Fleischwarenfachverkäufer (Gast)


Lesenswert?

Darf's vielleicht noch eine Scheibe mehr Salami sein?

Also das wäre ja vielleicht eine Info für früher gewesen bevor man schon 
über eine Daisychain von 14 Switches mit hunderten angeschlossenen 
Devices nachgedacht hat und wie die Broadcasts sich benehmen wenn die 
Links durch anderen Treaffic voll sind...

Jetzt sag noch bitte wie viel andere Informationen (wie viel Traffic) da 
noch auf dieser 10Mbit Leitung sein soll? Oder ist die dediziert nur für 
diesen Hartbeat und die damit zu bauende Überwachung da?

Btw. der Chip hat ein Broadcast Frame Counter, da wird er mit Broadcasts 
umgehen können...

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Fleischwarenfachverkäufer schrieb:
> Also das wäre ja vielleicht eine Info für früher gewesen bevor man schon
> über eine Daisychain von 14 Switches mit hunderten angeschlossenen
> Devices nachgedacht hat

Bei 14 linear kaskadierten 2-Port Switches sind es maximal 16. Jene 
Nodes am SPI, plus 2 an den Enden. Diese Chips sind offensichtlich 
explizit für solche Szenarien gebaut.

: Bearbeitet durch User
von foobar (Gast)


Lesenswert?

> Es sind maximal 200 Bytes die aber so eine Art HartBit Funktion spielen
> müssen sprich jede 300 ms an alle Teilnehmern - Sicherheitsrelevante
> Funktionen.

Mit UDP alleine wirst du diese Garantie nie bekommen.

IP (und auch UDP) arbeiten so, dass, wenn ein Paket nicht übertragen 
werden kann, es sang und klanglos weggeschmissen wird.  Eine dieser 
Situationen ist, wenn ein Port überlastet ist (volle Bandbreite 
ausgenutzt).  Und dies ist kein seltenes Ereignis, das passiert bei 
jeder TCP-Verbindung: die Übertragungsrate wird Schritt für Schritt 
erhöht, bis Pakete verloren gehen.  Und dein UDP-Broadcast ist auch nur 
ein normales IP-Paket.  Wenn auf dem Port gerade viel los ist, wird das 
Paket weggeschmissen.

Wenn das gesamte Netz nicht ausschließlich für diese 
sicherheitsrelevante low-bandwidth Anwendung reserviert ist, dürfte das 
schwierig werden.

von (prx) A. K. (prx)


Lesenswert?

Die im Screeenshot erwähnte Ringtopologie sollte man evtl mal näher 
beleuchten, zwecks Ausfallsicherheit. In ein übliches Ethernet-Kabel 
kriegt man ja zwei 10-Mbit-Stränge rein, einer hin und einer wieder 
zurück. Das hilft nicht gegen die Axt, aber gegen eine defekte Node.

Und vielleicht auch mal reinsehen, wozu der ominöse ADIN1100 gut ist.

: Bearbeitet durch User
von Walter K. (walter_k488)


Lesenswert?

Nxitimi schrieb:
> Hallo zusammen
>
> Eine Frage an die Experten. Ich habe 14 Switches, die ich über Daisy
> Chain Topology verbunden sein müssen. Die Frage, die ich mir stelle, ist
> halt "Broadcasting" und Performanz?
>
> 1) Ist Broadcasting mit mehrere Switches über Daisy Chain Topology
> überhaupt möglich? Es sind ja mehrere Switches . . .
>
> 2) Performanz: Hat jemand Erfahrung mit so viele Switche?
>

Und viele Beiträge später kommt dann

„compliant with the IEEE® 802.3cg-2019TM Ethernet standard for long 
reach 10 Mbps single pair Ethernet (SPE). …“

von Bichael M. (Gast)


Lesenswert?

Nxitimi schrieb:
> Und wir haben mit mehrere Kollegen diskutiert und konnte die nicht
> überzeugen dass Broadcasting in dem Fall einfach nichts bringt. Weil
> eben die Information nacheinander fliesst.

Auf Absenderseite bringts natürlich trotzdem was, denn der muss nur ein 
Paket raus hauen, nicht 100. Und deine Switches müssen nur 1 Paket 
weiterleiten, nicht 100. Also ja, Broadcasting bringt natürlich was, man 
darf halt nur nicht so naiv sein zu glauben das Paket käme bei allen 
Empfängern in der gleichen Mikrosekunde an.

Die Latenz pro Switch wird irgendwo zwischen 1µs und 150µs liegen (bei 
Kollisionen am Netz entsprechend mehr, aber das hat ein shared Medium so 
an sich). Den Rest kannst du ja ausrechnen, die 300ms sind da weit weg 
davon.

von DerEinzigeBernd (Gast)


Lesenswert?

Das Zeitverhalten dieser Switch-Kette bei 10BaseT1L dürfte nur 
unwesentlich besser sein als das, was man in der vorderen Altsteinzeit 
(also kurz nach dem Aussterben der Dinosaurier) als 10Base2 oder 10Base5 
kannte. Das war 10-MBit-Ethernet auf Koaxkabel, halbduplex-Betrieb, und 
eine Kollisionsdomäne (d.h. jeder Teilnehmer am Bus sieht jedes einzelne 
Paket).

Zwar sind die Dinger hier Switches, so daß die angeschlossenen Geräte 
das Elend auf dem Bus nur dann mitbekommen, wenn sie selbst beteiligt 
sind, aber ein Paket von einem Teilnehmer an eine Ende zum anderen Ende 
der Stichleitung muss logischerweise jeden einzelnen Switch passieren. 
Bei viel Traffic zwischen den einzelnen Teilnehmern wird sich das 
entsprechend auswirken.

Immerhin ist hier von nur 14 Switches die Rede, so daß das Limit von 16 
MAC-Adressen dieser Switches keine Probleme machen wird.

von Klaus (feelfree)


Lesenswert?

Bichael M. schrieb:
> Die Latenz pro Switch wird irgendwo zwischen 1µs und 150µs liegen

Store-and-Forward-Architektur, d.h. ein Frame muss erst komplett 
empfangen werden, bevor er weitergesendet wird.
Minimale Framegröße 64 Byte = 512 bit (+ 64 Preamble) = 576 bit
Minimale Übertragungszeit 576 bit / 10 MBit/s = 58µs.
Schneller wird's auf keinen Fall.

: Bearbeitet durch User
von Sebastian (Gast)


Lesenswert?

Man könnte ja auch Gbit-Switche mit Gbit-Interconnects nehmen und nur 
die Endgeräteports auf 10Mb drosseln ...

LG, Sebastian

von Bichael M. (Gast)


Lesenswert?

foobar schrieb:
>> Es sind maximal 200 Bytes die aber so eine Art HartBit Funktion spielen
>> müssen sprich jede 300 ms an alle Teilnehmern - Sicherheitsrelevante
>> Funktionen.
>
> Mit UDP alleine wirst du diese Garantie nie bekommen.
>
> IP (und auch UDP) arbeiten so, dass, wenn ein Paket nicht übertragen
> werden kann, es sang und klanglos weggeschmissen wird.  Eine dieser
> Situationen ist, wenn ein Port überlastet ist (volle Bandbreite
> ausgenutzt).  Und dies ist kein seltenes Ereignis, das passiert bei
> jeder TCP-Verbindung: die Übertragungsrate wird Schritt für Schritt
> erhöht, bis Pakete verloren gehen.  Und dein UDP-Broadcast ist auch nur
> ein normales IP-Paket.  Wenn auf dem Port gerade viel los ist, wird das
> Paket weggeschmissen.
>
> Wenn das gesamte Netz nicht ausschließlich für diese
> sicherheitsrelevante low-bandwidth Anwendung reserviert ist, dürfte das
> schwierig werden.

TCP ist eben durch diesen Retrymechanismus für Echtzeitanwendungen 
unbrauchbar, weshalb Profinet und Co entweder direkt auf Ethernet oder 
UDP aufsetzen.
Wer ein Echtzeit-Protokoll basteln möchte ist gut beraten es davon 
abzukupfern. Entweder ohne Retry und Busfehler bei Paketverlust, oder 
einem geschickten Retrymechanismus.

von Klaus (feelfree)


Lesenswert?

Sebastian schrieb:
> Man könnte ja auch Gbit-Switche mit Gbit-Interconnects nehmen und nur
> die Endgeräteports auf 10Mb drosseln ...

Könnte man, genauso wie man einen Brief per 40-Tonner bis direkt vor die 
Haustüre fahren kann und dann vom Briefträger in den Briefkasten 
einwerfen lassen kann.

von (prx) A. K. (prx)


Lesenswert?

Klaus schrieb:
> Store-and-Forward-Architektur

Der Chip kann cut through.

von (prx) A. K. (prx)


Lesenswert?

DerEinzigeBernd schrieb:
> Das Zeitverhalten dieser Switch-Kette bei 10BaseT1L dürfte nur
> unwesentlich besser sein als das, was man in der vorderen Altsteinzeit
> (also kurz nach dem Aussterben der Dinosaurier) als 10Base2 oder 10Base5
> kannte.

Andersrum. Es ist schlechter als im Koax. Abgesehen von Kollisionen 
spielte da nur die begrenzte Ausbreitungsgeschwindigkeit im Kabel eine 
Rolle. Selbst - im Idealfall - cut through quer durch die Kette sind 
hier einige gespeichterte Bits pro Node zu überwinden.

Allerdings hätte man in dieser Ära Token-Ring in Erwägung gezogen. Das 
braucht zwar auch einige Bits pro Node, arbeitete aber deterministisch. 
In manchen Maschinensteuerungen ist aus solchen Gründen auch noch das 
archaische ARCNET im Einsatz.

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

(prx) A. K. schrieb:
> Der Chip kann cut through.

Ja, aber dann arbeitet er nur unmanaged, ohne CPU, als Repeater zwischen 
beiden Ports. Das ist hier nicht brauchbar.

von Frank K. (fchk)


Lesenswert?

Nxitimi schrieb:

> Eine Frage an die Experten. Ich habe 14 Switches, die ich über Daisy
> Chain Topology verbunden sein müssen. Die Frage, die ich mir stelle, ist
> halt "Broadcasting" und Performanz?

Du solltest Dir mal Ethercat anschauen. Das ist zwar eine Art Ethernet, 
aber ein spezielles. Dort ist es üblich, dass jeder Slave einen 
Input-Port und einen Output-Port hat und alle Slaves in einer Kette 
hängen. Jeder Slave hat einen speziellen Ethercat-Chip (normale 
Ethernet-Hardware geht hier nicht), der ein Ethercat-Paket empfängt, 
sich die für ihn vorgesehenen Informationen aus dem Paket extrahiert, 
seine eigenen Daten in das Paket an die dafür vorgesehenen Stellen 
einfügt und dann an den nächsten Slave schickt - alles in Hardware, 
während das Paket durch den Ethercat-Chip durchläuft. Der letzte Slave 
schickt die Daten dann wieder an den Master. Das ist dann alles exakt 
deterministisch und kollisionsfrei und ist hunderttausendfach im 
industriellen Einsatz. Dabei wird kein IP und kein TCP oder UDP 
verwendet.

fchk

von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Nxitimi schrieb:
>> Was würden Sie von dem halten?
>
> Moooment - in Zeiten von Switches mit 10 Gbit/s geht es hier um
> archaische 10 Mbit/s? Das kommt etwas überraschend.
Klar. Du hast die Reichweite nicht. Sorry. 2km Entfernung. Innerhalb von 
diesem Abstand werden 14 Teilnehmer einpaltziert, aus dem Grund "Single 
Pair Ethernet".
>> Haben Sie evtl. Erfahrungen in der Richtung.
>
> Mit Ethernet unter Echtzeitbedingungen nicht.

von Frank K. (fchk)


Lesenswert?

Nxitimi schrieb:
>> Nxitimi schrieb:
>>> Was würden Sie von dem halten?
>>
>> Moooment - in Zeiten von Switches mit 10 Gbit/s geht es hier um
>> archaische 10 Mbit/s? Das kommt etwas überraschend.
> Klar. Du hast die Reichweite nicht. Sorry. 2km Entfernung. Innerhalb von
> diesem Abstand werden 14 Teilnehmer einpaltziert, aus dem Grund "Single
> Pair Ethernet".

Bei einer sicherheitskritischen Anwendung würde ich vor allem eines 
halten: ganz viel Abstand. Da sind einfach zu viele Komponenten, die das 
System zum Einsturz bringen können.

Von der Zuverlässigkeit, der Latenz und der Anzahl der Fehlerquellen 
insbesondere unter dem Hintergrund einer sicherheitskritischen Anwendung 
ist eine Sterntopologie mit einem zentralen gemanageten Switch (der kann 
dann Alarm schlagen, wenn eine Verbindung weg ist), von dem je eine 
Verbindung zu jedem Teilnehmer abgeht, deutlich besser. Die Reichweite 
kannst Du mit Monomode-Glasfaser und LX(Long Range)-SFP-Modulen (1310nm) 
problemlos überbrücken.

fchk

von der_eine (Gast)


Lesenswert?

Nxitimi schrieb:
> Innerhalb von 300[ms] muss die Information da sein, sonst geht alles in
> die Hose.

Servus,

UDP und sichere (im Sinne von: garantierte) Übertragung ist ein 
Widerspruch. UDP ist eben per sich NICHT gesichert, sondern die Daten 
werden ins Netzwerk gebrüllt, und wenn diese ankommen: gut - wenn nicht: 
merkt weder Absender noch Empfänger.
Wenn es schon unbedingt UDP sein muß, daß auf einer höheren 
Protokollebene noch eine Absicherung rein.

Was heißt denn: "Alles geht in die Hose"? Stirben dann hunderte Leute 
auf einen Schlag, oder kommt nur ein Fehler ins Log? Wahrscheinlich 
liegt die Auswirkung irgendwo dazwischen.

Das beste Vorgehen ist hier vermutlich in 2 Stoßrichtungen.

1. Fehlervermeidung
Ein möglichst robustes Protokoll mit geeigneter Datenübertragung, damit 
innerhalb von 300ms auch unter möglichst vielen Störeinflüssen die 
Informationen ankommen

2. Fehlerbeherrschung
Sollten die Daten nicht (rechtzeitig) ankommen (völlig egal aus welchem 
Grund, es wird einfach fix angenommen, die Daten kommen nicht an), soll 
die Auswirkung möglichst klein sein. Also kein Personen- oder 
Sachschaden, sondern ... [das kommt jetzt sehr auf die Anlage an, also 
selber nachdenken].


Gruß

von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Die im Screeenshot erwähnte Ringtopologie sollte man evtl mal näher
> beleuchten, zwecks Ausfallsicherheit. In ein übliches Ethernet-Kabel
> kriegt man ja zwei 10-Mbit-Stränge rein, einer hin und einer wieder
> zurück. Das hilft nicht gegen die Axt, aber gegen eine defekte Node.
>
> Und vielleicht auch mal reinsehen, wozu der ominöse ADIN1100 gut ist.

ADIN1100 gut? Du meinst PHY to PHY Verbindung ohne Switch(ADIN2111) ?

von Nxitimi (nxitimi_tol)


Lesenswert?

DerEinzigeBernd schrieb:
> Immerhin ist hier von nur 14 Switches die Rede, so daß das Limit von 16
> MAC-Adressen dieser Switches keine Probleme machen wird.
Wo siehst du das mit 16 MAC-Adressen? An einem Switch? Oder Maximal im 
Netz?

von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Fleischwarenfachverkäufer schrieb:
>> Also das wäre ja vielleicht eine Info für früher gewesen bevor man schon
>> über eine Daisychain von 14 Switches mit hunderten angeschlossenen
>> Devices nachgedacht hat
>
> Bei 14 linear kaskadierten 2-Port Switches sind es maximal 16. Jene
> Nodes am SPI, plus 2 an den Enden. Diese Chips sind offensichtlich
> explizit für solche Szenarien gebaut.

Maximal 16 ?? WO steht das?

von Nxitimi (nxitimi_tol)


Lesenswert?

Frank K. schrieb:
> Nxitimi schrieb:
>
>> Eine Frage an die Experten. Ich habe 14 Switches, die ich über Daisy
>> Chain Topology verbunden sein müssen. Die Frage, die ich mir stelle, ist
>> halt "Broadcasting" und Performanz?
>
> Du solltest Dir mal Ethercat anschauen.
> fchk
Die Übertragungsgeschwindigkeit bei 2 km?

von DerEinzigeBernd (Gast)


Lesenswert?

Nxitimi schrieb:
> Wo siehst du das mit 16 MAC-Adressen? An einem Switch? Oder Maximal im
> Netz?

Das steht im Datenblatt des Switches.

Da alle Switches in Reihe geschaltet werden (die haben nur zwei Ports!), 
ist die Auswirkung bei mehr als 16 beteiligten Geräten (jedes Gerät 
benutzt so einen Switch zur Anbindung) recht einfach zu verstehen.

Stell' Dir z.B. 32 Geräte vor, also 32 in Reihe geschaltete Switches.

Ein Gerät am Ende der Kette sendet Daten an alle anderen Geräte, damit 
läuft in den ersten Geräten der Kette der MAC-Buffer über, denn es 
werden mehr als 16 verschiedene Adressen verwendet. Nicht überlaufen 
werden nur die letzten 16 Geräte der Kette.

Und nun möchte z.B. das achte Gerät in der Kette Daten an ein 
benachbartes Gerät senden. Da der MAC-Buffer übergelaufen ist, kann es 
nicht anders, als die Daten in beide Richtungen zu senden (d.h. auf 
beiden Ports gleichzeitig auszugeben).

von Nxitimi (nxitimi_tol)


Lesenswert?

DerEinzigeBernd schrieb:
> Nxitimi schrieb:
>> Wo siehst du das mit 16 MAC-Adressen? An einem Switch? Oder Maximal im
>> Netz?
>
> Das steht im Datenblatt des Switches.

Würde Broadcast die Lage etwas entspannen?

von Sebastian (Gast)


Lesenswert?

DerEinzigeBernd schrieb:
> Ein Gerät am Ende der Kette sendet Daten an alle anderen Geräte, damit
> läuft in den ersten Geräten der Kette der MAC-Buffer über, denn es
> werden mehr als 16 verschiedene Adressen verwendet.

Bei Broadcast wird nur eine MAC-Adresse (halt eine 
Broadcast-MAC-Adresse) verwendet.

LG, Sebastian

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
> ADIN1100 gut? Du meinst PHY to PHY Verbindung ohne Switch(ADIN2111) ?

Die Rolle, die er im Bild im Datasheet hat. Hab nicht näher 
nachgeforscht.

von (prx) A. K. (prx)


Lesenswert?

Nxitimi schrieb:
>> Bei 14 linear kaskadierten 2-Port Switches sind es maximal 16. Jene
>> Nodes am SPI, plus 2 an den Enden. Diese Chips sind offensichtlich
>> explizit für solche Szenarien gebaut.
>
> Maximal 16 ?? WO steht das?

Wenn jede Node zwei Nachbar-Switches hat, dann sind beide Ports belegt 
und jedes Gerät hängt am SPI seines Chips. Die beiden Endnodes haben je 
einen Port frei, ergibt maximal 14+2=16 Geräte und maximal 16 
MAC-Adressen von Geräten, wenn kein weiterer Switch an den Endnodes 
hängt und jedes Gerät nur 1 MAC-Adresse nutzt.

: Bearbeitet durch User
von Nxitimi (nxitimi_tol)


Lesenswert?

(prx) A. K. schrieb:
> Nxitimi schrieb:
>>> Bei 14 linear kaskadierten 2-Port Switches sind es maximal 16. Jene
>>> Nodes am SPI, plus 2 an den Enden. Diese Chips sind offensichtlich
>>> explizit für solche Szenarien gebaut.
>>
>> Maximal 16 ?? WO steht das?
>
> Wenn jede Node zwei Nachbar-Switches hat, dann sind beide Ports belegt
> und jedes Gerät hängt am SPI seines Chips. Die beiden Endnodes haben je
> einen Port frei, ergibt maximal 14+2=16 Geräte und maximal 16
> MAC-Adressen von Geräten, wenn kein weiterer Switch an den Endnodes
> hängt und jedes Gerät nur 1 MAC-Adresse nutzt.

Gibts evtl. andere Switche die mehr können? Finde grad nicht :-(

von Bichael M. (Gast)


Lesenswert?

Selbst billige Netgear-Switches für den Heimgebrauch können tausende 
MAC-Adressen halten. Vergiss die Frührentner hier, die leben im vorigen 
Jahrtausend.

Ändert natürlich nix dran dass es Blödsinn ist Unicast zu verwenden wenn 
ich eigentlich Broadcast/Multicast möchte, und die ganze Sache nicht 
gerade schneller macht.

von Frank K. (fchk)


Lesenswert?

Nxitimi schrieb:
> Frank K. schrieb:
>> Nxitimi schrieb:
>>
>>> Eine Frage an die Experten. Ich habe 14 Switches, die ich über Daisy
>>> Chain Topology verbunden sein müssen. Die Frage, die ich mir stelle, ist
>>> halt "Broadcasting" und Performanz?
>>
>> Du solltest Dir mal Ethercat anschauen.
>> fchk
> Die Übertragungsgeschwindigkeit bei 2 km?

Lichtgeschwindigkeit? Wobei Ethercat eh nur 100MBit ist.

fchk

von Bichael M. (Gast)


Lesenswert?

Bichael M. schrieb:
> Selbst billige Netgear-Switches für den Heimgebrauch können tausende
> MAC-Adressen halten. Vergiss die Frührentner hier, die leben im vorigen
> Jahrtausend.
>
> Ändert natürlich nix dran dass es Blödsinn ist Unicast zu verwenden wenn
> ich eigentlich Broadcast/Multicast möchte, und die ganze Sache nicht
> gerade schneller macht.

Nachsatz vergessen: es muss sich halt wer dran setzen der halbwegs 
Ahnung hat und nicht den erstbesten Chip auswählt der ihm vor die Maus 
läuft.

von Nxitimi (nxitimi_tol)


Lesenswert?

Klaus schrieb:
> Ja, aber dann arbeitet er nur unmanaged, ohne CPU, als Repeater zwischen
> beiden Ports. Das ist hier nicht brauchbar.

Cut through (port to port or SPI host to port). steht drin. Sollte 
eigentlich funktionieren.

von Nxitimi (nxitimi_tol)


Lesenswert?

Frank K. schrieb:
> Lichtgeschwindigkeit? Wobei Ethercat eh nur 100MBit ist.

Aber wie können wir 2 km abdecken? Ethercat kann doch nur 100 m 
Reichweite bedienen.

von Sebastian W. (wangnick)


Lesenswert?

Nxitimi schrieb:
> Aber wie können wir 2 km abdecken?

Dann braucht ihr halt 21 Switches, alle 100m einen ...

LG, Sebastian

von Wo laufen Sie denn? (Gast)


Lesenswert?

Nxitimi schrieb:

> Es sind maximal 200 Bytes die aber so eine Art HartBit Funktion spielen
> müssen sprich jede 300 ms an alle Teilnehmern - Sicherheitsrelevante
> Funktionen.

Und dann 14 hintereinander, wo bleibt da die Sicherheit?

von Sigi S. (sermon)


Lesenswert?

Hier sprechen die Blinden von der Farbe.
Dabei steht im Netz der Netze alles zum Nachlesen bereit.
Im Zeitalter wo alle, sogar an unseren Hochschulen, nur noch 
"Kompetenzen"
erwerben, nutzen diese Kompetenzträger noch nicht mal die freien 
"Kompetenzquellen".
Möglicherweise fehlen die Links in den ausgehändigten und vorgekauten 
Scripts?

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Nxitimi schrieb:
> Frank K. schrieb:
>> Lichtgeschwindigkeit? Wobei Ethercat eh nur 100MBit ist.
>
> Aber wie können wir 2 km abdecken? Ethercat kann doch nur 100 m
> Reichweite bedienen.

Mit LWL-Umsetzern natürlich mehr.

Aber ich würde das mit der Daisy-Chain Geschichte eh ganz lassen.

Siehe meinem Beitrag
Beitrag "Re: UDP Broadcast mehrere Switches"

Einen zentralen Switch mit SFP(+)-Schächten verwenden. Sowas z.B.
https://mikrotik.com/product/crs317_1g_16s_rm

Dafür passende SFP-Module für jede Seite:
https://mikrotik.com/product/S-31DLC20D-181
Die können 20km mit Singlemode-Fasern OS1/OS2 überbrücken. Es gibt auch 
Module für 40km und für 80km.

Auf der anderen Seite ein entsprechendes Gerät mit dem gleichen 
SFP-Modul.

Das lässt sich zentral überwachen, ist erweiterbar, und wenn es irgendwo 
im Feld ein Problem gibt, dann ist nur diese eine Station weg und nicht 
die halbe oder die ganze Kette. Und diese Technik ist nicht brandneu wie 
SPE, sondern wie wird in der Industrie seit >20 Jahren zu tausenden 
eingesetzt, mit Geschwindigkeiten bis zu 25GBit/s pro Faser und mehr.

Wenn Ihr erweiterten Temperaturbereich braucht, gibts auch dafür 
Lösungen. Erdkabel ist auch kein Problem, auch fertig konfektioniert mit 
LC-Steckern.

fchk

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.