XP 2.93 / uucico-Timingprobleme
Peter Mandrella
Ich moechte noch einmal darauf hinweisen, dass der im XP-2.93-Paket
enthaltene uucico (und nur der) schwere Timingprobleme hat. Das ist kein
generelles Problem des XP-uucico, sondern ein Bug in Version 2.93.
Abhilfe schafft
- Verwenden des alten uucico von XP 2.92
- Verwenden des Bugfix-uucico fuer XP 2.93 (s. Nachricht von Hajo Zierke)
- Verwenden des neuen uucico, der in Kuerze mit XP 3.0 erscheint.
Peter
Matthias Brunke
> Ich moechte noch einmal darauf hinweisen, dass der im XP-2.93-Paket
> enthaltene uucico (und nur der) schwere Timingprobleme hat. Das ist kein
> generelles Problem des XP-uucico, sondern ein Bug in Version 2.93.
Ich nochmal darauf hinweisen, dass nicht nur dieser uucico, sondern auch
der Fix und aeltere, Probleme (out of sequence, error receiving uucp-
command) bereiten wobei der Fix noch am ertraeglichsten ist.
Gegenseiten sind fxuucico und taylor.
Matthias
--
Matthias Brunke email: matt...@bonbit.deceiver.sub.org
voice: +49-431-556645 Never place friendship above profit. (RoA #21)
## CrossPoint v2.93 ##
Andre Friedrich
Wie meinte *Matthias Brunke *am 18.03.94
zu *"Re: XP 2.93 / uucico-Timingprobleme"*
in "de.comm.uucp"?
>pe...@xpoint.ruessel.sub.org (Peter Mandrella) writes:
>
>> Ich moechte noch einmal darauf hinweisen, dass der im XP-2.93-Paket
>> enthaltene uucico (und nur der) schwere Timingprobleme hat. Das ist kein
>> generelles Problem des XP-uucico, sondern ein Bug in Version 2.93.
>
>Ich nochmal darauf hinweisen, dass nicht nur dieser uucico, sondern auch
>der Fix und aeltere, Probleme (out of sequence, error receiving uucp-
>command) bereiten wobei der Fix noch am ertraeglichsten ist.
>
Der Mann spricht die Wahrheit. Schwer nervende Timeouts quaelen auch mich.
Alle denkbaren Einstellunegn getestet. Der Fix brachte da auch nicht allzu
viel...
Gruesse Andre
*HIGH ON HOPE!*
## CrossPoint v2.93 ##
Matthias Brunke
> Der Mann spricht die Wahrheit. Schwer nervende Timeouts quaelen auch
> mich. Alle denkbaren Einstellunegn getestet. Der Fix brachte da auch
> nicht allzu viel...
Na Danke... Ich dachte schon, ich sei zu bloede.
Der UUCICO hat sich seit der 2.15 nur langsam verbessert.
Am schlimmsten war und ist es beim Senden.
Einige Artikel geschrieben, der UUCICO schob einige Jobs hoch, hing, und
stieg irgendwann mit "error receiving uucp command" aus.
Alle bisher geschickten Jobs werden natuerlich vom Feed verarbeitet, was
XP aber nicht hindert, sie weiter als unversandt zu betrachten.
Toll, ewig zu hoeren: "Ich habe diese Mail aber 5 Mal bekommen...".
Von dem eventuellen Muell in den Spool-Verzeichnissen mal abgesehen.
Oder aber beim Empfangen (inzwischen sehr selten) die besagten "out of
sequence" bzw. im Log dann "error receiving file". [Click]
Grosse UUCP-Jobs zu senden ist selbst bei dem Fix der 2.93 eine
Katastrophe.
Irgendwann habe ich die Hoffnung dann aufgegeben. Die Probleme des Fido-
Mailers mit ZyXEL-Modems wurden ja auch irgendwann behoben, wobei Peter
Mandrella die Schuld fuer die Fehler der Firma ZyXEL gab und bekundete,
er faende es unschoen, dass er deren Fehler extra beruecksichtigen
muesse.
Inzwischen habe ich die Nase von den Pollproblemem voll, installierte
Waffle und komme seitdem bestens zurecht.
Ich benutze aber dennoch XP zum Lesen, weil ich die News damit am
schnellsten bewaeltigen kann und alle Netze in einem Programm habe.
Die Konvertierung nach ZCONNECT halte ich nicht fuer sonderlich guenstig
und das Datenbankkonzept bedarf meiner Ansicht nach fuer die hier
teilweise auftretenden Datenmengen einer kompletten Ueberarbeitung.
Wann Peter Mandrella das aber machen soll, weiss ich selbst nicht. Mit
den jetzigen Erweiterungen und dem Support ist er sicherlich mehr als
ausgelastet.
Dennoch ist XP ein sehr gutes Programm. Es bietet fuer die Gebuehren
einen unschlagbaren Funktionsumfang. Die Erweiterungen in letzter Zeit
waren betraechtlich. Wuensche und Fragen der User werden wenn moeglich
beruecksichtigt.
Aber ich werde das Gefuehl nicht los, dass alle bisherigen per UUCP
pollenden XP-User keine grossen Jobs an ihren Feed senden muessen...
> Gruesse Andre
Matthias
--
I am Clinton of Borg. Hillary says resistance is futile!
Matthias Brunke matt...@bonbit.deceiver.sub.org
voice: +49-431-556645 Matthias Brunke 2:242/257.9, M_BR...@KBBS.ZER
## CrossPoint v2.93 ##
Peter Mandrella
> Der Mann spricht die Wahrheit. Schwer nervende Timeouts quaelen auch mich.
> Alle denkbaren Einstellunegn getestet. Der Fix brachte da auch nicht allzu
> viel...
Warum erfahre ich sowas immer erst zufaellig in irgendeiner Newsgroup?
*seufz*. Also, wenn es massive Probleme gibt -> Mail an mich, mit
moeglichst exakter Beschreibung. Wenn mehrere Sites, die an der gleichen
Stelle pollen, die gleichen, reproduzierbaren Probleme mit dem uucico
haben, brauche ich einen *Testaccount*, damit ich die Ursache finden
kann.
Das wundert mich schon seit Monaten: Warum gibt es im Usenet - im
Gegensatz zu allen anderen Netzen - fast niemanden, der Fehler an den
Programmautor meldet? Reagieren andere Leute nicht auf Bugreports? Oder
kommt es daher, dass man gewohnt ist, sich bei Problemen den Quelltext
eines Programmes besorgen und selbst darin herumstochern zu muessen?
Ich bin immer wieder verbluefft, wenn ich von Problemen erfahre, mit
denen sich offenbar dutzende von XP-UUCP-Usern ueber Monate hinweg
herumgeschlagen haben, ohne mir auch nur das Geringste davon zu sagen.
Nunja, vielleicht aendert sich das ein wenig, falls es demnaechst eine
eigene crosspoint-Newsgroup gibt.
Peter
Axel P. Roschinski
>> Der Mann spricht die Wahrheit. Schwer nervende Timeouts quaelen auch
>> mich. Alle denkbaren Einstellunegn getestet. Der Fix brachte da auch
>> nicht allzu viel...
Modem benutzte, ohne Kompression klappt alles wie am Schnürchen.
>Grosse UUCP-Jobs zu senden ist selbst bei dem Fix der 2.93 eine
>Katastrophe.
Was definierst Du als große UUCP-Jobs? Ich habe seit Anfang dieses
Quartals mit XP etwa 400 MB durch die Gegend geschoben, auch Sendungen
_von_ mir auf den Server kamen problemlos an. Dazwischen waren ein paar
Jobs, die auch mal so ein-zwei MB am Stück rausgeschickt haben...
>Die Konvertierung nach ZCONNECT halte ich nicht fuer sonderlich guenstig
Dieser Meinung kann ich mich anschließen.
Axel <>\/\/
-- 'I think you are experiencing a certain transcendent experience which
can be best described as "a clue is biting you ON THE BUTT".' -- Kibo
## CrossPoint v2.93 R ##
Matthias Brunke
> Die einzigen Probleme hatte ich als ich noch Kompression bei meinem
> Modem benutzte, ohne Kompression klappt alles wie am Schnuerchen.
Das ist ja auuch nicht die wahre Loesung.
> Was definierst Du als grosse UUCP-Jobs? Ich habe seit Anfang dieses
> Quartals mit XP etwa 400 MB durch die Gegend geschoben, auch Sendungen
> _von_ mir auf den Server kamen problemlos an. Dazwischen waren ein
Eben das, was XP als "Nachricht, Fileserver, Senden" bezeichnet.
Matthias
--
Extremities where I can see them! - Odo
Matthias Brunke matt...@bonbit.deceiver.sub.org
voice: +49-431-556645 Matthias Brunke 2:242/257.9, M_BR...@KBBS.ZER
## CrossPoint v3.0 ##
Axel P. Roschinski
>> Die einzigen Probleme hatte ich als ich noch Kompression bei meinem
>> Modem benutzte, ohne Kompression klappt alles wie am Schnuerchen.
>
>Das ist ja auuch nicht die wahre Loesung.
prinzipiell vergebliche Liebesmüh' sie noch weiter komprimieren zu wollen.
Ich denke inzwischen sogar darüber nach, auch noch V.42 abzustellen, um
noch ein wenig Protokolloverhead zu sparen. ZModem sollte es eigentlich
alleine packen. (Das wird ein Test für die Laboer und Kieler
Telefonleitungen... mal sehen. ;-) )
Ich komme mit g-Protokoll, 4096/7, auf eine durchschnittliche
Übertragungsrate von knapp 1800 cps auf die gesamte Verbindung, bei einem
16800er Connect. (Da sind auch die Wartezeiten auf die einzelnen Pakete
drinnen.)
>> Was definierst Du als grosse UUCP-Jobs? Ich habe seit Anfang dieses
>
>Eben das, was XP als "Nachricht, Fileserver, Senden" bezeichnet.
Habe ich zuletzt gestern, als ich XP 3.0 auf die Toppoint hochgeladen
habe, ohne Probleme machen können... :-)
Axel <>\/\/
-- VETO
Device by which one absolute bastard can
spoil the work of everyone else.
-- TCWF
## CrossPoint v3.0 R ##
Noses
> > Alle denkbaren Einstellunegn getestet. Der Fix brachte da auch nicht allzu
> > viel...
> Warum erfahre ich sowas immer erst zufaellig in irgendeiner Newsgroup?
Weil das Testen Deiner Software Deine Aufgabe ist? Ein Paket, das von sich
behauptet, uucp zu sprechen, sollte wenigstens mit den verbreitetsten uucp-
Implementationen zusammenarbeiten. Wenn etwas unter Standardbedingungen (i.
e. die Verbindung zwischen Modem und Rechner ist schneller als die Verbindung
zwischen den Modems) nicht mit Taylor uucp zusammenarbeitet, dann war es zu
frueh fuer die beta-Release. Und genau das ist das Problem.
> *seufz*. Also, wenn es massive Probleme gibt -> Mail an mich, mit
> moeglichst exakter Beschreibung.
Siehe oben.
> kommt es daher, dass man gewohnt ist, sich bei Problemen den Quelltext
> eines Programmes besorgen und selbst darin herumstochern zu muessen?
Wohl eher DUERFEN.
Noses.
Slam
Wie meinte *Peter Mandrella *am 23.03.94
zu *"Re: XP 2.93 / uucico-Timingprobleme"*
in "de.comm.uucp"?
>Das wundert mich schon seit Monaten: Warum gibt es im Usenet - im
>Gegensatz zu allen anderen Netzen - fast niemanden, der Fehler an den
>Programmautor meldet? Reagieren andere Leute nicht auf Bugreports? Oder
>kommt es daher, dass man gewohnt ist, sich bei Problemen den Quelltext
>eines Programmes besorgen und selbst darin herumstochern zu muessen?
Nein, der Grund einfacher: Bevor ich mich z.B. an den Autor wende, teste
ich erst einmal selbst das Programm aus. Und wenn Du daran denkst, wo da
ueberall Probleme liegen koennten, kann es schon sein, dass man eine Weile
beschaeftigt ist. Ausserdem war es wohl so, dass etliche Leute entweder
von dem Fix nix wussten und/oder auf das 3.0 gewartet haben.
Gruesse Andre
*HIGH ON HOPE!*
## CrossPoint v3.0 ##
Peter Mandrella
> Implementationen zusammenarbeiten. Wenn etwas unter Standardbedingungen (i.
> e. die Verbindung zwischen Modem und Rechner ist schneller als die
> Verbindung zwischen den Modems) nicht mit Taylor uucp zusammenarbeitet, dann
> war es zu frueh fuer die beta-Release. Und genau das ist das Problem.
Selbstverständlich habe ich es mit verschiedenen Taylor- und anderen
Gegenstellen getestet (ca. 100-200 gezielte Testanrufe, auch bei
abgeschalteter Fehlerkorrektur und mit gezieltem Provozieren von Fehlern
[hallo Martin :-]; dazu viele hundert "Normalpolls"), sowohl mit Modem/
Schnittstellen-Direktzugriff als auch mit ISDN (cFos+CAPI).
Darüberhinaus lief der uucico für ein halbes Jahr lang bei einem dutzend
Betatestern.
Peter
Olaf Titz
Peter Mandrella <pe...@xpoint.ruessel.sub.org> wrote:
> MIME-Konvertierungen muessen nur einmal und nicht bei jedem Zugriff auf
> die Nachricht erfolgen, was die Performance erhoeht. Last but not least
Minor nit: das geht auch im RFC-Format.
Olaf
--
olaf titz o ol...@bigred.ka.sub.org praetorius@irc
comp.sc.student _>\ _ s_t...@ira.uka.de LINUX - the choice
karlsruhe germany (_)<(_) uk...@dkauni2.bitnet of a GNU generation
what good is a photograph of you? everytime i look at it it makes me feel blue
Peter Mandrella
> Du kriegst den großen Job ohne weiteres durch, wenn Du die Blockgröße auf
> 512 zurücknimmst bei uucp-g. Dies verringert bei ZyXEL 16.8 und gepackten
> Batches den Durchsatz von 1950 auf 1915 cps, womit Du leben können solltest,
> bis Peter den Fehler gefunden hat. Notfalls schränkst Du Dich eben mit
> Blockgröße/DTE-Speed - Kombination auf 1850 cps ein oder so.
Die Frage ist, ob die Ursache dieses Problems überhaupt bei XP liegt.
Beispiel 1: Ich polle bei der mcd per ISDN. Solange ich beim Senden
unter 5000-6000 cps bleibe, klappt alles wunderbar. Gehe ich darüber,
dann verschluckt sich die Gegenstelle regelmäßig (d.h., sie schickt
NAKs). Das führt zu ziemlich vielen Retransmits, mit dem Effekt, daß die
effektive cps-Rate wieder unter 5000 sinkt.
Also habe ich ein wenig mit verschiedenen Optimierungen und mit der
Blockgröße experimentiert. Das Resultat war verblüffend: Ich schaffte es
zwar, der Kiste das Verschlucken abzugewöhnen - allerdings legte sie
stattdessen alle paar Datenpakete gezielte Pausen ein, sodaß die Rate
wieder auf ca. 5000 cps gedrückt wurde. Bei größeren Datenpaketen (etwas
höherer Durchsatz) wurden die Pausen länger, bei kleineren kürzer. Sieht
also fast so aus, als *wüßte* der uucico auf der anderen Seite, daß er
mit mehr als 5000cps nicht zurechtkommt, und bremste daher den
Datendurchsatz gezielt ab.
Beispiel 2: Die bei einer bestimmten Site per ISDN mit XP pollenden
Systeme haben alle das gleiche Problem, daß sie bei größeren Blöcken und
bei der üblichen Window-size von 7 beim Empfangen (nicht jedoch beim
Senden) erhebliche Probleme haben; es gibt regelmäßig checksum errors
auf XP-Seite. Diese Probleme treten völlig unabhängig davon auf, welche
ISDN-Hardware auf XP-Seite verwendet wird - sowohl bei externem ELink,
bei interner Karte mit eingebauter serieller Schnittstelle als auch bei
Karte mit CAPI+cFos.
Eine genauere Analyse ergab, daß bei größeren Fenster- und Blockgrößen
auf der Gegenseite einzelne Zeichen verschluckt werden. Jegliches
Drosseln der Übertragungsgeschwindigkeit und der
Reaktionsgeschwindigkeit, mit der XP die eingehenden UUCP-g-Pakete
bestätigt (ACK), verringert die Fehlerrate.
Zwei verschiedene Fälle, aber gleiches Problem: Der XP-uucico ist zu
schnell. Ich denke nun darüber nach, entweder eine Option "Bremsfaktor"
in XP einzubauen, mit der sich die Sende- und ACK-Geschwindigkeit des
uucico reduzieren läßt, oder aber bei wiederholt auftretenden
Übertragungsfehlern die Geschwindigkeit automatisch zu drosseln, so wie
es z.B. GSZ und BiModem machen.
Peter