881199 klkl Server ITA

[detlef]

Jetzt ist gerade wieder durchgehend besetzt. Ist da soviel los auf dem Server?

[detlef]

Ich habe mir gerade noch mal den Datenverkehr zwischen WinTlx und KLKL-Server angeschaut.
So wie es aussieht, sendet der KLKL-Server keine Ack-Pakete. Dadurch stellt WinTlx irgendwann das Senden ein, weil es davon ausgeht, dass der Empfangspuffer der Gegenseite voll ist. i-Telex kommt damit offensichtlich klar. Vermutlich hat Fred eine Art Timeout eingebaut, für den Fall dass keine Ack-Packete kommen. Ich muss ihn mal fragen.

Ich habe jetzt in WinTlx auch so einen Mechanismus eingabaut, damit es nicht zu einem Deadlock kommt, wenn die Gegenstelle keine Ack-Pakete schickt oder wenn die Zeichen im Empfangspuffer der Gegenstelle nach einer paar Sekunden nicht weniger geworden sind. Heute Abend gibt es dann eine neue WinTlx-Version, die mit dem aktuellen KLKL-Server klar kommt.

Der Fehler, dass keine Ack-Pakete kommen, sollte aber im KLKL-Server behoben werden.

[FredSonnenrein]

Weil es hier besser aufgehoben ist als im anderen Thread:
Das Senden jedes einzelnen 5-Bit-Zeichens in einem eigenen TCP-Paket hat folgenden Nachteil:
Aufgrund der begrenzten Hardware des i-Telex kann dieses nur EIN in falscher Reihenfolge ankommendes TCP-Paket behandeln.
Somit kann es bei der vorhandenen Implementierung mit TCP-Pakten im Abstand von 0,15 Sekunden dazu führen, dass bei schlechter IP-Verbindung das i-Telex die Verbindung trennt, weil mehr als ein TCP-Paket in der falschen Reihenfolge eintraf (also beispielsweise 1-2-4-5-3-6-7).
Beim Testen auf DSL-Verbindungen innerhalb Deutschlands mag das nicht vorkommen.
Daher kann ich nur empfehlen, das Senden der Daten etwas effizienter zu machen.

[BanditDD]

Hallo,

es kommt bei der Wiedergabe zu Problemen, also keine flüssige Wiedergabe:

1. Bei welcher Liste trat das Problem auf
KLKL - sowohl über 881188 und auch 881199

2. Welche Art von FS wurde verwendet mechanisch/elektronisch
T100s - also mechanisch

Zudem sind die beiden Systeme sporadisch nicht erreichbar ('nc'). Dies haben auch andere im mChat bestätigt. Nachdem einer rückmeldete, dass es bei ihm geklappt hätte, war auch mein nächster Anwahlversuch erfolgreich. Heute morgen gegen 6:30 Uhr dann wieder 'nc'.

Gruß,
Thomas

Nachtrag: Verbindung um 7:15 erfolgreich, Laufgeräusch war diesmal wie man es von einem T100s kennt. Gibt es dafür eine Erklärung? Serverlast? Nur bei mehreren gleichzeitigen Verbindungen?

[FredSonnenrein]

Moin zusammen,
Solange der Server jedes Zeichen in einem eigenen TCP-Datenpaket sendet, wird jede minimale "Belastung" der Internet-Übertragungsstrecke zum "ruckeln" führen.
Viele Grüße,
Fred

[Fernschreiber]

Hier nochmal eine allgemeine Beschreibung zu den Punkten Ack und TCP:
Das System sendet aus historischer Sichtweise (Communication Protokoll 2016/17) zur Erhaltung der Verbindung Heartbeats. Das ist auch auch jetzt noch erlaubt. Ein Ack als wirkliches Ack macht nur Sinn wenn sich der Wert ändert. Da bei runterladen der Listen vom FS keine Zeichen zum Server geschickt werden, kommen auch keine Acks zwischendurch vor. Bei der Menueauswahl kommen daher sehrwohl Acks, (sogar für jedes Zeichen einzeln) daher ist die Aussage von Detlef nicht ganz zutreffend. Acks sind übrigens weiterhin eine Empfehlung, kein Muß.
Zu der Einzelpaketverschickung: Ein TCP-Paket Inkl. 3-Wegehandshake ist in wesentlich weniger als 150ms durch das WAN Netz. Ein normaler Socket (eingebettet im OS wie in Windows oder Linux) hat dann auch locker die Reihenfolge sortiert. Wenn Fred wie beschrieben eingeschränkte Ressourcen hat (muss sich u.a. selber um die Reihenfolge kümmern) ist das natürlich eine ganz andere Baustelle als wie die prinzipiell extrem jitterbehaftete TCP-Übertragung ohnehin schon. Solche kritischen Werte sollten zusammen mit anderen systemtypischen Werten mal auf ein technisches Beiblatt zum i-Telex geschrieben werden (gilt auch für andere Entwicklungen wie mit Windows, Arduino, Pi und Co). Es sind aber nach der Testphase (Justage der Flusskontrolle) damals keine grösseren Probleme mehr aufgetaucht, obwohl gerade die Baudoart-Phase heftig genutzt wurde. Aus meiner persönlichen Erfahrung kann aber auch jedes " Bottleneck " im Heimnetz (WLan bzw. sporadische Last oder Drucker oder....) selbst bei Nutzung von Pi-Systemen zu Unregelmässigkeiten bei Dauerempfang führen.
Da das Ressourcenproblem im i-Telex nun zumindest auch mir bekannt ist, werde ich mir Gedanken machen, inwieweit die Versendung dieser grossen Datenmengen auf den Servern (und nur da) etwas effektiver (einstellbar im Zuge der Flusssteuerung) gestaltet werden kann. In diesem Fall gibt es in der Spec. ja Grenzen zur Paketierung der der 02er Pakete. Die mittlere Zeichenrate auf der IP-Strecke bleibt aber bei 50 Baud.
Zu der Erreichbarkeit kann ich leider keine definierten Aussagen machen. Mein Stand ist aber, das von den 2 mal 3 Servern ein Standort mangels Nachfrage gekündigt wurde. Somit stehen noch 3 Server bereit, von denen jeder alle Dienste anbieten kann. Wenn das plötzlich nicht mehr reicht, kann Thomas das schnell hochskalieren.
Wer wissen will wie das System arbeitet: https://telexforum.de/viewtopic.php?f=29&t=2278
Gruß
Willi

[FredSonnenrein]

Hallo Willi und alle anderen:

Hier nochmal eine allgemeine Beschreibung zu den Punkten Ack und TCP:
Das System sendet aus historischer Sichtweise (Communication Protokoll 2016/17) zur Erhaltung der Verbindung Heartbeats. Das ist auch auch jetzt noch erlaubt. Ein Ack als wirkliches Ack macht nur Sinn wenn sich der Wert ändert.

Alles richtig.

Da bei runterladen der Listen vom FS keine Zeichen zum Server geschickt werden, kommen auch keine Acks zwischendurch vor.

Auch richtig, die Frage ist aber, was der Server mit empfangenen Ack-Paketen macht.

Bei der Menueauswahl kommen daher sehrwohl Acks, (sogar für jedes Zeichen einzeln) daher ist die Aussage von Detlef nicht ganz zutreffend. Acks sind übrigens weiterhin eine Empfehlung, kein Muß.

Auch richtig, die Ack helfen aber beim Anpassen der Sendegeschwindigkeit und vermeiden so ein "Stottern".

Zu der Einzelpaketverschickung: Ein TCP-Paket Inkl. 3-Wegehandshake ist in wesentlich weniger als 150ms durch das WAN Netz. Ein normaler Socket (eingebettet im OS wie in Windows oder Linux) hat dann auch locker die Reihenfolge sortiert.

Auch richtig, allerdings ist die Gleichförmigkeit der Verzögerung nicht gewährleistet. D.h. wenn die Pakete im 150ms Takt gesendet werden kommen sie noch lange nicht im 150 ms Takt an. Und diese Ungleichmäßigkeit hört man dann...

Wenn Fred wie beschrieben eingeschränkte Ressourcen hat (muss sich u.a. selber um die Reihenfolge kümmern) ist das natürlich eine ganz andere Baustelle als wie die prinzipiell extrem jitterbehaftete TCP-Übertragung ohnehin schon.

Meine Applikation sortiert nicht selbst. Ich glaube das "Betriebssystem" des i-Telex verwirft Pakete die in falscher Reihenfolge kommen. Das muss ich aber nochmal verifizieren.

Solche kritischen Werte sollten zusammen mit anderen systemtypischen Werten mal auf ein technisches Beiblatt zum i-Telex geschrieben werden (gilt auch für andere Entwicklungen wie mit Windows, Arduino, Pi und Co).

Die Frage ist, was ein Entwickler eines Fremdsystems mit der Information dann macht... Wenn es für das Bearbeiten des Protokolls wichtig ist, dann muss das auch in die Spec.

Es sind aber nach der Testphase (Justage der Flusskontrolle) damals keine grösseren Probleme mehr aufgetaucht, obwohl gerade die Baudoart-Phase heftig genutzt wurde. Aus meiner persönlichen Erfahrung kann aber auch jedes " Bottleneck " im Heimnetz (WLan bzw. sporadische Last oder Drucker oder....) selbst bei Nutzung von Pi-Systemen zu Unregelmässigkeiten bei Dauerempfang führen.

Genau, und das kann man ausgleichen, indem zu Beginn ein "Vorrat" an Druckdaten gesendet wird und danach entsprechen der Ack-Meldungen weitere Daten nachgeschoben werden.

Da das Ressourcenproblem im i-Telex nun zumindest auch mir bekannt ist, werde ich mir Gedanken machen, inwieweit die Versendung dieser grossen Datenmengen auf den Servern (und nur da) etwas effektiver (einstellbar im Zuge der Flusssteuerung) gestaltet werden kann. In diesem Fall gibt es in der Spec. ja Grenzen zur Paketierung der der 02er Pakete.

Richtig.

Die mittlere Zeichenrate auf der IP-Strecke bleibt aber bei 50 Baud.

Warum?

Wer wissen will wie das System arbeitet: https://telexforum.de/viewtopic.php?f=29&t=2278

Danke für die Informationen!

Viele Grüße,

Fred

[Fernschreiber]

Hallo Fred und alle anderen die es betrifft oder interessiert,

im Prinzip sind wir uns ja mal wieder einig, aber hier ein paar Antworten auf die neuerlichen Fragen.
Was macht der Server mit den Ackpaketen?
Natürlich lesen und berechnen wieviel unbearbeitete Pakete in der Gegenstelle im Puffer liegen und entsprechend anpassbarer Parameter moderat abbremst auf < 50 Baud. Wird die Differenz kleiner, wird wieder beschleunigt (u.U. >50 Baud) bis ein minimaler Pufferwert(derzeit 16 Zeichen) erreicht ist (max 254 nach Spec).
Diese Parameter haben Thomas und ich damals durch die vielen Tests eingestellt. Es ist im Gegensatz zu Deiner im WiKi beschriebenen Quasi Start/Stop Lösung (völlig in Ordnung) eine etwas analogere weiche Steuerung, die umso besser wird je öfter Acks kommen.


Das die Pakete nicht in der Gleichförmigkeit ankommen wie gesendet meinte ich ja mir dem Begriff Jitter, daher ist etwas Puffervorrat unbedingt nötig. Über Puffergrössen haben wir schonmal reichlich diskutiert.

Das sortieren von TCP-Paketen braucht natürlich zusätzlichen Speicher und auch Zeit. Wenn hier viele kleinere Pakete zwischengelagert werden, kann man sehr gut sortieren und grössere Unzulänglichkeiten der Übertragung korrigieren. Kann man im selben Speicher aber nur 1-2 grössere mit max. 50 Zeichen (laut Spec. ich habe aber schon kleinere Werte von Dir gelesen) lagern, nimmt die Sortiermöglichkeit mit steigender Effizienz der Übertragung ab.
Ein verwerfen von gesichert mühsam durch 's Netz gesendeten TCP-Daten am Ende aus Ressourcenmangel kann eigentlich nur wie Du schon beschrieben hast zum Auslösen führen.


Die Baudrate von im Mittel 50 Baud (egal ob Start/Stop oder analoger Modus) auch im IP/ TCP-Verkehr ergibt sich durch den Feedback der Acks zu 50 oder u.U. 75 Baud ganz automatisch, lediglich die Auslenkung vom Sollwert fällt bei der Start/Stop Methode kurzzeitig grösser, bei der analogen moderater aber ständig auf. Beide haben ja den Zweck, das Sender und Empfänger bestmöglich im zeitlichen Gleichlauf bleiben. Da am Ende nur mit 50/75 Baud gedruckt werden kann hat es keinen Sinn die Daten wesentlich schneller in den (unbekannten) Empfangspuffer zu schieben. Dieser Gleichlauf ergibt sich bei manuellem oder kurzen Lochstreifen fast von selbst, da hier Personen vor den FS sitzen.
Das Problem bei den Servern sind die extrem langen Verbindungszeiten zum Übertragen der Listen. Wir reden hier von bis zu 40 Minuten/ca 13000 Zeichen beim Kölner Dom. Soll danach noch ein sinnvoller weiterer Menüpunkt auswählbar sein, ist absoluter Gleichlauf zwingend. Alternativ könnte man natürlich die gewählte Datei bei entsprechenden Puffern in wenigen Sekunden übertragen und die Verbindung beenden, der Server stünde sofort wieder zur Verfügung für den nächsten Anruf. Der "Downloader" hat dann ja erstmal 40 Minuten Getöse um die Ohren. Diese Vision scheitert aber an den Puffern und der derzeitigen SW. Werden keine Acks vom Server empfangen, ist stumpf mit 50 Baud zu senden, egal wie der Ausdruck klingt. Eine Alternative wäre die absolute Schnellübertragung und serverseitiges verfolgen der hoffentlich gesendeten Acks. Was wäre dann gewonnen, im Gegenteil geht man das Risiko des Pufferüberlaufs ein, denn dafür gibt es kein Feedback (Pakettyp), die Spec sagt nur das der Sender dafür sorgen soll das die Zahl der unbearbeiteten Zeichen <254 bleiben soll . Der Sender bemerkt das u.U. lediglich durch nicht quittierte TCP-Pakete(bei sehr kleinen Puffern) und schreibt dann in den Sendepuffer, also neuer Problempunkt. Die Puffergrössen können von 1Byte bis mehrere Hundert Kilobyte variieren, z.B. der Pi ist da grosszügig und druck noch 5 Seiten aus während die Verbindung vom Server schon lange beendet wurde (unbeabsichtigte Implementierung hier bei mir, dadurch wurde die Notwendigkeit einer Flusssteuerung anfangs kaschiert).

Für diejenigen die das hier alles verstanden haben und sich selber daran versuchen möchten, nur zu. Die Anleitung von Fred zur Flusskontrolle ist sehr gut beschrieben und meine Variante ist ja nicht sehr weit davon weg. Beide basieren auf sinnvollen Acks, ohne die nur ein statischer Fallback-Betrieb möglich wäre. Der Teufel steckt wie immer im Detail (Speichergrößen und Implementierung der Spec in den existierenden und künftigen verschiedenen Lösungen). Die derzeitige Serversoftware ist durchaus auch für 75/100 Baud auf Grund der Acks nutzbar, leider ist ein programmtechnischer Deckel für 50 Baud drin , ich denke mal darüber nach das flexibel zu machen, wohlwissend das die IP- Einflüsse bei steigender Baudrate mehr Einfluss haben.

Gruss
Willi

[BanditDD]

Hallo Willi,

Danke für Deine ausführlichen Erläuterungen - interessant!

Habe heute abermals probiert, die Liste abzurufen. Heute lief es perfekt, absolut flüssige Ausgabe am Gerät.

Danke und Gruß,
Thomas

[FredSonnenrein]

Hallo Willi,

Vorab: Sehr herzlichen Dank für deine ausführlichen Antworten, auch deine Ausarbeitungen zeigen ja stets viel Fleiß und Sorgfalt!

im Prinzip sind wir uns ja mal wieder einig, aber hier ein paar Antworten auf die neuerlichen Fragen.
Was macht der Server mit den Ackpaketen?
Natürlich lesen und berechnen wieviel unbearbeitete Pakete in der Gegenstelle im Puffer liegen und entsprechend anpassbarer Parameter moderat abbremst auf < 50 Baud. Wird die Differenz kleiner, wird wieder beschleunigt (u.U. >50 Baud) bis ein minimaler Pufferwert(derzeit 16 Zeichen) erreicht ist (max 254 nach Spec).

Okay, dann muss ich das nochmal testen. Ich hatte den Eindruck, dass auf meiner 75 Baud Maschine doch nur eine Schreibrate von etwa 50 Baud lief.

Diese Parameter haben Thomas und ich damals durch die vielen Tests eingestellt. Es ist im Gegensatz zu Deiner im WiKi beschriebenen Quasi Start/Stop Lösung (völlig in Ordnung) eine etwas analogere weiche Steuerung, die umso besser wird je öfter Acks kommen.

Ich schaue das mal auf dem Protokoll an, aber die Lösung klingt auch sehr gut. Sie kommt aber möglicherweise bei kurzzeitigen Störungen der Übertragung durcheinander.

Das die Pakete nicht in der Gleichförmigkeit ankommen wie gesendet meinte ich ja mir dem Begriff Jitter, daher ist etwas Puffervorrat unbedingt nötig. Über Puffergrössen haben wir schonmal reichlich diskutiert.
Das sortieren von TCP-Paketen braucht natürlich zusätzlichen Speicher und auch Zeit. Wenn hier viele kleinere Pakete zwischengelagert werden, kann man sehr gut sortieren und grössere Unzulänglichkeiten der Übertragung korrigieren. Kann man im selben Speicher aber nur 1-2 grössere mit max. 50 Zeichen (laut Spec. ich habe aber schon kleinere Werte von Dir gelesen) lagern, nimmt die Sortiermöglichkeit mit steigender Effizienz der Übertragung ab.

Puffergrößen: Das das i-Telex in Empfangsrichtung zwei Puffer hat, gibt es eine Limitierung:
Es gibt einen Puffer, der die emfpangenen Daten vom TCP-Stack puffert.
Es gibt einen zweiten Puffer, der die an den Fernschreiber zu sendenden 5-Bit-Daten puffert. Dieser ist nur 50 Bytes groß.
Da die i-Telex-Telegramme von der Software nur "am Stück" verarbeitet werden, darf ein Baudot-Daten-Telegramm nicht größer als dieser 50 Byte Puffer sein.
Das i-Telex sendet trotzdem nur maximal 21 Bytes (20 wollte ich implementieren, dann ist es doch ein > 20 geworden...) am Stück, um wenigstens alle 3 Sekunden Daten zu versenden.

Die Baudrate von im Mittel 50 Baud (egal ob Start/Stop oder analoger Modus) auch im IP/ TCP-Verkehr ergibt sich durch den Feedback der Acks zu 50 oder u.U. 75 Baud ganz automatisch, lediglich die Auslenkung vom Sollwert fällt bei der Start/Stop Methode kurzzeitig grösser, bei der analogen moderater aber ständig auf. Beide haben ja den Zweck, das Sender und Empfänger bestmöglich im zeitlichen Gleichlauf bleiben. Da am Ende nur mit 50/75 Baud gedruckt werden kann hat es keinen Sinn die Daten wesentlich schneller in den (unbekannten) Empfangspuffer zu schieben. Dieser Gleichlauf ergibt sich bei manuellem oder kurzen Lochstreifen fast von selbst, da hier Personen vor den FS sitzen.

Alles richtig... Ich bin gespannt...

Das Problem bei den Servern sind die extrem langen Verbindungszeiten zum Übertragen der Listen. Wir reden hier von bis zu 40 Minuten/ca 13000 Zeichen beim Kölner Dom. Soll danach noch ein sinnvoller weiterer Menüpunkt auswählbar sein, ist absoluter Gleichlauf zwingend. Alternativ könnte man natürlich die gewählte Datei bei entsprechenden Puffern in wenigen Sekunden übertragen und die Verbindung beenden, der Server stünde sofort wieder zur Verfügung für den nächsten Anruf. Der "Downloader" hat dann ja erstmal 40 Minuten Getöse um die Ohren. Diese Vision scheitert aber an den Puffern und der derzeitigen SW. Werden keine Acks vom Server empfangen, ist stumpf mit 50 Baud zu senden, egal wie der Ausdruck klingt. Eine Alternative wäre die absolute Schnellübertragung und serverseitiges verfolgen der hoffentlich gesendeten Acks. Was wäre dann gewonnen, im Gegenteil geht man das Risiko des Pufferüberlaufs ein, denn dafür gibt es kein Feedback (Pakettyp), die Spec sagt nur das der Sender dafür sorgen soll das die Zahl der unbearbeiteten Zeichen <254 bleiben soll . Der Sender bemerkt das u.U. lediglich durch nicht quittierte TCP-Pakete(bei sehr kleinen Puffern) und schreibt dann in den Sendepuffer, also neuer Problempunkt. Die Puffergrössen können von 1Byte bis mehrere Hundert Kilobyte variieren, z.B. der Pi ist da grosszügig und druck noch 5 Seiten aus während die Verbindung vom Server schon lange beendet wurde (unbeabsichtigte Implementierung hier bei mir, dadurch wurde die Notwendigkeit einer Flusssteuerung anfangs kaschiert).

Sehr gute Überlegung... Auch das i-Telex druckt den (bzw. beide) Puffer erst leer und beendet dann.

Für diejenigen die das hier alles verstanden haben und sich selber daran versuchen möchten, nur zu. Die Anleitung von Fred zur Flusskontrolle ist sehr gut beschrieben und meine Variante ist ja nicht sehr weit davon weg. Beide basieren auf sinnvollen Acks, ohne die nur ein statischer Fallback-Betrieb möglich wäre. Der Teufel steckt wie immer im Detail (Speichergrößen und Implementierung der Spec in den existierenden und künftigen verschiedenen Lösungen). Die derzeitige Serversoftware ist durchaus auch für 75/100 Baud auf Grund der Acks nutzbar, leider ist ein programmtechnischer Deckel für 50 Baud drin , ich denke mal darüber nach das flexibel zu machen, wohlwissend das die IP- Einflüsse bei steigender Baudrate mehr Einfluss haben.

Deckel von 50 Baud nach oben oder nach unten? So wie du es bisher beschrieben hast, klang es nicht so als würde es eine Begrenzung geben. Dennoch sind Begrenzungen sinnvoll, um deinen Regelkreis nicht bei Timeouts / Jitter "überschwingen" zu lassen. Mein Baugefühl sagt: Obergrenze sollte 150 Baud sein. Das entspricht etwa der Obergrenze, die das aktuelle i-Telex momentan verarbeiten kann. Und wesentlich mehr wird auch (im Fernschreibbereich) nicht sinnvoll sein.

Viele Grüße,

Fred