[DDL-ML] Re: [DDL-ML] rufo, loconet, rückmeldebus, bushardware, ddl-treffen

["Andy" <Andy_P@gmx.de>]

Hi Torsten,

>
> Meines Wissens nach ist *gerade* bei Open-Collector-Bussen die mangelnde
> Störsicherheit ein nicht zu unterschätzender Nachteil, auch wenn es sich
> vom Protokoll-Handling und Hardware her einfacher zu handeln ist. RS485
> ist aufgrund seiner symmetrischen Leitungen nicht nur extrem störsicher,
> sondern auch noch schnell. In Industrieanwendungen wird mit
> RS485-Hardware Datenübertragung bis in den MBit-Bereich und mit -zig
> Teilnehmern betrieben. (z.B. Profibus). Das sollte wohl genügen.

Loconet ist auf Störsicherheit bei primitivster Verkabelung designed. Wer
andere Erfahrungen hat, möge diese mitteilen.


> CSMA/CD kann ich bei jeder Bus-Datenübertragung einsetzen (egal ob
> Loconet oder SNAP), im einfachsten Fall durch gleichzeitiges Rücklesen
> der gesendete Informationen (bei SNAP: SYNC-Pakete). Sind diese
> verstümmelt, so ist eine Kollision vorhanden.

Prima. Leider weder bisher weder definiert noch implementiert, laut Doku
kein Bestandteil von SNAP. Anscheinend wird meistens Master/Slave
gearbeitet?

> Ich glaube mich auch erinnern zu können, das für CSMA-CD bei 50% der
> physikalisch möglichen Bandbreite die maximale Übertragungskapazität
> erreicht ist.
Nein, erst bei 100 % (nicht mehr :-). Die 50 % sind ein Wert aus der Praxis
bei Ethernet und vielen Teilnehmern, da hört man auch was von 30 %. Digitrax
behauptet, daß ihr Arbitrierungsverfahren in der Regel besser ist (98% bei
1% Kollisionen). Wobei 50 % bei 8-Byte Paketen immer noch 100 Pakete/s sind.

> drauf ankommen lassen, und der gegenüber Loconet höhere
> Protokolloverhead (ca. 100 %) und geringere Geschwindigkeit lassen
> sich verschmerzen.
Wir reden etwa über Faktor drei. 35Pakete/s kann reichen, oder einen
weiteren Bus erforderlich machen. Loconet ist nicht nur für Feedback
gedacht, sondern auch für Handregler, und da kann es schon mal mehr Verkehr
geben.


> Das Thema Protokoll-Overhead ist immer im Zusammenhang mit der möglichen
> Paketgröße zu sehen. Und die kann ich bei SNAP ja in weiten Bereichen
> einstellen.
Das typische Paket wird wenige Daten Nettoinhalt haben.


> Wenn auf eine Arbitrierung ohne Informationsverlust besonderer Wert
> gelegt wird, dann wäre wahrscheinlich ein Prinzip wie CAN, wo sich die
> höher priorisierte Adresse durchsetzt, die bessere Alternative. Da wird
> aber wieder der Kostenfaktor eine Rolle spielen, CAN-Microcontroller
> sind nicht gerade billig. Die Alternative wäre Software-Emulation.
> Ausserdem, wer legt dann die Prioritäten fest?
Einfach alles 3x rausschicken in der Hoffnung es kommt an ist nicht so
dolle. Es reicht vielleicht wirklich, wenn die Rückmeldung nach 100-200 ms
da ist, aber ankommen sollte sie unbedingt: Ein nicht besetzt gemeldetes
Gleis gilt als frei und damit besteht Kollisionsgefahr; eine
Zugablaufsteuerung die lückenhafte Rückmeldungen bekommt wird auch schnell
ins Trudeln kommen.

> Treiber sind für Linux und Windows vorhanden.
Mit CSMA/CD?!?
Nicht die Umsetzung eines definierten Protokolles ist das Problem, sondern
der Rest. Einfach derzeitiges SRCP auf SNAP drauf setzen erzeugt ein
unpraktikablen Durchsatz (geschätzt max. 10/s), und Hardware ist auch nicht
da. Es reicht nicht, das Stichwort RS-485 in die Luft zu werfen: wie sehen
die Kabel aus? Stecker? Terminierung? Arbitrierung? Signalpegel? Baudrate?
...


> Ausserdem, war da bei Loconet nicht irgendwas mit Lizenz-Fragen, die
> eine freie Verwendung untersagten bzw. die eigene Entwicklung stark
> einschränken ?

Und da war es wieder, das Totschlagargument "Loconet ist proprietär". Für
den Hobbybedarf  gibt's schon mal gar keine Probleme.
Im Übrigen habe ich den Verdacht daß einige "Mitreder" nicht mal die ersten
Seiten der Doku von Digitrax gelesen haben....

> Allerdings wurde auch von einem zeitkritischen Verhalten bei Loconet
> gesprochen. Wie sieht es denn mit der zusätzlichen Belastung de Rechners
> aus?
Zeitkritisch ist das Einbuchen eines Controllers in einen Slot. Unter Linux
zuverlässig nur direkt im Device Driver zu lösen, da eine geringe Latenz
erforderlich ist. Im Normalbetrieb ansonsten mit seriell zu vergleichen und
damit eher unproblematischer als erddcd.

>
> Fazit: Viele Fragen sind noch offen, jedoch würde ich vorsichtig mit
> pauschalen Urteilen wie "nicht zu gebrauchen" sein. Sicherlich ist die
> Entwicklung eines eigenen Protokolls mit mehr Arbeit verbunden, aber ich
> denke, es lohnt sich am Ende.
Na denn man zu. Aus dem Nichts eine stabile Protokollsuite zu entwickeln
halte ich für unrealistisch. Die Diskussion ist schon älter, irgendwelche
substantiierten Ansätze hat noch keiner vorgetragen. Man könnte ja erst mal
anfangen überhaupt die Anforderungen zu definieren. Dann trennt sich schnell
die Spreu vom Weizen.

Andreas