🚀 go-pugleaf

In <JOCHEN.92Jul30222426@busybit.mrz.lm.sub.org> jochen@busybit.mrz.lm.sub.org (Jochen Fahrner) writes:
>Kann mir jemand sagen, was das bedeutet und was die ursache sein kann?

Schwierig zu sagen. Was fuer eine serielle Schnittstelle hast Du? Eine
stinknormale oder eine mit 16550. Falls letztere, werden die 550er
erkannt?

Ich wuerde mal vermuten, dass Dir Zeichen verloren gehen.
-- 
				Christoph Badura  ---  bad@flatlin.ka.sub.org

ISO? Nicht immer, aber immer M-vfter.

bad@flatlin.ka.sub.org (Christoph Badura) writes:

>In <JOCHEN.92Jul30222426@busybit.mrz.lm.sub.org> jochen@busybit.mrz.lm.sub.org (Jochen Fahrner) writes:
>>Kann mir jemand sagen, was das bedeutet und was die ursache sein kann?

>Schwierig zu sagen. Was fuer eine serielle Schnittstelle hast Du? Eine
>stinknormale oder eine mit 16550. Falls letztere, werden die 550er
>erkannt?
Wuerd ich auch mal vermuten, dass es keine 550er sind.
Abhilfe:
die Schnittstelle mit 16550er versehen und FAS einbinden anstatt
des SIO. Ich hatte frueher auch mal solche Probleme. Mit Fas laeuft
dann alles reibungslos.... :-))

bis denne
Thomas
-- 
  I~~~~~~~~~~~~~~~~~~~~~~\~~~~~~email: ths@schuh.hanse.de<*>~~~~~~~~/~~~~~~~~I
  I      Thomas Schulz     \            btx@schuh.sub.org         /          I
  I                          \    BTX  : 0407158600 0001        /~~~~~~~~~~~~I
  I    Max-Pechsteinstr.6     >-------------------------------<  Don't Panik I

In article <BsF20K.3un@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:

   Schwierig zu sagen. Was fuer eine serielle Schnittstelle hast Du? Eine
   stinknormale oder eine mit 16550. Falls letztere, werden die 550er
   erkannt?

   Ich wuerde mal vermuten, dass Dir Zeichen verloren gehen.

Moeglich, aber eher unwahrscheinlich. Ich benutze nur 9600bps und die
werden von SCO garantiert, dass Sie funktionieren. Die Rechner sind
auch schnell genug, beide 486er >= 33 MHz.
Ich koennte mir vielleicht vorstellen, dass es was mit der flowcontrol
des Rechner zu tun hat, der SCO 3.2.2 hat. Da geht die
hardwareflowcontrol naemlich nur in eine Richtung. Das Modem kann mit
CTS den Rechner bremsen, aber nicht umgekehrt der Rechner das Modem.

Aber die Stockungen treten nur dann auf, wenn ich etwas von dem
3.2.2-Rechner empfange, in dem Moment bekommt er von mir nur die ACKs,
und die werden doch wohl nicht durch fehlende flowcontrol
verlorengehen, oder doch ?
In der anderen Richtung, wenn ich zum 3.2.2-Rechner sende, treten
keine Stockungen auf. Wenns andersrum waere, koennte ich mir das durch
die fehlende flow-control erklaeren.

Jochen
-- 
Jochen Fahrner, D-8068 Pfaffenhofen, jochen@busybit.mrz.lm.sub.org

In <JOCHEN.92Aug5193103@busybit.mrz.lm.sub.org> jochen@busybit.mrz.lm.sub.org (Jochen Fahrner) writes:
>Ich koennte mir vielleicht vorstellen, dass es was mit der flowcontrol
>des Rechner zu tun hat, der SCO 3.2.2 hat. Da geht die
>hardwareflowcontrol naemlich nur in eine Richtung. Das Modem kann mit
>CTS den Rechner bremsen, aber nicht umgekehrt der Rechner das Modem.

In 3.2.2 schaltet der uucico die Flowcontrol-Flags ab, kann also nicht
sein.

>Aber die Stockungen treten nur dann auf, wenn ich etwas von dem
>3.2.2-Rechner empfange, in dem Moment bekommt er von mir nur die ACKs,
>und die werden doch wohl nicht durch fehlende flowcontrol
>verlorengehen, oder doch ?

Unwahrscheinlich. Wahrscheinlicher verlierst *Du* beim Empfangen die
Datenpakete.

Poste halt mal die Auszuege aus einem -x9 Log vom uucico. Interessant
sind die Zeilen ab "got 'Pg'" bis nach INITC, und die Stelle wo
Stockungen auftreten. Der Rest ist uninteressant.

-- 
				Christoph Badura  ---  bad@flatlin.ka.sub.org

ISO? Nicht immer, aber immer M-vfter.

In article <Bsn6t9.Jzn@flatlin.ka.sub.org> bad@flatlin.ka.sub.org (Christoph Badura) writes:

   Unwahrscheinlich. Wahrscheinlicher verlierst *Du* beim Empfangen die
   Datenpakete.

   Poste halt mal die Auszuege aus einem -x9 Log vom uucico. Interessant
   sind die Zeilen ab "got 'Pg'" bis nach INITC, und die Stelle wo
   Stockungen auftreten. Der Rest ist uninteressant.

Hatte ich bereits ganz zu Beginn der Diskussion gepostet.
Mittlerweile hat sich das Raetsel aber geloest: Muss wohl so gewesen
sein, dass mein Rechner ankommende Zeichen verloren hat. Ich habe
gestern den fas-Treiber installiert, seitdem treten die Stockungen
nicht mehr auf.

Das Versprechen von SCO, dass ihr Treiber mit 9600bps noch garantiert
funktioniert, ist scheinbar nichts wert :-(

Was mich aber dennoch wundert: Wieso reagiert das uucp-g Protokoll so
empfindlich auf verlorene Zeichen ? Sowas kann doch bei
Leitungsstoerungen genauso passieren, oder ? Mit scuzzy in Berlin ist
mir z.B. staendig die Verbindung total abgebrochen. Sollte doch nicht
sein oder ?

Da mich aber trotzdem interressiert, wie man aus dem uucico -x9 Log
rauslesen kann, warum es zu den Stockungen kam, poste ich hier noch
einmal den Log. Vielleicht kannst Du dann mal kurz erklaeren, wie man
den lesen muss.
---------------------------------------
omsg "Sbusybit -Q0 -x9"
imsg >^PROK^@msg-ROK
 Rmtname mrz, Role MASTER,  Ifn - 5, Loginuser - root
rmesg - 'P' imsg >^PPgexf^@got Pgexf
wmesg 'U'g
omsg "Ug"
send 77
pkgetpack: Connodata=1
rec h->cntl 77
send 61
state - [INIT code a] (1)
pkgetpack: Connodata=2
rec h->cntl 61
send 57
state - [INIT code a]&[INIT code b] (3)
pkgetpack: Connodata=3
rec h->cntl 57
state - [O.K.] (10)
Proto started g
*** TOP ***  -  role=1, setline - X
gtwvec: dir /usr/spool/uucp/mrz
wmesg 'H'
send 37777777610
rmesg - 'H' pkgetpack: Connodata=4
rec h->cntl 41
pkcntl: RR/RJ: Connodata=0
state - [O.K.] (10)
pkgetpack: Connodata=1
rec h->cntl 37777777611
send 41
got HN
 PROCESS: msg - HN
HUP:
*** TOP ***  -  role=0, setline - X
rmesg - '
rec h->cntl 37777777621
send 42
got S D.mrz666012a D.mrz666012a mmdf - D.mrz666012a 0666 mmdf
 PROCESS: msg - S D.mrz666012a D.mrz666012a mmdf - D.mrz666012a 0666 mmdf
SNDFILE:
msg - S
Remote Requested: mrz!D.mrz666012a --> busybit!D.mrz666012a (mmdf)
SLAVE - cntrl_cntrl_filename: /usr/spool/uucp/mrz/D.mrz666012a
chkpth ok Rmtname - mrz
TMname(/usr/spool/uucp/mrz/TM.00482.000)
wmesg 'S'Y
send 37777777622
pkgetpack: Connodata=1
rec h->cntl 42
pkcntl: RR/RJ: Connodata=0
state - [O.K.] (10)
pkgetpack: Connodata=1
rec h->cntl 37777777632
send 43
pkgetpack: Connodata=1
rec h->cntl 37777777642
send 44
pkgetpack: Connodata=1
rec h->cntl 37777777652
send 45
pkgetpack: Connodata=1
rec h->cntl 37777777662
send 46
pkgetpack: Connodata=1
rec h->cntl 37777777672
send 47
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40

[ Das wiederholt sich jetzt munter, bis folgendes auftritt: ]
[ Die Zahlen bei "Connodata=1" zaehlen ploetzlich weiter,   ]
[ bei 6 tritt dann die Pause ein, und mit 1 geht es wieder weiter ]

pkgetpack: Connodata=1
rec h->cntl 37777777632
send 43
pkgetpack: Connodata=1
rec h->cntl 37777777642
send 44
pkgetpack: Connodata=1
rec h->cntl 37777777652
pkgetpack: Connodata=2
rec h->cntl 37777777672
pkgetpack: Connodata=3
rec h->cntl 37777777612
pkgetpack: Connodata=4
rec h->cntl 37777777622
pkgetpack: Connodata=5
rec h->cntl 37777777632
pkgetpack: Connodata=6
rec h->cntl 37777777652
send 25
pkgetpack: Connodata=1
rec h->cntl 37777777662
send 46
pkgetpack: Connodata=1
rec h->cntl 37777777672
send 47
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40
pkgetpack: Connodata=1
rec h->cntl 37777777612
send 41
pkgetpack: Connodata=1
rec h->cntl 37777777622
send 42
pkgetpack: Connodata=1
rec h->cntl 37777777632
send 43
pkgetpack: Connodata=1
rec h->cntl 37777777642
send 44
pkgetpack: Connodata=1
rec h->cntl 37777777652
send 45
pkgetpack: Connodata=1
rec h->cntl 37777777662
send 46
pkgetpack: Connodata=1
rec h->cntl 42
pkcntl: RR/RJ: Connodata=1
state - [O.K.] (10)
pkgetpack: Connodata=2
rec h->cntl 37777777672
send 47
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40
pkgetpack: Connodata=1
rec h->cntl 37777777612
send 41
pkgetpack: Connodata=1
rec h->cntl 37777777622
send 42
pkgetpack: Connodata=1
rec h->cntl 37777777632
send 43
pkgetpack: Connodata=1
rec h->cntl 37777777642
send 44
pkgetpack: Connodata=1
rec h->cntl 37777777652
send 45
pkgetpack: Connodata=1
rec h->cntl 37777777662
send 46
pkgetpack: Connodata=1
rec h->cntl 37777777672
send 47
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40
pkgetpack: Connodata=1
rec h->cntl 37777777612
send 41
pkgetpack: Connodata=1
rec h->cntl 37777777622
send 42
pkgetpack: Connodata=1
rec h->cntl 37777777632
send 43
pkgetpack: Connodata=1
rec h->cntl 37777777642
send 44
pkgetpack: Connodata=1
rec h->cntl 37777777652
send 45
pkgetpack: Connodata=1
rec h->cntl 37777777662
send 46
pkgetpack: Connodata=1
rec h->cntl 37777777672
send 47
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40
pkgetpack: Connodata=1
rec h->cntl 37777777612
send 41
pkgetpack: Connodata=1
rec h->cntl 37777777622
send 42
pkgetpack: Connodata=1
rec h->cntl 37777777632
send 43
pkgetpack: Connodata=1
rec h->cntl 37777777642
send 44
pkgetpack: Connodata=1
rec h->cntl 37777777652
send 45
pkgetpack: Connodata=1
rec h->cntl 37777777662
send 46
pkgetpack: Connodata=1
rec h->cntl 37777777672
send 47
pkgetpack: Connodata=1
rec h->cntl 37777777602
send 40

------------------------------------------

Also *Ich* kann daraus nichts entnehmen :-(

Jochen
-- 
Jochen Fahrner, D-8068 Pfaffenhofen, jochen@busybit.mrz.sub.org

In article <JOCHEN.92Aug12192756@busybit.mrz.sub.org>, Jochen Fahrner writes:

> Was mich aber dennoch wundert: Wieso reagiert das uucp-g Protokoll so
> empfindlich auf verlorene Zeichen ?

	Mit einem verlorenen Zeichen verliert das g-Protokoll immer
mindestens zwei Pakete (fast, bei Windowsize 1 wohl nicht unbedingt,
aber... :) ): das Paket, zu dem das verlorene Zeichen gehoerte -
logisch - und das nachfolgende Pakete, denn dessen Header wird nicht
erkannt.  Der Anfang des Headers wird als Ende des ersten Pakets
eingelesen, dem ja noch Zeichen fehlen.  Erst das dritte Paket kann
wieder erkannt werden, weil der uucico nach einem Header sucht.

	Dazu kommt, dass es nicht genuegt, nur das Paket nochmal zu
uebertragen, das fehlerhaft war bzw. nicht erkannt wurde.  Alle Pakete,
die danach kommen, muessen nochmal gesendet werden, auch wenn sie schon
korrekt empfangen wurden.  Es koennen ein paar Pakete sein, die der
Sender schon an sein Modem abgegeben hat bevor er das `Halt, alles
nochmal' bekommt.

> Da mich aber trotzdem interressiert, wie man aus dem uucico -x9 Log
> rauslesen kann, warum es zu den Stockungen kam, poste ich hier noch
> einmal den Log.

	Aus den Unix-Logs werde ich auch nicht so ganz schlau.  Schon
das `37777777' in `rec h->cntl 37777777611' mach mich skeptisch ;-)

> pkgetpack: Connodata=1

	Wofuer das das steht habe ich auch mal gewusst - und wieder
vergessen.  Kann mal jemand nachhelfen?

> rec h->cntl 37777777642

	Der uucico hat ein Paket bekommen, in dem das Kontrollbyte
auf 242 (oktal) steht%.  Die erste 2 besagt, dass es sich um ein
Datenpaket handelt, die 4 ist die Sequenznummer dieses Paketes,
und die 2 ist die Sequenznummer des letzten Daten-Paketes, das
Dein uucico korrekt empfangen hat.

	% Das ist als signed char negativ, weil das achte Bit gesetzt
ist.  Uebergibt man in C einen solchen char an printf(), wird der zu
int erweitert, d.h. links mit Einsen (weil negativ) aufgefuellt.  Das
Ergebnis ist die 37777777 (und 6 statt 2).

> send 44

	Dein uucico hat ein Paket gesendet, das Kontrollbyte ist
044 (wieder oktal).  Die 0 kennzeichnet es als Kontrollpaket
(nur Header, keine Daten), die erste 4 steht fuer ACK, die zweite
gibt die Nummer des Paketes, dessen Empfang mit diesem ACK
bestaetigt werden soll.

[...]

> [ Das wiederholt sich jetzt munter, bis folgendes auftritt: ]
> [ Die Zahlen bei "Connodata=1" zaehlen ploetzlich weiter,   ]
> [ bei 6 tritt dann die Pause ein, und mit 1 geht es wieder weiter ]
>
> pkgetpack: Connodata=1
> rec h->cntl 37777777632
> send 43

	Paket mit Sequenznummer 3 empfangen und bestaetigt...

> pkgetpack: Connodata=1
> rec h->cntl 37777777642
> send 44

	4 empfangen und bestaetigt...

> pkgetpack: Connodata=1
> rec h->cntl 37777777652

	5 empfangen - und noch nicht bestaetigt, das wahr wohl defekt(?)...

> pkgetpack: Connodata=2
> rec h->cntl 37777777672

	6 fehlt, 7 wird wieder empfangen, aber das kann er jetzt gar
nicht brauchen...

> pkgetpack: Connodata=3
> rec h->cntl 37777777612
> pkgetpack: Connodata=4
> rec h->cntl 37777777622
> pkgetpack: Connodata=5
> rec h->cntl 37777777632
> pkgetpack: Connodata=6

	Es geht noch mehr verloren.  0 und 4 fehlen auch.

> rec h->cntl 37777777652
> send 25

	Jetzt steig' ich auch nicht mehr durch (aehem :) ).  Wieso
sendet er jetzt erst das NACK (die 2 steht dafuer)?  Und wieso bekommt
er schonwieder ein Paket mit Sequenznummer 5, er hat doch die letzte
5 bisher gar nicht bestaetigt.  Oder ist das nochmal die 5 von oben,
die der andere uucico nochmal sendet, weil er inzwischen noch kein
ACK dafuer bekommen hat?  OK, letzteres koennte ich verstehen, aber
warum das NACK so spaet?  Steckt dahinter irgendeine magische Strategie,
hab ich was voellig falsch verstanden, oder ist das wirklich so dumm,
wie es mir erscheint?

	Mit Sicherheit sind dabei einige Pakete (7?) verloren
gegangen.  Das sich das auf Dauer negativ auf den Durchsatz
auswirkt, ist klar.  Aber mir scheint, dass es durch die
Implementation schlimmer gemacht wird, als es vom g-Protokoll
aus sein muesste.  Wie gesagt, das spaete NACK irritiert mich.

[...]
> pkgetpack: Connodata=1
> rec h->cntl 37777777662
> send 46
> pkgetpack: Connodata=1
> rec h->cntl 42
> pkcntl: RR/RJ: Connodata=1
> state - [O.K.] (10)

	Ein ACK, wo kommt das denn her?

> pkgetpack: Connodata=2
> rec h->cntl 37777777672
[...]

> Also *Ich* kann daraus nichts entnehmen :-(

	Ich hab auch so meine Schwierigkeiten :)  Ich hoffe, dass
es die die Kenner jetzt ob soviel Bloedsinns nicht mehr haelt ;^)

> Jochen

	Tschuess, Gerald.

-- 
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: +49 531 796832
\X/ gm@germal.bs.open.de                      Mittagspause von 0.30 - 23.45 Uhr