Telexforum.de

Ich wollte heute von meinem Lo3000 mit 100 Baud eine längere Nachricht an einen Teilnehmer mit nur 50 Baud senden. Ja, ich weiß, daß dabei die langsamere Empfangsgeschwindigkeit zu beachten ist, aber es hat bisher immer recht gut funktioniert, auch bei langen Nachrichten.

Heute kam es jedoch nach ca. einer 1/2 Seite immer an der gleichen Stelle wiederholt zum Abbruch der Übertragung mit der Meldung occ. Eine Testsendung an mein anderes i-Telex klappte allerdings einwandfrei. Nach Rückfrage beim Empfänger, stellte sich heraus, daß er eine Light-Karte verwendet.

In der Vermutung, daß es zu einem Speicherüberlauf kommt, habe ich dann die Sendung nochmals gestartet und dann immer wieder Pausen eingefügt. Diesmal klappte es dann einwandfrei. Ich fühle mich nun mit der Vermutung bestätigt.

Vermutlich wird es nicht viele Leute mit dieser außergewöhnlichen Konfiguration geben und es ist für mich auch kein Problem. Ich muß mich eben nur darauf einstellen. Dennoch würde es mich interessieren, ob es dafür eine Erklärung gibt und ob dieses Verhalten schon einmal jemand beobachtet hat?

WolfgangH hat geschrieben: ↑So 21. Apr 2024, 16:04 In der Vermutung, daß es zu einem Speicherüberlauf kommt, habe ich dann die Sendung nochmals gestartet und dann immer wieder Pausen eingefügt. Diesmal klappte es dann einwandfrei. Ich fühle mich nun mit der Vermutung bestätigt.

Das klingt grundsätzlich plausibel. Fred können wir leider nicht fragen.

Aber zwischen den Ethernetkarten gibt es einen Handshake. Da dürfte kein Überlauf stattfinden. Wenn der Puffer der empfangenden Ethernetkarte voll ist, wird die sendende Ethernetkarte gestoppt (dafür gibt es ein Acknowledge-Paket). Wenn das nicht so wäre, würde jeder Dienst zu einem Überlauf führen. Denn die meinsten Dienste sind nicht auf 50 Baud begrenzt. Bei Willis Diensten ist das glaube ich anders. Die senden konstant mit 50 Baud.

Aber zwischen deiner Ethernetkarte und deinem 100 Baud Fernschreiber gibt es lokal keinen Handshake. Den Fernschreiber kann man nicht stoppen. Deswegen hätte ich den Überlauf eher lokal erwartet. Also dein T100 überrennt deine Ethernetkarte, wenn die Karte des Empfängers die Daten nicht schnell genug abnimmt.

Das sind jetzt aber Vermutungen auf Basis des i-Telex-Protokolls. Was in den Ethernetkarten genau abläuft, das weiß ich nicht.

Ich holt das Thema noch mal hoch. Franz hat ja inzwischen einen T100 mit 75 Baud und der 75 Baud Firmware für die TW39-Karte.
Wir haben heute mal ein paar Tests gemacht und Franz hat einen längeren Text (4300 Zeichen) vom Lochstreifen an Werner, Reinhold und mich gesendet. Im einzelnen folgende Tests:

Franz (75 Baud, Standard-Ethernet) an Werner (50 Baud, Light-Ethernet) - Abbruch nach ca. 2000 Zeichen (Test 2x wiederholt)
Franz (75 Baud, Standard-Ethernet) an Reinhold (50 Baud, Standard-Ethernet) - kein Fehler
Franz (75 Baud, Standard-Ethernet) an Detlef (50 Baud, Standard-Ethernet) - kein Fehler
Franz (75 Baud, Standard-Ethernet) an Detlef (50 Baud, Light-Ethernet) - kein Fehler (!!!)
Was noch aussteht, wären Tests mit Ethernet-Light auf der Sende-Seite. Aber Franz hat keine Ethernet-Light.

Wie man sieht, konnten die Abbrüche von Werners Ethernet-Karte mit meiner Ethernet-Light-Karte nicht reproduziert werden. Trotz gleicher Firmware-Version 953. Franz wird den Test an Werner nochmal mit 50 Baud wiederholen. Nicht, dass die Ethernet-Karte ein Problem hat.

Ich hatte aber eigentlich mit Fehlern bei allen 4 Tests gerechnet. Denn ich war davon ausgegangen, dass die Ethernetkarten (auch die Standard) keinen ausreichend großen Pufferspeicher hat, um den 33% zu schnell gesendeten Text zu puffern. Und zwar völlig unabhängig von Standard oder Light. Der empfangende Fernschreiber lief immerhin ca. 10 Minuten lang nach.

Also wer puffert da?

Fred hätte uns das sicher sofort erklären können. Aber das geht ja nun nicht mehr. Henning, hast du eine Erklärung, wie das funktioniert?

Wie Wolfgang schon im ersten Beitrag gepostet hatte, war es heute bei der Verbindung zu Werner genauso, nach einer Weile Abbruch und dann noch die Meldung "occ ".

Ich habe NULL Ahnung von Firmware/Software/Übertragungsprotokoll.
Ich kann mich nur erinnern, dass Fred immer von einem 3000 Zeichen Pufferspeicher gesprochen hat.

Ok, 3000 Zeichen würde ungefähr passen. Das würde ausreichen, um den Text in unserem Test zu puffern.
Dann bräuchten wir einen längeren Text, um einen Pufferüberlauf zu erzeugen.

Ich habe jetzt auch noch mal den Quellcode der Ethernetkarte durchsucht, aber leider keinen Hinweis auf einen 3000 Byte großen Pufferspeicher gefunden.

Ich war bisher der Meinung, dass der ATmega1284 der Ethernet-Light-Karte weniger RAM-Speicher hat, als der ATmega2561 der Standard-Ethernet-Karte. Das stimmt aber nicht. Der ATmega1284 hat mit 16 KB den doppelten RAM-Speicher. Wegen irgendwelcher Puffergrößen kann es also bei der Light-Karte eigentlich keine EInschfänkungen geben.

Wir werden nochmal weiter testen.

I might be wrong, but I thought the character buffer was in each interface card?

The ATmega168 on the interface card only has 1 Kbytes of RAM. Not much space for a buffer.

It should also be noted that the internal i-Telex bus does not transmit bytes, but bits, which are passed on directly to the end device. And when received from the end device, they are also forwarded directly to the bus.

Das Problem ist der Sendebuffer, wenn vom Schreiber die Daten mit 100baud kommen und nur mit 50baud weggehen ist nicht der Empfänger das Problem sondern der Sender. Es gibt ja keine Möglichkeit den Schreiber zu stoppen und der schiebt weiter Daten in den Sendebuffer. Dieser läuft dann langsam zu. Wenn man den Emfangsbuffer zu sehr füllt, sendet die Firmware aus ungeklärten Grund keine ACK Pakete mehr. Je nachdem wie die Flusskontrolle implementiert wurde wird dann auch der Sendebuffer nicht geleert. Womit um so schneller dieser zuläuft und die einzige Reaktion ist dann die Verbindung zu beenden.

100baud -> 50baud macht einen Überschuss von 50% das wären bei 4300Zeichen 2150 Zeichen im Sendebuffer aufgefangen werden müssen. Wenn es gut läuft kommt es durch die Flusskontrolle zu Verzögerungen oder Fehlern läuft dieser weiter zu.

Interessant wäre welche Seite die Verbindung trennt...