technox
Goto Top

Paketkollisionen auf altem 10mbit Hub mit AUI

Guten Morgen und vorweg ja wir haben sowas noch im Einsatz.

Folgende Situation, wir haben hier noch son Asbach Yellowcable H1 Bus am Start.
(Über Vampir Klemmen mit Repeatern verbunden)
Dies wird endlich auch modernisiert. Aber um für Ausfallsicherheit zu sorgen bis es soweit ist,
will ich die Knotenpunkte redundant vor liegen haben.

Der Haupt Repeater an dem 2 der 3 ComServer laufen. Wird über ein 15Pol AUI Kabel
an einen 10MBit Hub angeschlossen. Der dann an einen Auto Sensing fähigen 10/100Mbit
Switch angeschlossen wird/wurde. Was ja bedeutet das er sich die Geschwindigkeit und den
Modus ob halb oder Vollduplex automatisch auswählt.
Welcher die Verbindung mit dem Hausnetz herstellt. Soweit so gut es läuft!
Wir haben allerdings Paket Kollisionen auf den Repeatern. Gleichzeitig ist der H1 Bus mit dem
Leitstand und den dortigen Steuerungs PCs verbunden.

Die Haustechnik liegt mir deswegen nun in den Ohren, das ihre Hochregal Steuerung die
daran angebunden ist Zeitverzögerungen besitzt - die sie sich nicht erklären können.
Ob es je anders war wage ich zu bezweifeln. Aber sie haben halt Störungen auf der Leitung.
Und schieben das auf das Netzwerk.

In einem Test um die Technik dahinter etwas besser zu verstehen habe ich mir hier mit einem
Allied TeleSyn AT-MR820TR Hub ein Testszenario aufgebaut um zu testen, wie das Verhalten
in ähnlicher Steckweise wie im Hochregal Lager zu Stande kommen kann. Das Ergebnis war,
ohne große Last läuft das ganze reibungslos! Kopiere ich aber Daten über den Hub - rauscht
die Lastanzeige auf Vollauslastung & ich erhalte massive Kollisionen auf der LED.
Dies änderte sich nicht egal ob ich einen anderen Switch eingebunden habe an dem ich die
Ports einstellen konnte (Netgear JGS524E-200EUS) oder über direkt Anbindung zweier Notebooks
auf ebenfalls verschiedener Geschwindigkeit mit 10/100 Mbit halb und Vollduplex / Autosensing.

Sobald ein Copy Job gestartet wurde, war der Hub so ausgelastet das er nonstop Kollisionen aufzeigte.

Ich habe mit so alter Technik wenig am Hut gehabt bisher. Habe aber nun die Vermutung das es sich
bei den paar Kollisionen auf dem H1 Bus (der HUB dort ist ein anderer) um normale Technologie bedingte
Kollisionen handelt die eben auftreten wenn der Datenstrom eine gewisse Auslastung überschreitet.

Die Kollisionen wären eben die einfachste Erklärung gewesen, das die Steuerung lahmt. Bis zb. eine
Gassen Freigabe weiter gegeben und zurück gemeldet wurde (dauert manchmal bis zu 5 Sekunden).
Wenn ich das nämlich richtig sehe ist das CSMA/CD verfahren so aufgebaut das eben ein Timeout
erzeugt wird. Wenn nun der Bus also zu stark ausgelastet ist (zu viele Zugriffe o.ä) könnte der
Hub also überlastet sein - was dann in das H1 Netz einstreut & eben das Netz lahmlegt.
Weil das Kollsionspaket ja auf niederer Ebene als Broadcast auf alle Ports durchstrahlt.
Nur das ist eben bloß eine Vermutung. Kann im Live Betrieb schlecht testen face-sad

Falls wer ne Idee hat oder die Theorie bestätigen könnte - wäre ich happy. Darüber kriegt man nämlich
kaum noch Infos außer: "Sowas gibt´s nicht mehr oder wenn dann im Museum..."
War schon tot als ich meine Ausbildung anno 2000 angefangen habe.

Danke im Voraus.

Content-Key: 328567

Url: https://administrator.de/contentid/328567

Ausgedruckt am: 28.03.2024 um 14:03 Uhr

Mitglied: emeriks
emeriks 06.02.2017 um 09:23:49 Uhr
Goto Top
Hi,
schau mal hier, bei einer spontanen Suche gefunden:
yellow cable collision detection

Dort steht jetzt zwar nicht die Welt erklärt, aber es hat doch meine Erinnerung bestätigt:
In den alten Ethernet-Medien (Coax) sind Kollisionen by design im Programm.

E.
Mitglied: chgorges
chgorges 06.02.2017 aktualisiert um 09:44:27 Uhr
Goto Top
Zitat von @TechnoX:

Guten Morgen und vorweg ja wir haben sowas noch im Einsatz.
Der dann an einen Auto Sensing fähigen 10/100Mbit
Switch angeschlossen wird/wurde.

Vorsicht, einen Auto-MDIX-fähigen 100MBit/s Switch gab es zur damaligen Zeit sicher noch nicht face-smile
Die Hubs/Switche hatten immer einen dedizierten Uplink-Port, der mechanisch und nicht dynamisch gedreht ist, damit man ein normales Patchkabel zum Verbinden von mehreren Switchen/Hubs nehmen konnte.
Andernfalls muss ein (gutes), altes Crossover-Kabel her, damit man die Geräte miteinander verbinden kann.
Auch sollte man die Auto-Switche auf den Ports fest auf 10MBit/s einstellen, wenn man weiß, dass die Geräte daran nur 10MBit/s können.
Mitglied: chiefteddy
chiefteddy 06.02.2017 aktualisiert um 10:40:14 Uhr
Goto Top
Hallo,

ein Paar Infos zur Klarstellung:

Thick Ethernet ist der "Handelsname" für einen Ethernet-Verkabelungs-Standard (10Base5) mit einer Übertragungsgeschwindigkeit von 10 Mbit und einer max. Segmentlänge von 500m. https://de.wikipedia.org/wiki/10BASE5

Siemens Sinec H1 ist ein Feldbus-Protokoll der Firma Siemens zur Vernetzung von (SPS-) Steuerungen. Der "Vorläufer" von Profinet. Dieser Feldbus nutzt als Topologie den Bus mit 10Base5 Thick Ethernet - auch als "Yellow Cable" bekannt (doppelt geschirmtes Coax-Kabel 50 Ohm, Knotenanschluß über AUI-Kabel).

Sinec H1 ist protokolltechnisch nicht gleich ("Büro-") Ethernet!

Kollisionen sind in einem Hub-basierten Ethernet prinzipbedingt. Das ist die Grundlage des Zugriffsverfahrens CSMA/CD ( https://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_De ... ) bei Ethernet. Damit ist Ethernet ein nichtdeterministisches Übertragungsverfahren. Dh., man kann nicht vorherseagen, wann ein Datenpaket übertragen wird. Damit "disqualifiziert" sich das ("Büro"- ) Ethernet für zeitkritische Anwendungen. Um dieses Problem zu lösen, wurden spezielle (Feldbus-)Protokolle auf Basis von Ethernet entwickelt. Eines der ersten war Sinec H1. Heute gibt es unter dem Oberbegriff "Industrial Ethernet" eine ganze Reihe. ZB. ProfiNet, EtherNet/IP, Ethernet Powerlink oder EtherCAT ( https://de.wikipedia.org/wiki/Industrial_Ethernet ).

Prinzipbedingt kann ein Hub-basiertes Ethernet nur zu 20-30% ausgelastet werden (liegt am CSMA/CD-Zugriffsverfahren). Ist die Auslastung größer kommt es zwangsläufig zu Paketverlusten. Die einzige Lösung ist die Verkleinerung der Kollisionsdomänen durch Segmentierung des Netzes.

Jürgen

PS Und natürlich beherrscht 10Base5 keine Autonegotation zur Aushandlung von Übertragungsgeschwindigkeit und kein Auto-MIDI für gekreuzte oder nicht-gekreuzte Ports. Es muß alles fest (von Hand) eingestellt sein.
Und in einem Hub-basiertem Netz gibt es nur eine Übertragungsgeschwindigkeit! Bei einem H1-Bus also 10Mbit. Die Kopplung mit dem "restlichen" Netz muß über einen Switch erfolgen.

PPS: Steuerungs-Kommunikation und Datei-Transfer in einem 10Base5-Netz ohne Switching ist ein "no go"!! --> Paketverluste
Mitglied: brammer
brammer 06.02.2017 um 10:56:53 Uhr
Goto Top
Hallo,

das die Technik nicht mehr produktiv eingesetzt werden sollte weißt du ja selber....
Aber schön zu lesen das es noch im Einsatz ist....

Stell den Switch auf 10 MBit/s Halfduplex und schau ob es geht, evtl sogar 10 Full.

Das 15 Polige Kabel ist auf was für einen Stecker terminiert? RJ45 ?
oder D-Sub? und vom HUB auf Netzwerk? Coax oder RJ45?

Wenn durch einen Copy Job im selben NETZ die Last zu hoch steigt solltest und das Netz in VLAN's teilen und den Traffic in dem betreffenden Netz mit QoS priorisieren oder wenn möglich komplett physikalisch trennen....

brammer
Mitglied: chiefteddy
chiefteddy 06.02.2017 aktualisiert um 11:49:14 Uhr
Goto Top
Hallo @brammer,

Stell den Switch auf 10 MBit/s Halfduplex und schau ob es geht, evtl sogar 10 Full.

10Base5 arbeitet nur mit Halb-Duplex.

Das 15 Polige Kabel ist auf was für einen Stecker terminiert? RJ45 ?
oder D-Sub? und vom HUB auf Netzwerk? Coax oder RJ45?

Das Endgerät ist bei 10Base5 immer über ein 15-poliges AUI-Kabel an den Tansceiver (D-Sub) angeschlossen. Der ist - wie @TechnoX richtig beschreibt - über eine "Vampir-Klemme" mit dem Yellow-Cable verbunden.

Um ein 10Base5-Segment mit einem anderen Segment zu verbinden, braucht man immer einen Repeater, der auf der einen Seite einen AUI-Anschluß hat und auf der anderen Seite zB. einen RJ45-Anschluß. Früher hatten die Ethernet-HUBs (laut OSI-Modell Repeater) oft neben den RJ45-Ports auch noch einen BNC- (Thin Ethernet 10Base2 ) und/oder einen AUI-Anschluß als Uplink-Port.

Jürgen


connection_a_station_to_a_10base5_ethernet_system

thicknettransceiver

allied-telesis-mr820tr-10base2-aui-backbone-port-w-10-base-t-ports-2.17


PS. VLANs gibt es bei 10BaseX- Netzen nicht. Dazu braucht man einen Switch und dann hat man auch kein CSMA/CD mehr und auch keine Kollisionen.
Mitglied: TechnoX
TechnoX 06.02.2017 um 11:50:41 Uhr
Goto Top
Das Testszenario war exemplarisch nicht exakt gleich. Der Switch im Echtbetrieb ist ein Simpler 10/100Mbit Switch. Hier die Signal Kette:

Lan > Switch (unmanged) 10/100Mbit > Rj45 (ob X unklar..) auf Rj45 Hub (MDI Port) 10Mbit (Blackbox Stackable Minihub Port 8) > AUI 15 Pin DSub zu Tranciver/Repeater DSub 15 Pin > H1 Bus Yellowcable (Coax).

Der Bus besteht aus 6 Tranciever / Repeatern. Die alle über das Yellow Cable gesteckt/geklemmt sind.

An dem Switch hängen 2 ComCerver über Rj45. Der eine wird am Switch mit 100Mbit gefahren (neuer) der andere auf 10Mbit (älter). Die ComServer
sind dann mit der Gasse und dem LVR System direkt verbunden über 15pin DSUB.

Der Tranciever/Repeater an dem (linken) Ende empfängt die Daten des H1 Bus, leitet es an einen Steuerungs PC weiter. Dies passiert
über einen Minihub der von 15pol DSub auf Rj45 Adaptiert. Außerdem hängt an dem Tranciever / Repeater ein weiterer ComServer dran.
Jeder der Comserver ist über eine Verbindung direkt mit einem LVR System verbunden, das die Auslagerungsaufträge aus unserem System
verwaltet. (Serverraum)

Der Leitstand ist das rechte Ende. An ihm ist eine Steuereinheit angeschlossen welche die 3 Steuerungs PCs speist. Diese Verbindung ist über Coax zu 15pin DSub (Multi I/O) realisiert. Und geht auf eine eigene Steckkarte. Ein Remote Steuerungsaccess ist über einen PC mit Com Port realisiert. Dieser ist über RJ45 auch ins Hausnetz verbunden.

An den anderen Trancievern Repeatern hängen DSub Verbindungen zu Gassen oder Steuerungs PC mit direkt Anbindung.
Ob an dem linken Ende ein Terminator hängt (ich gehe davon aus) weis ich nicht. Sollte eigentlich.. *grübel*

Ausserdem ist an dem 10/100Mbit Switch ein PC angeschlossen der als Gegenstück zu dem Remote System im Leitstand dient.
Hauptsächlich geht es darum die doch beträchtliche Laufstrecke zu überbrücken. Um die Gassen nach der Störungsbeseitigung
schneller freigeben zu können. Ein Test (PC aus) zeigte aber das es keine Rolle spielt ob der PC an ist oder nicht da dieser
über LAN ins Firmen Netz geht und von dort auf den PC (schnellere Verbindung). Der Switch hat damit auch kein Problem.

Der Test mit dem COPY Job war ausschließlich in der Testumgebung durchgeführt worden. Und brachte mich auf die Vermutung
mit dem CSMA/CD - da der hub im Testszenario eine Lastanzeige besitzt welche der Hub im echt Betrieb nicht besitzt. (würde
den die Woche mal ersetzen um zu sehen wie viel Last wirklich existiert)
Mitglied: GrueneSosseMitSpeck
GrueneSosseMitSpeck 06.02.2017 um 12:14:12 Uhr
Goto Top
ja das gute alte Thick Ethernet... danke für die schönen Bildchen face-smile

CDMA heißt Collision detect Multiple Access. Man versucht das Medium zu belegen und stellt dabei fest ob eine Kollision vorliegt oder nicht. Also ob ein Multiple Access vorlag.

Wenn eine Kollision vorliegt sollten beide Sender eine zufallsgesteuerte Wartezeit einlegen, und dann erneut senden. Grundlagen des "Alohanet", so auch vorhanden in allen Koax-Netzwerken. Ich meine die höchste effektive Datentransferrate lag da so bei ca. 30% der verfügbaren Bandbreite mit dem Standardalgorihmus - wenn alles in Ordnung war. Das sind 300 KB/Sekunde.

Ich hab in der Coax-Zeit Netze administriert, und es kam leider immer wieder vor, daß ein Transceiver defekt war und ständig Kollisionen verrusacht hat. Sehr zum Leidwesen der anderen Anwender...
Mitglied: chiefteddy
chiefteddy 06.02.2017 aktualisiert um 13:49:25 Uhr
Goto Top
Hallo @TechnoX,

eine Zeichnung sagt mehr als tausend Worte.

Was aus Deinen "tausend" Worten aber immer noch nicht hervor geht, ist, ob Ihr das Sinec H1-Protokoll zwischen den Steuerungen im Hochregallager nutzt oder ob Ihr "nur" 10Base5 als Ethernet-Verkabelung einsetzt.

Und noch einmal: der Transceiver ist ein Transceiver und kein Repeater. Ein Repeater arbeiter auf Schicht 1 des OSI-Modells und ein HUB ist ein Multiport-Repeater.

die-mii-schnittstelle-von-fast-ethernet

Das Bild zeigt den Aufbau einer Ethernet-Schnittstelle im OSI-Modell. Die AUI-Schnittstelle entspricht dem MII.

https://de.wikipedia.org/wiki/Media_Independent_Interface

https://de.wikipedia.org/wiki/Attachment_Unit_Interface

https://de.wikipedia.org/wiki/Medium_Dependent_Interface

Das Ethernet-Segment, auf dem die Steuerungen miteinander kommunizieren sollte als eigenständige Kollisionsdomäne gestaltet werden und keinen anderen Datenverkehr transportieren.Prinzipbedingt kommt es bei 10BaseX-Ethernet immer zu Kollisionen und bei einer Auslastung >= 20-30% zu Paketverlusten. Bei Zeitkritischer Kommunikation muß man den Datenverkehr soweit reduzieren, das es zu keinen bzw sehr wenigen Kollisionen kommt. Wenn die Kollisions-LED permanent leuchtet ist das Segment einfach Überlastet und die Steuerungen können in dem vorgegebenen Zeitfenster keine Informationen austauschen, weil sie keinen Zugriff auf das Medium erhalten (CSMA/CD). Natürlich kann auch eine Komponente (Netzwerkinterface) defekt sein. Das bekommt man aber durch einfaches Austauschen heraus.


Jürgen
Mitglied: mathu
mathu 02.03.2017 um 10:12:32 Uhr
Goto Top
Zitat von @GrueneSosseMitSpeck:

ja das gute alte Thick Ethernet... danke für die schönen Bildchen face-smile

CDMA heißt Collision detect Multiple Access. Man versucht das Medium zu belegen und stellt dabei fest ob eine Kollision vorliegt oder nicht. Also ob ein Multiple Access vorlag.

Yuup, ala "trial and error", frei nach dem Motto, ich sende jetzt einfach mal mein Paket, wenn knallt, probier ich noch mal usw....
Aber so war das damalige Design leider.

face-wink
Mitglied: TechnoX
TechnoX 02.03.2017 um 10:33:23 Uhr
Goto Top
Nach einigen Try and Error kann ich sagen, das es etwas gebracht hat einen der äußeren Steuerungs PCs auf eine Separate Lan Leitung zu klemmen. Hat den Bus letzten Endes doch etwas belastet. Was in dem Fall Gott sei dank möglich war. Leider ist es nach wie vor so, das die Techniker UNBEDINGT ihren Remote zugriff aus dem Lan haben wollen weil sie sonst mehr laufen müssen... ohne den könnte man das ganze Yellow Cable vom Lan trennen. So aber und das habe ich auch klar gesagt - ist es nicht ratsam die Remote Verbindung so wie es aktuell ist laufen
zu lassen. (Geht vom LanSw, in den Hub von dort in das Yellowcable H1 Bus System und daran hängt dann der PC auf den sie aus dem Lan aus zugreifen. Ungut aber die Herren wollen also kriegen sie müssen halt dann damit leben wie es is.)

Es gibt zwar noch Kollisionen, diese sind aber "im Rahmen". Soll heißen die Hochregal Rechner laufen tatsächlich etwas flüssiger.

Für mich ist das Thema gegessen. Ich kann nicht mehr tun als das was ich getan habe. Der Nächste Schritt ist der Heiß ersehnte Umstieg auf Lan & das ist bereits beauftragt. (NA ENDLICH) Dauert aber noch seine Zeit. Da kommt noch was auf mich zu, aber bis dahin is das Thema erstmal erledigt face-smile