Hallo, ich hab diesbezüglich schonmal nebenbei in einem anderen Thread gefragt, aber jetzt solls nochmal konkret um dieses Thema "Ethernet Switches kaskadieren" gehen. Und zwar wäre es interessant zu wissen, ob jemand weiß ob es Probleme gibt, wenn man mehrere Ethernet Switches (15-20) kaskadiert. Ich würde gerne ein Projekt machen, bei dem verschiedene Inhalte u.a. Videos auf Displays angezeigt werden. Rein von der Datenmenge (Videos) muss es wahrscheinlich Ethernet werden. Und vom Platzangebot geht es sich leider nicht aus jeden Client mit einem Netzwerkkabel an einen zentralen Switch anzuschließen. D.h. ich müsste ca. 15-20 Clients kaskadieren. Möglich wäre das z.B. mit 3-Port Ethernet Switch ICs von Micrel. Jedoch würde ich gerne vorher wissen, ob es funktioniert, wenn ich dann z.B. per Multicast ein Video an die Clients streame! Hat jemand Erfahrung im kaskadieren von Netzwerk Switches bzw. weiß jemand ob es da Limitierungen gibt? Danke, Andreas
:
Verschoben durch User
Es gibt Grenzen, afaik wurde die bei ca. 5 Stück gezogen. In der Praxis geht mal mehr mal weniger. Mit 15-20 Stück bist du auf jeden Fall über dem Limit, das wird nicht mehr gut gehen. Mit Layer 3 Switchen auf IP ebene würde das jedoch klappen.
Aus welchem Grund sollte die Anzahl der hintereinandergeschalteten Switches relevant sein? Soweit ich weiß, ist lediglich die Gesamtanzahl an MAC-Adressen begrenzt durch die Routingtabellengröße, die üblicherweise irgendwo im Bereich einiger 10000 Adressen liegt. Grüße, Peter
http://de.wikipedia.org/wiki/Switch_%28Netzwerk%29#Mehrere_Switches_in_einem_Netzwerk > Die Obergrenze hat hier nichts mit einer maximalen Kabellänge zu tun, > sondern hängt von der Größe der Adresstabelle (SAT) ab. Bei aktuellen > Geräten der Einstiegsklasse sind oft 500 Einträge (oder mehr) möglich, > das begrenzt die maximale Anzahl von Knoten (~Rechnern) auf ebendiese 500. > Kommen mehrere Switches zum Einsatz, so begrenzt das Gerät mit der > kleinsten SAT die maximale Knotenanzahl. Hochwertige Geräte können leicht > mit mehreren tausend Adressen umgehen. Wird die maximale Zahl > überschritten, so passiert das gleiche wie beim MAC-Flooding, folglich > bricht die Performance drastisch ein.
Afaik deshalb, weil irgend wann die Verzögerungen der Switche zu groß werden, mein Stnad ist aber auch schon 10 Jahre alt.
Es kommt auf die Stack-Tiefe an. Mir ist noch nicht klar, wie Du verkabeln willst: Bei einem 3er-Switch 1 in, 1 out zum Video, 1 out zum nächsten Switch? Dann liegen alle 20 "in Reihe". Nicht gut. > Und vom Platzangebot geht es sich leider nicht aus jeden Client > mit einem Netzwerkkabel an einen zentralen Switch anzuschließen. Baue lieber einen Binärbaum auf aus 1x 4er- und 3x 8er-Switchen (3x7=21 Displays): 1. Ebene 1 Stück 4er: 1x in 3x out zu je einem 8er 2. Ebene 3 Stück 8er: 1x in vom 4er 7x out zum Display So liegen zwischen Quelle und Ziel nur 2 Switche. Zur Not geht auch in 3 Ebenen nur mit 1+3+9=13 4ern (max. 9*3=27 Displays): 1. Ebene 1 Stück 4er: 1x in von der Quelle 3x out zu je einem 4er 2. Ebene 3 Stück 4er: 1x in vom 1. 4er 3x out zum 3. 4er 3. Ebene 9 Stück 4er: 1x in vom 2. 4er 3x out zum Display
eProfi schrieb: > Es kommt auf die Stack-Tiefe an. > Mir ist noch nicht klar, wie Du verkabeln willst: > Bei einem 3er-Switch 1 in, 1 out zum Video, 1 out zum nächsten Switch? > Dann liegen alle 20 "in Reihe". Nicht gut. Leider wäre genau das der Plan. Der "Ethernet Switch IC" ist direkt auf der Platine und hat nach außen 2 physikalische Ethernet Ports. Der 3. Port ist für den Prozessor des Gerätes selbst (R)MII. D.h. ich hätte tatsächlich 15-20 Switches "in Reihe" (1. Port: "Eingang"; 2. Port: "Ausgang"; 3. Port: "Device selbst"). Noch kurz zu deiner Anmerkung "Nicht gut". Grundsätzlich würde ich dir mal gefühlsmäßig zustimmen und sagen, wenns anders geht, dann lieber anders machen. Aber was passiert, wenn 20 Switches in Reihe geschaltet sind? IMHO würd ich sagen, dass z.B. der erste Switch "nur" eine Tabelle von MAC Adressen macht, die an seinem "Ausgangsport" und das wären z.B. 20 Stück. Sollte für einen Switch im Grunde nicht das Problem sein. Außerdem wird jeder Switch eine kleine Zeitverzögerung bewirken. Irgendwo im Internet hab ich was von 8-20µs gelesen. Bei 20 Switches wären das 400µs. Find ich jetzt auch noch nicht so schlimm (selbst bei ein paar Millisekunden wärs für meine Anwendung ausreichend). Gibts noch andere Effekte, die ich nicht bedacht habe?? >> Und vom Platzangebot geht es sich leider nicht aus jeden Client >> mit einem Netzwerkkabel an einen zentralen Switch anzuschließen. > Baue lieber einen Binärbaum auf aus 1x 4er- und 3x 8er-Switchen (3x7=21 > Displays): Wie gesagt ist der Platz sehr begrenzt, da die Displays fix in die Rückenlehne von Stühlen eingebaut werden und ich im Grunde keine zusätzlichen "externen" Switches verwenden kann. Die Verkabelung sollte eben von einem Stuhl zum nächsten passieren. Danke schonmal für die Beiträge. Für weitere Anregungen wäre ich natürlich sehr dankbar! mfg Andreas
WLAN ist mir ehrlich gesagt zu unsicher was die Verbindungsqualität betrifft. Vorallem wenn aus den 20 vielleicht mal 50 oder 100 Clients werden sollen (nicht alle kaskadiert sondern jeweils ca. 20 Clients "in Serie"). Ich hab bis jetzt zumindest die Erfahrung gemacht, dass WLAN für Streaming Dienste nicht unbedingt zufriedenstellend läuft.
> ist lediglich die Gesamtanzahl > an MAC-Adressen begrenzt durch die > Routingtabellengröße Das war auch mein erster Gedanke, aber ist es nicht so, dass ein Switch ein Paket an eine unbekannte (weil in der Routingtabelle nicht mehr vorhandene) MAC-Adresse an alle Ports weiterreicht? Insofern müsste dies ja funktionieren - auch wenn gefühlt die Kette irgendeine Maximallänge haben müsste. Volker
Andreas Auer schrieb: > Noch kurz zu deiner Anmerkung "Nicht gut". Grundsätzlich würde ich dir > mal gefühlsmäßig zustimmen und sagen, wenns anders geht, dann lieber > anders machen. Aber was passiert, wenn 20 Switches in Reihe geschaltet > sind? Ich glaube mir ist dein gewünschtes Setup bzw der Datenfluss noch nicht ganz klar. Aber wenn etwas am ersten Switch hängt - mit etwas das am letztwn Switch hängt kommunizieren will, dann müssen die Daten durch viele switche durch, die jeweils nur mit einem Kabel verbunden sind? Wenn da andere auch noch Kommunizieren wollen, dann werden diese Inter-Switch Verbindungen zum Flaschenhals ... Ich würde erwarten, dass dir bei diesem Setup die Datenraten massiv einbricht ... was letztlich bedeutet, dass du auch gleich WLAN benutzen kannst.
Für Broadcast und dieses Setup würde vermutlich ein Hub auch bessere Dienste leisten.
> ob es funktioniert, wenn ich dann z.B. per Multicast > ein Video an die Clients streame ISt es denn ein beabsichtigter optischer Effekt, daß bei der geplanten Kaskadierung in der Wiedergabe aller Clients ein gewisser Zeitversatz auftritt?
Wegstaben Verbuchsler schrieb: >> ob es funktioniert, wenn ich dann z.B. per Multicast >> ein Video an die Clients streame > > ISt es denn ein beabsichtigter optischer Effekt, daß bei der geplanten > Kaskadierung in der Wiedergabe aller Clients ein gewisser Zeitversatz > auftritt? Nein, ist im Grunde kein beabsichtigter optischer Effekt. Im Gegenteil! Am liebsten wäre mir, wenn es keinen Zeitversatz geben würde. Das zu erreichen wird aber noch viel schwieriger denke ich. Kleine Unterschiede im Millisekundenbereich werden nicht wirklich gravierend sein und stören mich deshalb auch nicht. Andere Frage... weiß jemand wie so Entertainment Systeme in großen Flugzeugen realisiert sind? Wird dort Ethernet in Stern-Topologie verwendet oder kommt ein ganz anderer Bus zum Einsatz?
Nimm einen 24 Port Switch und mach es Stternfoermig. Spanningtree erlaubt max. 7 Bridges.
Genau für so etwas würde sich ein Hub und Multicast anbieten. Ein Switch wäre eher von Nachteil.
Bei rein linearer Topologie braucht er keinen Spanning Tree. Hat aber einen hässlichen Nachteil: Wenn eine Station hopps ist, ist jede andere dahinter tot.
Andreas Auer schrieb: > Andere Frage... weiß jemand wie so Entertainment Systeme in großen > Flugzeugen realisiert sind? Wird dort Ethernet in Stern-Topologie > verwendet oder kommt ein ganz anderer Bus zum Einsatz? Aktuelle Ethernet-Übertragungsverfahren sind Punkt-zu-Punkt-Verbindungen mit Sternkoppler, und so wird es überall auch implementiert, alleine schon um zu vermeiden, dass alle Endgeräte ausfallen, wenn irgendwo vorne in der Kette ein Problem ist. Wartung und Fehlersuche sind teuer. Im Automotive-Bereich wird inzwischen gerne MOST verwendet, den Media Oriented Systems Transport, und das oft über LWL wegen Gewichtsersparnis. Eventuell wäre für Dich IEEE1394 Firewire besser geeignet. Das findet sich auch in der Automobilindustrie für Infotainment-Zwecke wieder. Vorteil: Du kannst über das Kabel auch gleich noch die Versorgungsspannung (8-33V bei 1.5A) transportieren. In der Automobilindustrie wird aber ein anderer Stecker verwendet, der eine Verriegelung bietet. fchk
A. K. schrieb: > Hat aber einen hässlichen Nachteil: Wenn eine Station hopps ist, ist > jede andere dahinter tot. Das stimmt leider. Darum wird man aber wahrscheinlich nicht herumkommen bei linearer Ethernet Topologie.
> Für Broadcast und dieses Setup würde vermutlich ein Hub auch bessere > Dienste leisten. DAS würde ich in keinem Fall tun.
Anwendungen wie diese werden mit Multicasts bedient. Das heisst dann einen ARP Eintrag für alle clients. Da ist dann generell ein Hub schneller als ein Switch. Für Multicasts ist Kaskadierung sowie limit bez. ARP kein Problem, und für andere Anwendungen setzt man das Timeout einfach rauf, so kann man anstelle der 5 Levels auch 15 bewältigen, alles eine Kostenfrage.
CHH schrieb: > Ich glaube mir ist dein gewünschtes Setup bzw der Datenfluss noch nicht > ganz klar. Aber wenn etwas am ersten Switch hängt - mit etwas das am > letztwn Switch hängt kommunizieren will, dann müssen die Daten durch > viele switche durch, die jeweils nur mit einem Kabel verbunden sind? > Wenn da andere auch noch Kommunizieren wollen, dann werden diese > Inter-Switch Verbindungen zum Flaschenhals ... > Ich würde erwarten, dass dir bei diesem Setup die Datenraten massiv > einbricht ... was letztlich bedeutet, dass du auch gleich WLAN benutzen > kannst. Im Grunde hab ich einen Server, der verschiedenen Content bereitstellt. Einerseits vielleicht Videostreams, andererseits aber auch z.B. HTML Seiten.
1 | Server <-----> Switch <-----> Switch <-----> Switch .... |
2 | | | | |
3 | CPU 1 CPU 2 CPU 3 |
Der 3-Port Switch und die "CPU" befinden sich auf der selben Platine. Also es ist kein externer Switch als Gerät sondern "nur" ein Halbleiter IC. Im einfachsten Fall rufen alle Clients irgendwelche HTML Seiten vom Server ab. Das sind dann burst-artige Datenübertragungen, die über ein 100MBit Netzwerk kein großes Problem darstellen sollten (trotz der ganzen Switches). Der andere Fall ist, dass der Server per Multicast an alle Clients einen Videostream (z.B. 1MBit H264 Video) überträgt. Dann sollte doch trotzdem noch genug Bandbreite zur Verfügung sein, um etwaige HTML Seiten abzurufen, oder? Dass beim Ausfall eines Devices die dahinterliegenden Devices keine Daten mehr bekommen, ist mir bewusst.
>Das war auch mein erster Gedanke, aber ist es nicht so, dass ein Switch >ein Paket an eine unbekannte (weil in der Routingtabelle nicht mehr >vorhandene) MAC-Adresse an alle Ports weiterreicht? Ja, es ist so, dass der Switch ein Paket ohne bekanntes Routing an alle Ports sendet, auch wenn es Unicast ist. So funktioniert ja auch das erste ARP-Paket. Soweit mir bekannt ist, liegen die Timeouts von den üblichen TCP/IP-Stacks im Sekundenbereich. Die paar 100 ns Verzögerung, die ein Switch hat, sind vernachlässigbar. Anders ist es bei einem Router, da sind die Verzögerungen erheblich. Ein Switch ist normal ein FPGA oder gleich hardwired, das Paket geht also sofort raus, sobald es komplett empfangen ist. Bei einer üblichen MTU von 1500 Byte und 1GBit/sec dauert das also 1500 Byte * 8 Bit Byte 1024^3 Bit / sec = 11,2 µs vorausgesetzt, die Zeilleitung ist gerade frei. Da hätte ich bei einer Videoanwendung kein Problem damit, 100 Switches hintereinander zu hängen. Aber wie bereits gesagt, solange im Wesentlichen immer nur eine Station sendet, ist ein Hub schneller. Grüße, Peter
Hi wenns etwas mehr als ein Hobbyprojekt ist würde ich das einfach mal ausprobieren. 20 x 100MBit Switch gibts schon für unter 200€ inkl. der nötigen Patchkabel. Dann kannst du auch ein paar vernünftige Tests machen. Aus dem Bauch heraus würde ich sagen das das geht. Aber probieren ist sicher nicht verkehrt bevor du da eigene Hardware baust. Matthias
Peter Diener schrieb: > Ja, es ist so, dass der Switch ein Paket ohne bekanntes Routing an alle > Ports sendet, auch wenn es Unicast ist. So funktioniert ja auch das > erste ARP-Paket. Wobei ARP ein schlechtes Beispiel ist, weil das als Broadcast versendet wird und nie direkt geroutet werden kann. > Ein Switch ist normal ein FPGA oder gleich hardwired, das Paket geht > also sofort raus, sobald es komplett empfangen ist. Ethernet-Switches bestehen eher aus Spezialchips, beispielsweise von Broadcom, nicht aus FPGAs. Von Highend-Kisten mit brandneuen Interfaces vielleicht abgesehen. Bei grösserer Portanzahl gerne kaskadiert, also beispielsweise 24 Ports in 4 1Gb-Chips à 6 Ports und einem zentralen 10Gb-Chip. Wobei ich nicht drauf wetten würde, dass diese Fabrics auch Pakete übernehmen, die nicht per Adresstabelle geroutet werden können. Könnte mir vorstellen, dass dies der Prozessor erledigt.
Ja, ok, ARP ist kein geeignetes Beispiel. Man kann das einfach mit einem AVR-Net IO ausprobieren. Einfach mit dem ENC ein Ethernet-Paket an eine beliebige MAC-Adresse senden, ohne, dass man vorher was gesendet hat. Der Switch sendet das dann an allen anderen Ports raus. Das mit dem Hintereinanderschalten ist nur eine Latenzsache. Systeme, die deswegen nicht funktionieren, hab ich noch nie gesehen, wohl aber welche, die funktionieren und mehr als 20 Switches kaskadieren und das als Baumstruktur, nicht nur linear. Ich lasse mir aber gerne erklären, warum nicht mehr als 3 Switches kaskadiert werden dürfen (denn das ist die Meinung vieler Fachleute auf dem Gebiet). Bisher habe ich dazu weder eine vernünftige Erklärung, noch eine Norm gefunden. Dass es dadurch bei Ausfällen größere Probleme geben kann und die Fehlersuche schwieriger ist, ist keine Frage. Die Expertenmeinung sagt aber, dass es im Normalbetrieb Probleme geben kann. Diese habe ich bisher nicht beobachten können und niemand hat mir genau erklären können, wie die überhaupt auftreten könnten. Und nun soll bloß keiner sagen, das liegt an der Latenzzeit. Ein einfacher Ping dauert ja schon bis zu 1 ms bis er von der Gegenstelle beantwortet wird, welche Rolle sollten also die paar µs Verzögerung der Switches spielen?
Also Pings dauern nur unter Windows im LAN 1ms. 0,1 ms sind da realistischer, wobei die Laufzeit im Switch keine so große Rolle spielt, zumindest nicht bei einem einzelnen Switch. Bei 20 Switchen hast Du zumindest die grob 0,15 ms pro Switch (bei 100 MBit) dazwischen, die der Switch benötigt um das Paket zu empfangen um es weiter zu leiten. Quasi alle modernen Switche arbeiten nach dem Store and Forward Prinzip. Falls Du übrigens eine Möglichkeit suchst, das trotzdem noch Synchron zu bekommen, nimm ein zusätzliches PPS-Signal über einen zusätzlichen Draht und führe das Deinen Geräten zu. Damit kannst Du ungefähr eine 1µs Fehler erreichen. Alternativ kannst Du auch an jede der Enden des Stranges einen Zeitserver stellen. (oder einen Zeitserver mit 2 Ethernetports) Die Clients stellst Du dann so ein, dass jeder beide Server (z.Bsp. per Broadcast) nutzt. Damit erreichst Du ungefähr 1 ms. Falls es nur darum geht, Video an mehrere Orte zu bringen, kannst Du auch einfach Video verteilen. Entweder direkt im Basisband (unmoduliert), oder mehrere Kanäle im Breitband. Im Prinzip so wie früher beim Kabelfernsehen. Rückmeldungen über Tastendrücke kannst Du da relativ einfach niederfrequent, oder über einen zusätzlichen Draht übertragen. Lokale Graphiken kannst Du bei vielen Graphikchips auch einfügen. Das Feature das Du suchst ist "Genlock".
Christian Berger schrieb: > Also Pings dauern nur unter Windows im LAN 1ms. Wobei man das Zeitraster der Anzeige im Auge behalten sollte. Eine Stoppuhr, die nur Millisekunden auflöst, wird eben nicht weniger anzeigen.
20 Switche kaskadieren ist so unsicher wie eine Weihnachtsbaumbeleuchtungsreihenschaltung mit 20 Kerzen. Wenn schon das 2. LAN-Kabel einen Kontaktfehler hat, ist ziemlich viel finster. WLAN könnte Ihr bei 20 gemeisamen Usern auch vergessen wegen Anfälligkeit.
Angehängte Dateien:
-
incorrectstpbp1.jpg
32 KB
Switche so verkabeln wie in dem Bild. Die beiden "großen" werden als Root-Bridge konfiguriert und auch die Multicast-Quelle wird dort angeschlossen. Siehe auch hier: http://de.wikipedia.org/wiki/Spanning_Tree_Protocol Das ist eine Standard Topologie für große L2 Netze.
BillX schrieb: > http://de.wikipedia.org/wiki/5-4-3-Regel Das war früher mal mit Repeatern. Das hat wirklich nichts mehr mit der heutigen Situation zu tun.
>>5-4-3 Regel >Das war früher mal mit Repeatern. >Das hat wirklich nichts mehr mit derheutigen Situation zu tun Grund der Regel war die Kollisionsvermeidung auf der Strecke. Die Laufzeit und Zuverlässigkeit wird durch sinnloses hintereinanderschalten irgendwelcher Baugruppen NIE besser, auch heute nicht.
also wenn das nur 100MBit werden soll DANN würd ich das ganz anders machen nimm dünne cat5e kabel 5 STück damit kannst du 10 100Mbit Verbindungen machen dann noch 10 von deine kleinen Switches im Kabelkanal und von dort mit einem kabel zum Sitz bei DIESEM kabel hättest dann auch wieder 4 litzen übrig für z.b. PoE (es geht um eine Reise-Bus oder ?)
Robert L. schrieb: > (es geht um eine Reise-Bus oder ?) Nicht ganz ;-). Es geht um Stühle in einem Theater.
Reichen dir 10Mbit? Wie wäre es mit dem guten alten BNC Kabeln und Multicast als Protokoll?
Tilo Lutz schrieb: > Wie wäre es mit dem guten alten BNC Kabeln und Multicast als Protokoll? Kriegt man sowas heute überhaupt nocht?
>http://de.wikipedia.org/wiki/5-4-3-Regel
"Wird anstelle eines Hubs ein Switch verwendet, findet insoweit die
5-4-3-Regel keine Anwendung. Ein Switch ermöglicht einen
Vollduplex-Betrieb, in dem keine Kollisionen mehr auftreten können."
Dass das innerhalb von Segmenten mit Kollisionsmöglichkeit Ärger macht
ist klar, ich hab aber schon von mehreren Experten gehört, dass man das
auch mit Switches nicht machen darf. Meiner Meinung ist das nach wie vor
nur eine Latenzsache und nicht ein grundlegendes Problem bei mehr als 3
Switches.
Wenn die Anwendersoftware also geeignet auf die Latenz reagiert, sollte
es problemlos funktionieren (solange nicht Knoten ausfallen).
Im Industriebereich nehmen fast alle Protokolle die ganzen Switches in Reihe, wobei die maximale Anzahl vor allem durch die Zykluszeiten begrenzt werden. 100 und mehr Switche in Reihe sind dabei durchaus üblich. Und da so eine Autofabrik recht empfindlich auf Störungen reagiert, scheint das auch ausreichend zuverlässig zu sein. Das dürfte also funktionieren. Übrigens sind Hubs dafür vollkommen ungeeignet. Hubs reichen das elektrische Signal einfach weiter, man kann einen Hub im Prinzip auch mit ein paar Dioden aufbauen. wenn dann auch noch Half Duplex verwendet wird, dauert es eben zu lange, bis eine Kollision erkannt wird. Daher auch die Beschränkungen auf 3 oder mehr Hops. Für Switche ist das aber vollkommen egal. Ob Deine Videoanwendung aber ruckelfrei läuft, wird spannend. Dafür muss in jedem der Switche jederzeit garantiert sein, dass das Signal verzögerungsfrei durchläuft und nicht durch anderen Verkehr blockiert wird. Man kann dafür aber die Videotelegramme priorisieren, allerdings unterstützen das nicht alle Switche. Gruss Axel
Danke für die Antworten. Die letzten stimmen mich doch sehr positiv, dass das funktionieren kann! Bezüglich der Videoanwendung... ich denke, wenn die Streams nicht unbedingt HD sind (was sie bestimmt nicht sein werden) und bei einer Bitrate von etwa 1MBit sollte es da bezüglich Ruckeln nicht so große Probleme geben. Und wenns mal ruckelt ist es auch nicht so schlimm.
Axel Laufenberg schrieb: > Im Industriebereich nehmen fast alle Protokolle die ganzen Switches in > Reihe, wobei die maximale Anzahl vor allem durch die Zykluszeiten > begrenzt werden. 100 und mehr Switche in Reihe sind dabei durchaus > üblich. Wobei im Industrie-Bereich auch nicht unbedingt normales Ethernet zum Einsatz kommt, bzw. nicht "normale" Switches. Für mich wäre in dem Fall eher die Ausfallsicherheit das Tabu, in einem Theater siehts bescheiden aus, wenn nur die ersten paar Leute was sehen ;) Wie wärs damit, das reihenbasiert zu machen? Also jede Reihe hat ihre eigene Anbindung an einen zentralen Knoten? So kann maximal eine komplette Reihe ausfallen statt alles.
ReinSch schrieb: > Axel Laufenberg schrieb: > Wie wärs damit, das reihenbasiert zu machen? Also jede Reihe hat ihre > eigene Anbindung an einen zentralen Knoten? So kann maximal eine > komplette Reihe ausfallen statt alles. Genau das ist auch meine Idee. Meine Frage bezog sich im Grunde nur auf eine Reihe. Das wären ca. 15-20 Sitze.
Mach mal folgendes, besorg Dir einen der potentiellen Switche, schaub ihn auf, und schau nach, welcher IC drin ist. Im Datenblatt sollte die Latenz drin stehen.
Es werden keine Standard Switches werden sondern der Switch-IC (wahrscheinlich von Micrel) wird direkt auf der Platine untergebracht. Damit ist alles "on-board" und leicht zu verkabeln! mfg Andreas
ReinSch schrieb: > Axel Laufenberg schrieb: >> Im Industriebereich nehmen fast alle Protokolle die ganzen Switches in >> Reihe, wobei die maximale Anzahl vor allem durch die Zykluszeiten >> begrenzt werden. 100 und mehr Switche in Reihe sind dabei durchaus >> üblich. > > Wobei im Industrie-Bereich auch nicht unbedingt normales Ethernet zum > Einsatz kommt, bzw. nicht "normale" Switches. Ethernet IP verwendet z. B. normale Switches. Profinet RT kann das auch. Spezielle Switches werden eigentlich nur bei harten Echtzeitanforderungen verwendet. Da geht es aber dann eher um Zeitslot- oder andere Verfahren, die mit Ethernet nur noch am Rande was zu tun haben. > > Für mich wäre in dem Fall eher die Ausfallsicherheit das Tabu, in einem > Theater siehts bescheiden aus, wenn nur die ersten paar Leute was sehen > ;) > Naja, wenn es Mercedes verschmerzen kann, dass ein Band stillsteht, weil ein Switch ausfällt, kann man das im Kino sicher auch. Aber im Prinzip ist das natürlich richtig. Aber dafür gibt es Redundanzverfahren, bei denen man die Switche in einen Ring schliesst und mit geeigneten Protokollen (komme gerade auf den Namen nicht) den Loop logisch trennt. Bei einem Fehler in einem Switch wird dann der Ring umgeschaltet. Dafür spart man sich massenhaft Verkabelung. Gruss Axel
Genau, im Prinzip muss man ja nur einen Ring für alle Stationen bauen. Der Anfang steckt am Masterrechner an einer Netzwerkkarte und das Ende vom Ring an einer anderen Netzwerkkarte. Normalzustand: Senden über Karte 1, Paketüberwachung über Karte 2. Fällt eine Station aus, erkennt man das daran, dass Karte 2 keine Daten mehr bekommt. Fehlerzustand ein Switch ist kaputt: Beide Karte versorgen nun von den beiden Seiten des Rings alle funktionierenen Clients weiter mit Daten. So fällt nur der Bildschirm aus, der den defekten Switch hat. Grüße, Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.