interne Kommunikation zw. 50 u. 100 Baud Maschine

[FredSonnenrein]

Wir bräuchten hier entweder eine zuverlässige automatische Symbolratenerkennung (m.E. schwierig, das schnell genug hinzubekommen), oder eine intelligente Auswertung, die die Symbolratenumschaltung erkennt (per Konvention) und dann die Logik umschaltet. Neuland ...

Das ist alles viel zu viel Aufwand für einen begrenzen Nutzen. Der Standard sollte bei 50 Baud bleiben, wer will kann ja höhere Geschwindigkeiten verwenden, er sollte sich aber (insbesondere bei mechanischen Maschinen!) der Konsequenzen bewusst sein.
Außerdem wird die Störanfälligkeit bei solchen Algorithmen zur automatischen Geschwindigkeitserkennung deutlich erhöht.

[Fernschreiber]

Hallo Björn und alle Anderen,
ja, Du hast es auf den Punkt gebracht.
Hier ein paar Grundlagen:
Die alte analoge(TF-Technik) und digitale(64Kb/s;PCM 2-140Mb/s) Ü-Technik war damals noch quasi Echtzeit, da nirgendwo zwischengespeichert oder korrigiert wurde, es waren am Ende die Rohdaten vom Anfang.Die Bitfehlerrate durfte niergends > 10 Exp -6 liegen. Lediglich die physikalischen Laufzeiten traten auf, waren aber interkontinental sehr gering, lediglich bei Satelitenverbindungen traten statische Verzögerungen auf. Als dann die ersten ATM-Systeme ins Spiel kamen traten plötzlich zusätzliche bemerkbare Verzögerungen auf, begründet durch das Sammeln und Verpacken bzw. Adressieren der Pakete (Ähnlich IP). Aber auch Diese waren statischer Natur, da die Wege über feste Grundleitungen führten und kein spontanes Wegehopping vorgesehen war, lediglich bei Ausfällen konnte die Wegeführung durch die Adressen einen anderen Verlauf nehmen.
Die in diesem Punkt leidige IP-Technik beschert uns nun einen anderen Ansatz. Wird ein solches Paket auf die Reise geschickt, ist theoretisch jeder zur Verfügung stehende Ü-Weg möglich, egal wie lang der in Km/ Zeit ist. Natürlich ist das in der Praxis nicht so, denn es hängt von der Topologie des Netzes jedes Providers ab und dort von der Integration der Router, was Diese so zulassen. Jeder Router ist ein weiterer Verzögerungspunkt in der Kette und sorgt für unterschiedliche Laufzeit. Daher ist das Bestreben der Provider, möglichst wenige Routingpoints gerade in Multimedianetzten zu platzieren, dafür den "Content" u.U. mehrfach regional vorhalten zu müssen. Auch hier wird die Physik nicht ausgehebelt. Kein Provider wird im Normalfall ein paketweises Routenhopping zwischen Seekabel- und Satelitenverbindung zulassen. Da diese IP-Verbindungen nach wie vor auf abschnitsbezogenen Grundleitungen (Faser oder Funk) basieren, kann man das sehr gut steuern. "Leider" werden die Übertragungsgeschwindigkeiten immer höher, sodaß trotzdem IP-Pakete selbst in nationalen Netz in unterschiedlicher Reihenfolge beim Emofänger eintreffen können. Das simple IP-Paket ist dann nur noch bedingt zu gebrauchen (bei UDP wird meist aus Zeitgründen verworfen). Die bei i-Telex benutzte Betriebsart TCP hat dagegen einen Sicherungsmechanismus integriert der sicher stellt das die Pakete in der richtigen Reihenfolge und möglichst vollständig an den nächsten Layer übergeben werden. Das heißt:
für jedes TCP-Paket (unabhängig der Länge der Payload) ein 3-Wege Handshake, dauert auch dreimal so lange; erst dann geht das nächste Paket beim Sender raus. bei trotzdem fehlender Paketnummer in der laufenden Sequenz erfolgt Nachforderung des vermissten Pakets. Trifft Dieses zwischenzeitlich ein, muß das danachkommende Doppel aussortiert werden. Die durch das Abwarten und Bearbeiten entstehenden Zeiten sind für Echtzeit nicht akzeptierbar, für Datentransfer (z.B. Updates) aber Grundvoraussetzung. Die Applikationslayer setzten dann gerade bei Dateiübertragungen noch weitere Maßnahmen ein (z.B. merken des Übertragungsstatus, um bei Abbruch und zweitem Versuch dort wieder ansetzen zu können. Sonst wäre ein 1GB grosses Kartenupdate für`s NAVi fast unmöglich.
Was heist das nun für i-Telex:
Die IP-Übertragung ist meilenweit schneller wie unsere Maschienen selbst im Lochstreifenbetrieb. Selbst der langsamste DSL-Anschluß hat im Upload dafür Reserven. Eine routingbedingte Umwegverzögerung bis zu 150 ms ist im Normalzustand extrem unwahrscheinlich.
Bei einer Zeichendauer von 150ms(50Baud)bzw. 75ms(100Baud) kann man sich eigentlich alle Zeit der Welt (bezogen auf Prozessorgeschwindigkeit) nehmen und jedes Zeichen in ein eigenes TCP-Paket stecken (meine Realisierung macht das nicht ohne Grund so. 50/100Baud auch bei IP).
Hier muß aber zwischen der Baud- und Symbolrate unterschieden werden. Während die Baudrate den technischen Bezug darstellt ( 20ms/Bit; 150ms/Zeichen) ist die Symbolrate vom Benutzer abhängig. Die Symbolrate ist aber durch die Baudrate begrenzt. Da durch das Medium IP die Baudrate eliminiert wird, ist nur noch die Symbolrate relevant und erkennbar. Aus Dieser im Empfänger nun auf die Baudrate zu schliessen ist äußerst kompliziert und kann eigentlich nur über längere Zeitintegration geschehen.
Sind da nun nur "Ein" oder mehrere Baudotdaten (logisch bis zu 254, Fred hat aber mal eine Grenze genannt, um der Empfangspuffer zu schonen ) vorhanden, wird es schwierig. Die mittlere Symbolrate muß um den Empfangspuffer nicht zu überlaufen bei 50 Baud ca 6,6 bzw. 100 Baud 13,2 betragen, egal wie es sporadisch gelöst wird. Werden z.B. 10 Baudotwerte zusammengafasst, darf das nächste Paket erst in 10X150 = 1500 ms gesendet werden, alle Kombinationen dazwischen möglich. Um an dieser Stelle keine "komplizierten" Berechnungen (wie in i-Telex) zu machen, schicke ich alles einzeln und der Empfänger kann bei Bedarf die max. Symbolrate errechnen.
Diese Betrachtung bezieht sich aber auf den Worstcase, also Dauerfeuer mittels guten Schreiber oder Lochstreifen. Ein "Normaluser" wird wohl eher die langsamere ungeübte Shreibweise bevorzugen.
Die Vorgeschlegene Symbolratenumschaltung von Björn ist da wie er ja selbst schreibt ziemlich schwierig zu lösen, wenn sie nur auf Grund der eimlaufenden Baudot-Pakete /Zeiteinheit basiert. Ein vernünftiges Ergebnis kann nur bei längerer Zeitintegration bei gleichbleibender Symbolrate ( nicht Baudrate) geschehen. Jede Unregelmäßigkeit (Pause) zieht das Ergebnis nach unten und man kann höchstens die Peakwerte nehmen. Eine adaptive Zwischenlösung wie bei der Flusskontrolle kann es ja nicht sein , da hier die Entscheidung am Empfänger wie auch Sender auf feste Baudraten fallen muß.
Im digitalen Mobilfunk gibt es in allen Frames sogenannte Trainingssequenzen, die ermöglichen das sich Endgeräte immer zu jeder Zeit auf die Basisstation synchronisieren können und keinen funktechnischen "Unsinn " machen können. Vielleicht wäre das Prinzip bei der Versionsaushandlung bzw. Erstkontakt mit dem Port(Maschine) ein Ansatz. bedingt aber neue Software für die Nutzer.
Die neueren bestehenden i-Telex Systeme haben als Synchronisation zwecks Flußkontrolle/ Baudrate eigentlich nur die Möglichkeit, über die (nicht mandatory) Ackpakete (Nr 06) rauszukriegen, was am anderen Ende passiert. wie schwierig das war habe ich ja bei der Serverentwicklung in Verbindung mit den Pi-Lösungen erfahren. Auch das evt. Senden von Datum/Zeit kann in einem TCP-Paket sein und gibt keine Hinweis auf Synbolrate.
Es wird evt. auf der pi-Seite eine mögliche empfangsseitige Lösung geben, wie kommt das Ergebnis dann aber zurück zum Anrufer?
Wir kommen an einen Punkt, an dem entweder das I-Telex Communication Protocol einer Erweiterung und damit evt. einer höheren Version bedarf oder wir lassen die I-Telex Verbindungen reinrassig, d.h. nur 50/75/ oder 100 Baud Verbindungen sind möglich. Kann man auf dem Teinehmerserver kenntlich machen und damit in der Auskunft 118811 auch. Im Telexbuch kann auch ein Hinweis gedruckt werden. Alles andere Bedarf Aufwand bezüglich Updates mit neuer Software. Nicht umsonst gab es eben diese baudotverschiedenen Verbindungen in Echtzeit früher nicht.

Gruß
Willi