🚀 go-pugleaf

gero@gkminix.sub.org (Gero Kuhlmann) writes:
% ralf@ptavv.ka.sub.org (Ralf Wenk) writes:
%> gero@gkminix.sub.org (Gero Kuhlmann) writes:
%> > da faellt mir auch noch was zu dem Thema ein: Kuerzlich fiel mir auf,
%> > dass im /usr/spool/news immer Newsbatches stehen, die sich nicht entpacken
%> > lassen bzw. nur mit vielen Fehlern entpacken lassen. Es stellte sich
%> > heraus, dass diese Batches schon vom UUCP-1.2 so abgeliefert worden sind.
%> > 
%> > Eigentlich sollte der g-Treiber doch fehlerhafte Pakete waehrend der
%> > Uebertragung abweisen und neu anfordern! Also habe ich die printmsg-
%> 
%> Tut er (hier). Einzige Aenderungen RWINDOW von 1 auf 3 geaendert und
% 
% Das steht ja auch so im Patch von 1.2.0 auf 1.2.1 drin. Leider erhoeht
% sich dann bei mir aber die Zahl der Fehler drastisch.

Ich habe den 1.2.1er Patch (noch) nicht eingespielt. Bei Dir erhoeht
sich also die Fehlerzahl sobald die Gegenseite nicht mehr auf die
Quittung fuer jedes Paket warten muss. Hast Du mal mit den RS232-Puffern
herumexperimentiert ?

%> die Logmeldungen fuer bad, lost und reject Pakete so geaendert, dass
%> sie immer protokolliert werden. Einziges bekanntes Problem: _manchmal_
%> kommen Rejectpakete rein die aus den aktuellen Fenster herausfallen.
%> Danach klappt die Resynchronisation fast nie.
% 
% Manchmal? Wenn bei mir eine Stoerung auf der Leitung auftritt, ist die
% Resynchronisation _immer_ gestoert. Das ist reproduzierbar (ich kann
% Stoerungen auf meiner Leitung "kuenstlich" erzeugen).

Dann mach doch mal eine Verbindung mit -x9 und lass Dir von der
Gegenstelle das Protokoll senden. Ein Vergleich sollte ergeben was bei
der Resynchronisation falsch laeuft. Falls Dein Rechner zu langsam ist
um volle Transferleistung und Log-Protokoll zu fahren musst Du das Log-
Protokoll bei Dir ausschalten und die Aktionen Deiner Seite erraten.

%> [...]
%> > Erstaunlich ist, dass die Zahl der Fehler deutlich zunimmt, wenn man
%> > die Patches von UUCP-1.2.0 auf UUCP-1.2.1 anbringt. Dabei wird mit
%> > dem g-Treiber-Patch nur die Window-Groesse von 1 auf 3 geaendert.
%> 
%> Und noch ein anderer Patch. Bist Du sicher, dass es nicht an diesem
%> liegt ?
% 
% Ziemlich sicher. Im uebrigen glaube ich auch nicht, dass der Fehler durch
% diesen Patch _erzeugt_ wird. Er tritt nur wesentlich deutlicher in Erschei-
% nung. M.E. ist schon in der Version 1.2.0 irgendwas faul. Ich habe schon
% ziemlich viel von anderen Rechnern via UUCP bekommen - ohne Probleme. Nur
% bei meinem News-Feed gehts schief, wenn Stoerungen auf der Leitung sind.
% Offensichtlich vertraegt sich Will's UUCP doch nicht mit allen anderen.

Hast Du eine FvK UUCP Version vorher gehabt ? Wie lief es damit ?
Was fuer ein UUCP hat die Gegenstelle ? Was fuer ein Modem ?

-- 
-- 
Ralf Wenk -- ralf@ptavv.ka.sub.org