🚀 go-pugleaf

In article <kilian.0676@jam.han.sub.org> kilian@jam.han.sub.org (Kilian Jacob) writes:
>Hallo,
>
>was habe folgende (Fehler-)meldungen waehrend dem Pollen zu
>bedeuten?
>
>recvd: '^PROK^@^PP' (GOTIT!)

Obiges ist wohl keine Fehlermeldung, sondern die Ausgabe vom Dillon
AmigaUUCP (bei Option -xx), wenn die Verbindung steht.

>Received sequence 6, expected 4

Hier werden wohl Packete wegen schlechter Leitung und sonst. Fehlueber-
tragung noch einmal angefordert. Hatte ich uebrigens mit meinem alten
2400er desoefteren. Seit Umstieg (besser: Aufstieg) auf Traily nie
wieder passiert.
>
>Fast immer bekomme ich darueberhinaus noch Meldungen wie
>"X.Failed ..", was mir auch nicht sonderlich viel sagt.

Protokoll-Fehler bei Uebertragung der Dateien. Siehe mal in
Dein UUspoll-Verzeichnis, da findest Du die (Dateien, nicht Fehler).
>
>Die Verbindung war im obrigen Fall 9600bps mit MNP4,
>Port speed war 38.4kbps.
>Mit meinem alten 2400er Modem habe ich nie derartige
>Meldungen bemerkt. Kann es sein, dass mein langsamer
>7.1MHz-A2000er manchmal nicht mit kommt, und deshalb
>ein Packet nicht erwischt und dieses dann nochmal vom
>anderen Rechner anfordert?
Nein, aber in Preferences hoehere Baudrate als in L.sys eingestellt und
dort auch etwas mehr Buffer gegoennt?
Gruss, Gerhard

_
Gerhard Mueller, TRICOM, Geibelstr. 14, D3000 Hannover, ECG119
Voice: +49 511 733794, Fax: +49 511 8093329, CompuServe: 100016,3017
UUCP: cbmvax.commodore.com!cbmehq!tricom!gerhard, gerhard@tricom.han.sub.org

In article <kilian.0676@jam.han.sub.org>, Kilian Jacob writes:

> Hallo,
>
> was habe folgende (Fehler-)meldungen waehrend dem Pollen zu
> bedeuten?
>
> recvd: '^PROK^@^PP' (GOTIT!)

	Das ist keine Fehlermeldung, es sagt nur, dass die beiden
uucicos sich gefunden haben.

> Received sequence 6, expected 4
> Received sequence 7, expected 4
[usw...]

	Hier sind dem g-Protokoll zwei Pakete verlorengegangen,
der uucico erwartet eines mit der Sequenznummer 4 und findet 6.
Wahrscheinlich ist (sind) in der 4 ein (oder gar mehrere) Byte(s)
verlorengegangen.  Das Paket wird weggeschmissen, weil die Pruefsumme
nicht stimmt.  Die 5 wurde nicht erkannt, weil sein Anfang als Ende
von 4 gelesen wurde.  Erst das Paket mit der Sequenznummer 6 wird
wieder erkannt, aber damit kann der uucico (bzw. das g-Protokoll)
im Moment gar nichts anfangen...

	Das ganze ist nicht tragisch (nur fuer den Durchsatz nicht
so gut).  Die Pakete werden nochmal gesendet.

> recvd: '^P^I"*^H^I^POOOOOO' (GOTIT!)

	Die uucicos verabschieden sich hoeflich.  Auch keine Fehlermeldung.

> Fast immer bekomme ich darueberhinaus noch Meldungen wie
> "X.Failed ..", was mir auch nicht sonderlich viel sagt.

	Du meinst `F.X failed'!?  Das ist auch eine Meldung des
g-Protokolls.  Der Header jedes Pakets hat eine eigene Pruefsumme,
wenn die nicht stimmt, gibt's diese Meldung.
 
> Die Verbindung war im obrigen Fall 9600bps mit MNP4,
> Port speed war 38.4kbps.
> Mit meinem alten 2400er Modem habe ich nie derartige
> Meldungen bemerkt. Kann es sein, dass mein langsamer
> 7.1MHz-A2000er manchmal nicht mit kommt, und deshalb
> ein Packet nicht erwischt und dieses dann nochmal vom
> anderen Rechner anfordert?

	Sieht so aus.  Was laeuft bei Dir? 1.3.x (x=?)?  2.0?  Das
neue serial.device sollte das eigentlich koennen.

> Gruss,
> --
> --/<ilian

	Tschuess, Gerald.

-- 
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: +49 531 796832
\X/ gm@germal.bs.open.de   "Und wenn ich w|_te, da_ morgen die Welt unterginge,
so w|rde ich doch heute mein Apfelbdumchen pflanzen"    Martin Luther zugeschr.

In article <gerhard.051p@tricom.han.sub.org> gerhard@tricom.han.sub.org (Gerhard Mueller) writes:
>>Die Verbindung war im obrigen Fall 9600bps mit MNP4,
>>Port speed war 38.4kbps.
>>Mit meinem alten 2400er Modem habe ich nie derartige
>>Meldungen bemerkt. Kann es sein, dass mein langsamer
>>7.1MHz-A2000er manchmal nicht mit kommt, und deshalb
>>ein Packet nicht erwischt und dieses dann nochmal vom
>>anderen Rechner anfordert?
>Nein, aber in Preferences hoehere Baudrate als in L.sys eingestellt und

Ich dachte die Prefs-Baudrate spielt keine Rolle (?)
Ausserdem kann dort nur bis 31.25KB eingestellt werden.

>dort auch etwas mehr Buffer gegoennt?

Habe es jetzt von 8 auf 16k hochgesetzt. Mal sehen..

Gruss,
--/<ilian

-
Kilian Jacob|Phone: +49-511-559379|E-mail: kilian@jam.han.sub.org
    "Das Junix Konto.    Man hat es.              Frau auch."

In article <qKdxr*-T1@germal.bs.open.de> gm@germal.bs.open.de (Gerald Malitz) writes:
>	Das ganze ist nicht tragisch

:-)

>(nur fuer den Durchsatz nicht so gut).

:-(

>> Fast immer bekomme ich darueberhinaus noch Meldungen wie
>> "X.Failed ..", was mir auch nicht sonderlich viel sagt.
>
>	Du meinst `F.X failed'!?  Das ist auch eine Meldung des
>g-Protokolls.	Der Header jedes Pakets hat eine eigene Pruefsumme,
>wenn die nicht stimmt, gibt's diese Meldung.

Was soll ich dann von den sequence-Fehlern, wenn dabei
_kein_ Pruefsummenfehler = Uebertagungasfehler
 (d.h. _keine_ F.X failed Meldung) auftritt?

>> Die Verbindung war im obrigen Fall 9600bps mit MNP4,
>> Port speed war 38.4kbps.
>> Mit meinem alten 2400er Modem habe ich nie derartige
>> Meldungen bemerkt. Kann es sein, dass mein langsamer
>> 7.1MHz-A2000er manchmal nicht mit kommt, und deshalb
>> ein Packet nicht erwischt und dieses dann nochmal vom
>> anderen Rechner anfordert?
>
>	Sieht so aus.  Was laeuft bei Dir? 1.3.x (x=?)?  2.0?  Das
>neue serial.device sollte das eigentlich koennen.

Ich habe noch immer 1.3. Ob das 2.0-serial.device "isoliert" auch
unter KS/WB1.3 laeuft? BTW. Was hat es mit diesem sogenannten
"BaudBandit.device" auf sich? (Habe ich mal irgendwo gelesen,
fragt sich nur wo..)


Gruss,
--
--/<ilian

-
Kilian Jacob|Phone: +49-511-559379|E-mail: kilian@jam.han.sub.org
    "Das Junix Konto.    Man hat es.              Frau auch."

In article <kilian.0782@jam.han.sub.org>, Kilian Jacob writes:

> >	Du meinst `F.X failed'!?  Das ist auch eine Meldung des
> >g-Protokolls.	Der Header jedes Pakets hat eine eigene Pruefsumme,
> >wenn die nicht stimmt, gibt's diese Meldung.
>
> Was soll ich dann von den sequence-Fehlern, wenn dabei
> _kein_ Pruefsummenfehler = Uebertagungasfehler
>  (d.h. _keine_ F.X failed Meldung) auftritt?

	Sorry, da habe ich mich nicht klar ausgedrueckt:  Jedes
Paket besteht aus einem Header aus sechs Bytes und einem Datenteil,
letzterer kann 0 Bytes lang sein (maw. fehlen).  Es gibt zwei
Pruefsummen.  Eine nur ueber die Daten, die mit einem Paket
verschickt werden.  Diese 16-Bit-Summe wird im Header des Pakets
gespeichert.  Dann gibt es noch eine 8-Bit-Pruefsumme, die
ausschliesslich fuer den Header zustaendig ist.  Wenn diese
zweite Pruefsumme falsch ist, also der Header was abgekriegt
hat (oder gar keiner war :) ) gibt's die F.X-Meldung.  Wenn
die Pruefsumme fuer die Daten nicht stimmt, wird das Paket
kommentarlos wegeworfen.

	Die "received x,expected y"-Meldungen entstehen, wenn
Pakete in der falschen Reihenfolge ankommen.  Der uucico hat
das n-te Paket erwartet und das n+1-te bekommen (weil das n-te
kommentarlos weggeworfen wurde).  Die Pakete werden aber nicht
mit n gekennzeichnet (n koennte ja beliebig gross werden),
sondern mit n modulo 8.  Dieser Wert n%8 ist die Sequenznummer,
die bei diesen Meldungen ausgegeben wird.

> Ich habe noch immer 1.3. Ob das 2.0-serial.device "isoliert" auch
> unter KS/WB1.3 laeuft?

	Ja.  Auf meiner letzten 1.3-WB (1.3.3 bzw. 34.34) ist schon
das 2.0-serial.device (37.4 vom 30.5.91), so von C= ausgeliefert.

> Gruss,
> --
> --/<ilian

	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

In article <IUvBr*M+1@germal.bs.open.de> gm@germal.bs.open.de (Gerald Malitz) writes:
>verschickt werden.  Diese 16-Bit-Summe wird im Header des Pakets
>gespeichert.  Dann gibt es noch eine 8-Bit-Pruefsumme, die
>ausschliesslich fuer den Header zustaendig ist.  Wenn diese
>zweite Pruefsumme falsch ist, also der Header was abgekriegt
>hat (oder gar keiner war :) ) gibt's die F.X-Meldung.  Wenn

Alles klar. Dann ist ja auch logisch, warum weniger F.X-Meldungen
auftreten: Die Header sind halt einfach kuerzer, als der Datenteil
der Pakete --> folglich geringere Wahrscheinlichkeit eines Ueber-
tragungsfehlers beim header im Vergleich zum Datenteil.

>> Ich habe noch immer 1.3. Ob das 2.0-serial.device "isoliert" auch
>> unter KS/WB1.3 laeuft?
>
>	Ja.  Auf meiner letzten 1.3-WB (1.3.3 bzw. 34.34) ist schon
>das 2.0-serial.device (37.4 vom 30.5.91), so von C= ausgeliefert.

Tja. Ich habe V34.28.. :-(
Ich benutze jetzt das BaudBandit.device 1.4
(wurde in zer.z-netz.rechner.amiga.binaer gepostet)
Die Fehlermeldungen tauchen weiterhin auf. Es ist moeglich,
dass deren Anzahl gesunken ist, d.h. die jetzt erscheinenden
Meldungen nur (?) auf wirkliche Leitungsstoehrungen
zurueckzufuehren sind und nicht auf das "Verschlucken" von Daten
durch meine langsame CPU, allerdings kann ich nach einem Mal Pollen
mit dem neuen device noch nicht definitiv sagen, ob dies der Fall
ist.

Was ist vorzuziehen (schneller und zuverlaessiger) fuer AmigaUUCP:
BaudBandit.device 1.4 oder serial.device 37.4?

Kann mir jemand erklaeren, was es mit den verschiedenen "Window-"
Groessen auf sich hat, und was man bei Veraenderung dieser erreichen
kann? Vielleicht kann man damit die sequence- und F.X Fehlermeldungen
beim Pollen veringern?

An welchen anderen uucico-Parametern kann man (oder koennte ich)
sonst noch herumspielen?

Gruss,
--
--/<ilian

-
Kilian Jacob|Phone: +49-511-559379|E-mail: kilian@jam.han.sub.org
    "Das Junix Konto.    Man hat es.              Frau auch."

In article <kilian.0898@jam.han.sub.org>, Kilian Jacob writes:

> >> Ich habe noch immer 1.3. Ob das 2.0-serial.device "isoliert" auch
> >> unter KS/WB1.3 laeuft?
> >
> >	Ja.  Auf meiner letzten 1.3-WB (1.3.3 bzw. 34.34) ist schon
> >das 2.0-serial.device (37.4 vom 30.5.91), so von C= ausgeliefert.
>
> Tja. Ich habe V34.28.. :-(

	Mir hat vor geraumer Zeit mein freundlicher C=-Haendler
fuer 4.40DM ein Update kopiert.  Ob das jetzt noch geht?  Es
sollte aber eigentlich nicht so schwierig sein, irgendwo ein
aktuelles serial.device aufzutreiben ;-)

> Ich benutze jetzt das BaudBandit.device 1.4
> (wurde in zer.z-netz.rechner.amiga.binaer gepostet)

	Wer schrieb denn neulich, er haette um die Bugs in diesem
Device "herumprogrammiert"?  Lutz Vieweg?  Der uucico meidet sicherlich
die Fehler im serial.device von C=, aber sonst keine.

> Was ist vorzuziehen (schneller und zuverlaessiger) fuer AmigaUUCP:
> BaudBandit.device 1.4 oder serial.device 37.4?

	Ich tippe auf 37.4

> Kann mir jemand erklaeren, was es mit den verschiedenen "Window-"
> Groessen auf sich hat, und was man bei Veraenderung dieser erreichen
> kann? Vielleicht kann man damit die sequence- und F.X Fehlermeldungen
> beim Pollen veringern?

	Nein.  Du kannst mit einer groesseren Windowsize u. U. den
Durchsatz verbessern, vorausgesetzt, Deine Gegenseite versteht das
ueberhaupt.  Probier's aus, mehr kann ich dazu von hier aus nicht
sagen.

	Mit groesseren Paketen kannst Du den Durchsatz verbessern,
ebenfalls vorausgesetzt, dass Deine Gegenseite das auch kann, was
keineswegs selbstverstaendlich ist.  Der Vorteil eines groesseren
Paketes ist der geringere Overhead.  Es wird ein Header fuer z.B.
je 256 Bytes verschickt statt fuer 64 wie bisher (also 24 Bytes
Header pro KByte Daten statt 96).  Nachteile hast Du, wenn Du viele
kleine Files verschickst.  Es werden immer nur ganze Pakete gesendet.
Auch wenn ein File nur 3 Bytes hat, werden (z. B.) 256 uebertragen
(zuzueglich Header).  Das muesste nicht so sein, ist im Dillon-UUCICO
aber nicht anders implementiert, und es wuerde in den meisten Faellen
sowieso nur zu Problemen fuehren.  Unguenstig sind grosse Pakete
natuerlich auch, wenn Fehler haeufig sind.  Du musst sehen, was bei
Dir am besten funktioniert.  Pauschale Aussagen sind nicht möglich.

> Gruss,
> --
> --/<ilian

	Tschüß, Gerald.

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

In article <kilian.1156@jam.han.sub.org>, kilian@jam.han.sub.org (Kilian Jacob) writes:
> In article <1aAFr*o32@germal.bs.open.de> gm@germal.bs.open.de (Gerald Malitz) writes:
> >In article <kilian.0898@jam.han.sub.org>, Kilian Jacob writes:
> >> Ich benutze jetzt das BaudBandit.device 1.4
> >> (wurde in zer.z-netz.rechner.amiga.binaer gepostet)
[...]
> >> Was ist vorzuziehen (schneller und zuverlaessiger) fuer AmigaUUCP:
> >> BaudBandit.device 1.4 oder serial.device 37.4?
> >
> >     Ich tippe auf 37.4
>
> Die Fehlermeldungen sind bei mir urploetzlich verschwunden, als
> ich die port speed von 38.4k auf 19.2k heruntergesetzt habe.

     Welcher Rechner  (i.  e.  680xx@xxMHz)? Zumindest bei 68000/7 und
serial  37.4  wuerde  ich  *nicht*  ueber 19k2 gehen, falls die Gefahr
besteht,  es  koennten  wirklich  mal  Daten  mit  38k4 kommen  (z. B.
unkomprimierte ASCII-Texte ueber eine V.32bis/V.42bis-Verbindung).

[...]
> >sowieso nur zu Problemen fuehren.  Unguenstig sind grosse Pakete
> >natuerlich auch, wenn Fehler haeufig sind.  Du musst sehen, was bei
>
> Da das Modem Fehlerkorrektur durchfuehrt, ist die Wahrscheinlichkeit
> eines Fehlers doch sowieso sehr gering. Also: Eigentlich sollte nichts
> gegen grosse Pakete sprechen.

     Ohoh, also,  *ich*  (wusel@hactar.hanse.de)  kann nur von Paketen
>512  Bytes  abraten  -  die Übertragungsraten sinken ... Abhängig von
der  Beschaffenheit  der  zu  übermittelnden Daten (große komprimierte
Newsbatches  vs.   viele kleine unkomprimierte Mails) hat sich bei mir
256  bzw.  128 als ideal erwiesen. 1024 jedenfalls bringt in der Regel
nur  Probleme,  vor  allem,  wenn  die  Gegenseite nur ein 68000/7 ist
(Hallo, Robert =:->) ...

> Wenn uucico keine Fehlermeldungen auf dem Bildschrim ausgibt,
> kann ich doch davon ausgehen, dass auch keine Uebertragungs-
> fehler aufgetreten sind?

Hmm, kommen die Fehlermeldungen nicht nur bei Angabe von `-xx'?
			kai

-- _
_ // Kai 'wusel' Siering, Villa Straylight, Hamburg, BRD <wusel@hactar.hanse.de>
\X/    (Heute wieder im schoenen Sietland: <hactar.hanse.de!straylight!wusel>)

"Das IN _ist_ eine Portokasse. Wir haben *nur* Mailkosten."
                  -- Kristian Koehntopp auf dem IN-Arbeitstreffen OL, 21.06.1992

In article <22Sep1992.022838.13486@straylight.uucp>, Ulf Diekmann writes:
                                                     ^^^^^^^^^^^^
Unten mit Kai unterschreiben und oben... Falscher Account, oder was?

>      Ohoh, also,  *ich*  (wusel@hactar.hanse.de)  kann nur von Paketen
> >512  Bytes  abraten  -  die Übertragungsraten sinken ... Abhängig von
> der  Beschaffenheit  der  zu  übermittelnden Daten (große komprimierte
> Newsbatches  vs.   viele kleine unkomprimierte Mails) hat sich bei mir
> 256  bzw.  128 als ideal erwiesen. 1024 jedenfalls bringt in der Regel
> nur  Probleme,  vor  allem,  wenn  die  Gegenseite nur ein 68000/7 ist
> (Hallo, Robert =:->) ...
Also ich benutze (512,7) und kann mich ueber die erreichten Uebertragungs-
raten nicht beschweren. Meine Verbindung laeuft ueber V.32bis/V.42bis
und ich erreiche maximal 1550 cps. Wenn viele kleine Files (Newsbatches
und Mails) dabei sind gehts aber schon runter. Bei Gelegenheit werd
ich mal 256 ausprobieren, kann mir aber nicht vorstellen, dass das viel
bringt. Die cps-Rate berechne ich mit einem kleinen AREXX-script aus
den Angaben ueber Online-Zeit und transferierte Bytes im UUSPOOL:timelog.
Fuer einzelne Batches sind (laut meiner Gegenstelle) ueber 1620 cps drin.
Achja, die Strecke zum Modem steht auf 38400. Mit einem NS16550AFN als UART
und  A2630 kann man sowas absolut problemlos machen...

> Hmm, kommen die Fehlermeldungen nicht nur bei Angabe von `-xx'?
Nein, zumindest auch bei -X3 kann man sowas wie sequence... und ...failed
sehen. Das kam damals, als ich noch mit V.32/none gepollt habe oefter vor.

Gerrit

-- 
         Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
  Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)
                 If you are from outer space, please use:
  universe!local-cluster!milkyway!solarsystem!terra!europe!laosinh!gerrit

In article <Ua2Mr*XH1@laosinh.stgt.sub.org> gerrit@laosinh.stgt.sub.org (Gerrit Heitsch) writes:
> In article <22Sep1992.022838.13486@straylight.uucp>, Ulf Diekmann writes:
>                                                      ^^^^^^^^^^^^
> Unten mit Kai unterschreiben und oben... Falscher Account, oder was?
>
> >      Ohoh, also,  *ich*  (wusel@hactar.hanse.de)  kann nur von Paketen
> > >512  Bytes  abraten  -  die Übertragungsraten sinken ... Abhängig von
> > der  Beschaffenheit  der  zu  übermittelnden Daten (große komprimierte
> > Newsbatches  vs.   viele kleine unkomprimierte Mails) hat sich bei mir
> > 256  bzw.  128 als ideal erwiesen. 1024 jedenfalls bringt in der Regel
> > nur  Probleme,  vor  allem,  wenn  die  Gegenseite nur ein 68000/7 ist
> > (Hallo, Robert =:->) ...
> Also ich benutze (512,7) und kann mich ueber die erreichten Uebertragungs-
> raten nicht beschweren. Meine Verbindung laeuft ueber V.32bis/V.42bis
> und ich erreiche maximal 1550 cps. Wenn viele kleine Files (Newsbatches
> und Mails) dabei sind gehts aber schon runter. Bei Gelegenheit werd
> ich mal 256 ausprobieren, kann mir aber nicht vorstellen, dass das viel
> bringt. Die cps-Rate berechne ich mit einem kleinen AREXX-script aus
> den Angaben ueber Online-Zeit und transferierte Bytes im UUSPOOL:timelog.
> Fuer einzelne Batches sind (laut meiner Gegenstelle) ueber 1620 cps drin.
> Achja, die Strecke zum Modem steht auf 38400. Mit einem NS16550AFN als UART
> und  A2630 kann man sowas absolut problemlos machen...

Das ist der ideale Einstieg zu einer Frage, welche mich schon laenge quaelt.

Besonders im `On-line-Betrieb' ist mir folgendes aufgefallen:

                       - Es gibt MailBoxen, bei denen kann ich bei einer
                         V.32bis/V.42bis mit einer DTE-Rate von 57600
                         einwandfrei arbeiten.

                       - Es gibt aber auch MailBoxen, bei denen kann ich nicht
                         einmal mit einer DTE von 38400 ohne Übertragungsfehlern
                         arbeiten. (V.32bis/V.42bis)
                         Ich muss also auf 19200 herunter!
                         Bei V.42(bis) sollte so etwas aber doch nicht sein?!

                       - Das gilt nicht nur für `On-line-Betrieb'.
                         Auch bei Fido-Boxen per TrapDoor beobachtet.
                         Mit UUcico und einer DTE von 38400 hab ich
                         bisher keine Schwierigkeiten bemerkt.

  o Eine DTE von 57600 funktioniert einwandfrei!
  o Nur bei immer den gleichen Boxen muß die DTE auf 19200 begrenzt werden.


Zum Thema: :-) (IMHO:)

  o Ist sehr von der Größe der Files abhängig.

  o Ich habe für meine Site 256 als die optimale Block-Größe ermittelt.

  o Die frage ist einfach, wie oft wird BatchNews gestartet. (Beide Sites)
      - Wenn nur einmal am Tag -> Dann 512 ( > nicht nicht probiert! )
      - Je öfter, dann sollte immer mehr 128 angestrebt werden!
      - Bei größen Files ist es wohl klar.

> > Hmm, kommen die Fehlermeldungen nicht nur bei Angabe von `-xx'?
> Nein, zumindest auch bei -X3 kann man sowas wie sequence... und ...failed
> sehen. Das kam damals, als ich noch mit V.32/none gepollt habe oefter vor.
[...]
> --
>          Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
>   Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)

DANKE für fachliche Erklärungen!

Und viel Spass beim Experimentieren. (Gibt es eigentlich ein UUcico,
                                       welches das z-Protokol unterstützt?)

    - Olaf
--
Olaf Gimmini (ECG117)
 Weitbrucher Str. 31   D-1000 Berlin 47
  UseNet: myuucp.adsp.sub.org!gimmini
          (uunet|pyramid|rutgers)!cbmvax!cbmehq!cbmger!myuucp!gimmini

In article <gimmini.02ej@myuucp.adsp.sub.org>, Olaf Gimmini writes:

>                        - Es gibt MailBoxen, bei denen kann ich bei einer
>                          V.32bis/V.42bis mit einer DTE-Rate von 57600
>                          einwandfrei arbeiten.
> 
>                        - Es gibt aber auch MailBoxen, bei denen kann ich nicht
>                          einmal mit einer DTE von 38400 ohne Übertragungsfehlern
>                          arbeiten. (V.32bis/V.42bis)
>                          Ich muss also auf 19200 herunter!
>                          Bei V.42(bis) sollte so etwas aber doch nicht sein?!
> 
>                        - Das gilt nicht nur für `On-line-Betrieb'.
>                          Auch bei Fido-Boxen per TrapDoor beobachtet.
>                          Mit UUcico und einer DTE von 38400 hab ich
>                          bisher keine Schwierigkeiten bemerkt.
> 
>   o Eine DTE von 57600 funktioniert einwandfrei!
>   o Nur bei immer den gleichen Boxen muß die DTE auf 19200 begrenzt werden.
Merkwuerdig... Auf was steht dein Puffer in den serial.prefs?
Alles ueber 16 KB wird (aufgrund eines Fehlers?) fuer 512 Bytes
gehalten und auch so benutzt. Das fuehrt zu Problemen bei hohen
Baudraten.

>   o Ich habe für meine Site 256 als die optimale Block-Größe ermittelt.
Ich hier hab 512 als optimale Groesse.

Mit meinem Newsfeed hab ich eine maximale Batchgroesse von 250 KB
ausgemacht, so sind die Files immer recht gross.

> Und viel Spass beim Experimentieren. (Gibt es eigentlich ein UUcico,
>                                        welches das z-Protokol unterstützt?)
Beim Taylor-UUCP wird das a-Protokoll unterstuetzt, es entspricht
ZModem. Also wer setzt den uucico von Taylor auf den Amiga um? ;-)

Gerrit

-- 
         Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
  Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)
                 If you are from outer space, please use:
  universe!local-cluster!milkyway!solarsystem!terra!europe!laosinh!gerrit

In article <ZLLNr*HJ1@laosinh.stgt.sub.org> gerrit@laosinh.stgt.sub.org (Gerrit Heitsch) writes:
> In article <gimmini.02ej@myuucp.adsp.sub.org>, Olaf Gimmini writes:
>
> >                        - Es gibt MailBoxen, bei denen kann ich bei einer
> >                          V.32bis/V.42bis mit einer DTE-Rate von 57600
> >                          einwandfrei arbeiten.
> >
> >                        - Es gibt aber auch MailBoxen, bei denen kann ich nicht
> >                          einmal mit einer DTE von 38400 ohne Übertragungsfehlern
> >                          arbeiten. (V.32bis/V.42bis)
> >                          Ich muss also auf 19200 herunter!
> >                          Bei V.42(bis) sollte so etwas aber doch nicht sein?!
> >
> >                        - Das gilt nicht nur für `On-line-Betrieb'.
> >                          Auch bei Fido-Boxen per TrapDoor beobachtet.
> >                          Mit UUcico und einer DTE von 38400 hab ich
> >                          bisher keine Schwierigkeiten bemerkt.
> >
> >   o Eine DTE von 57600 funktioniert einwandfrei!
> >   o Nur bei immer den gleichen Boxen muß die DTE auf 19200 begrenzt werden.
> Merkwuerdig... Auf was steht dein Puffer in den serial.prefs?
> Alles ueber 16 KB wird (aufgrund eines Fehlers?) fuer 512 Bytes
> gehalten und auch so benutzt. Das fuehrt zu Problemen bei hohen
> Baudraten.

Das wars! - Nach zwei kurzen Tests.
Bei DTE von 38400 hatte ich bei beiden Boxen keine Probleme mehr. :-)
Die Puffergroeße war natuerlich auf 32k gestellt.
Jetzt 16k.

Kleine Ursache große Wirkung!

Ich kann nur sagen: `DANKE für den Tip!' :-)

> --
>          Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
>   Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)

 Gruss   - Olaf
--
Olaf Gimmini (ECG117)
 Weitbrucher Str. 31   D-1000 Berlin 47
  UseNet: myuucp.adsp.sub.org!gimmini
          (uunet|pyramid|rutgers)!cbmvax!cbmehq!cbmger!myuucp!gimmini

In article <Ua2Mr*XH1@laosinh.stgt.sub.org>, gerrit@laosinh.stgt.sub.org (Gerrit Heitsch) writes:

% In article <22Sep1992.022838.13486@straylight.uucp>, Ulf Diekmann writes:
%                                                      ^^^^^^^^^^^^
% Unten mit Kai unterschreiben und oben... Falscher Account, oder was?

     Jaja, das  kommt  davon,  wenn  der  Unterschied  nur  in  einem `set'
besteht   =:->   =:-<   Hatte  aber  keine  Lust  mehr,  das  nachtraeglich
rauszuhacken, als ich gemerkt hatte ...

% >      Ohoh, also,  *ich*  (wusel@hactar.hanse.de)  kann nur von Paketen
% > >512  Bytes  abraten  -  die Übertragungsraten sinken ... Abhängig von
% > der  Beschaffenheit  der  zu  übermittelnden Daten (große komprimierte
% > Newsbatches  vs.   viele kleine unkomprimierte Mails) hat sich bei mir
% > 256  bzw.  128 als ideal erwiesen. 1024 jedenfalls bringt in der Regel
% > nur  Probleme,  vor  allem,  wenn  die  Gegenseite nur ein 68000/7 ist
% > (Hallo, Robert =:->) ...
% Also ich benutze (512,7) und kann mich ueber die erreichten Uebertragungs-

[Mit ebenfalls einem A2500/30 unter 2.04, Anm. d. red. =:->]

% raten nicht beschweren. Meine Verbindung laeuft ueber V.32bis/V.42bis
% und ich erreiche maximal 1550 cps. Wenn viele kleine Files (Newsbatches
% und Mails) dabei sind gehts aber schon runter. Bei Gelegenheit werd
% ich mal 256 ausprobieren, kann mir aber nicht vorstellen, dass das viel
% bringt. Die cps-Rate berechne ich mit einem kleinen AREXX-script aus
% den Angaben ueber Online-Zeit und transferierte Bytes im UUSPOOL:timelog.

     Ich ziehe   zum   einen   die   per-Job-Daten,  die  der  von  Henning
Schmiedehausen  geänderte  uucico  1.15  zusaetzlich nach `uuspool:LOGFILE'
schreibt  (imho  ein  sinnvolles  Feature =:->), zum anderen die Werte, die
`uuspool:xferstat'  verzeichnet;  jene  hauptsaechlich,  ist daraus ja auch
ersichtlich,  ob z. B. Probleme bestehen (lahme Platte und/oder viele Files
im spooldir, Uebertragungsfehler) ...

Beispiel (alles V.32bis/V.42bis-Verbindungen):

< castle   09-10-92 03:10:11 > 09-10-92 03:13:10 (00:02:59)  1287   1151  89%
| G 7  128    11936   218448 #        0   206180 #    0    6
< abqhh    09-10-92 04:01:38 > 09-10-92 04:27:04 (00:25:26)  1637   1366  83%
| g 7   64  2110251   388039 #  1901718   183873 #   34   10
< genius   09-10-92 04:31:16 > 09-10-92 04:40:28 (00:09:12)  1263   1107  87%
| G 7  128   340377   356996 #   301125   310016 #   10   16

Gehen  ich/genius  z.  B.  auf >128 Byte/Paket, sinkt die Uebertragungsrate
drastisch (genius ist ein A2000/000).

% Fuer einzelne Batches sind (laut meiner Gegenstelle) ueber 1620 cps drin.

     Nunja, laut  den  per-Job-Daten hatte ich heute morgen zu wolfhh z. T.
>1700 cps - `xferstat' hingegen sagt:

> wolfhh   09-10-92 06:44:31 > 09-10-92 06:52:41 (00:08:10)  1158    897  77%
| g 7   64    56295   511504 #     7987   431957 #    6   36

Die  Werte,  die  die UNOX-Accountingprogramme melden, liegen meist 100 bis
200 cps ueber denen, die ich ausrechne ...

% Achja, die Strecke zum Modem steht auf 38400. Mit einem NS16550AFN als UART
% und  A2630 kann man sowas absolut problemlos machen...

     Bei mir  ebenso;  bis gestern mit der internen seriellen, seit gestern
abend  haengt  das Modem (endlich hab' ich mich aufgerafft =:->) allerdings
an  Friedrich  Genters/Henning Schmiedehausens seriellem Kaertchen (`Vector
Connection');  ob  sich  das  jetzt  positiv oder negativ auf den Durchsatz
auswirkt,  kann  ich  verstaendlicherweise  noch nicht sagen (will heiszen:
keine unerwarteten Werte bislang). Modem: USR DHST.

Wie gesagt, mein Erfahrungen - your mileage may vary,
			kai

--  _
 _ //   Kai 'wusel' Siering, Villa Straylight, Hamburg, Germany. Go for MIME!
 \X/: <wusel@hactar.hanse.de> Exile: <wusel@lime.in-berlin.de> iso-8859-1: äöüß

"Das  Schicksal  beschuetzt  Narren,  kleine  Kinder ... und Raumschiffe mit dem
Namen `Enterprise'."         -- William Riker, "Star Trek - The Next Generation"

In article <09Oct1992.201331.169533@hactar.hanse.de>, Kai 'wusel' Siering writes:

> Gehen  ich/genius  z.  B.  auf >128 Byte/Paket, sinkt die Uebertragungsrate
> drastisch (genius ist ein A2000/000).
Kann eigentlich nicht sein... ibase ist ein A2000/010 und dort liegt
das Maximum auch bei (512,7). Hat genius die Windowsize auf 7
eingestellt?

> % Fuer einzelne Batches sind (laut meiner Gegenstelle) ueber 1620 cps drin.
> Die  Werte,  die  die UNOX-Accountingprogramme melden, liegen meist 100 bis
> 200 cps ueber denen, die ich ausrechne ...
Die Gegenstelle ist ein NeXT mit Taylor-UUCP 1.03. Er rechnet den
Wert fuer jeden Batch einzeln aus und da meine Batches meist so
um die 250 KB haben kann das ganz gut sein.

>      Bei mir  ebenso;  bis gestern mit der internen seriellen, seit gestern
> abend  haengt  das Modem (endlich hab' ich mich aufgerafft =:->) allerdings
> an  Friedrich  Genters/Henning Schmiedehausens seriellem Kaertchen (`Vector
> Connection');  ob  sich  das  jetzt  positiv oder negativ auf den Durchsatz
> auswirkt,  kann  ich  verstaendlicherweise  noch nicht sagen (will heiszen:
> keine unerwarteten Werte bislang). Modem: USR DHST.
Wenn da ein 16550 oder ein anderer Chip mit FIFO drauf ist, dann reduziert
das auf jeden Fall den Interrupt Overhead, aber der Durchsatz erhoeht sich
im Normalfall nicht, nur treten keine Fehler mehr auf. Ich hab meinen FIFO auf 
einem Triggerlevel von 8, d.h. es werden immer 8 Bytes am Stueck abgeholt.
Erzaehl mal genaueres ueber die Karte, was fuer eine Hardware wird benutzt,
laeuft das device problemlos mit allen Programmen, wieviele
Schnittstellen hat die Karte, usw...

Hast du noch immer deinen A2090?

Gerrit

-- 
         Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
  Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)
                 If you are from outer space, please use:
  universe!local-cluster!milkyway!solarsystem!terra!europe!laosinh!gerrit

In article <gimmini.02g3@myuucp.adsp.sub.org>, Olaf Gimmini writes:

> Das wars! - Nach zwei kurzen Tests.
> Bei DTE von 38400 hatte ich bei beiden Boxen keine Probleme mehr. :-)
> Die Puffergroeße war natuerlich auf 32k gestellt.
> Jetzt 16k.
> 
> Kleine Ursache große Wirkung!
Eben... Wie siehts eigentlich bei den Leuten aus, die ohne GVPPatch
nicht leben koennen? Vielleicht koennte man GVPPatch durch das Runtersetzen
des Puffers ueberfluessig machen. Man glaubt gar nicht, wieviele Leute
den Puffer auf mehr als 16 KB haben und sich dann ueber Fehler beim
Download beschweren.

> Ich kann nur sagen: `DANKE für den Tip!' :-)
Keine Ursache, das ist mein Standard-Tip, wenn jemand Probleme
mit dem seriellen Port hat und nicht mehr weiterweiss.

> Olaf Gimmini (ECG117)
                ^^^^^^
Du als Entwickler muesstest das doch wissen, oder?

Gerrit

-- 
         Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
  Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)
                 If you are from outer space, please use:
  universe!local-cluster!milkyway!solarsystem!terra!europe!laosinh!gerrit

In article <TFqPr*tM1@laosinh.stgt.sub.org> gerrit@laosinh.stgt.sub.org (Gerrit Heitsch) writes:
>                 ^^^^^^
> Du als Entwickler muesstest das doch wissen, oder?

Als Entwickler liest man auch nicht alles, dazu reicht die Zeit einfach nicht.
Besonders, wenn Englisch nicht die Muttersprache ist. ;-)

>
> --
>          Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
>   Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)

--
Olaf Gimmini (ECG117)
 Weitbrucher Str. 31   D-1000 Berlin 47
  UseNet: myuucp.adsp.sub.org!gimmini
          (uunet|pyramid|rutgers)!cbmvax!cbmehq!cbmger!myuucp!gimmini

In article <Go+Or*gM1@laosinh.stgt.sub.org>, gerrit@laosinh.stgt.sub.org (Gerrit Heitsch) writes:

% In article <09Oct1992.201331.169533@hactar.hanse.de>, Kai 'wusel' Siering writes:
%
% > Gehen  ich/genius  z.  B.  auf >128 Byte/Paket, sinkt die Uebertragungsrate
% > drastisch (genius ist ein A2000/000).
% Kann eigentlich nicht sein... ibase ist ein A2000/010 und dort liegt
% das Maximum auch bei (512,7). Hat genius die Windowsize auf 7
% eingestellt?

Wie gepostet:

< genius   14-10-92 04:30:45 > 14-10-92 04:39:34 (00:08:49)  1153   1019  88%
| G 7  128   497975   112490 #   461168    77987 #   24    6

Bei  1024er  Paketen  brach die Verbindung heute um 18 Uhr nach kurzer Zeit
ab ...

% >      Bei mir  ebenso;  bis gestern mit der internen seriellen, seit gestern
% > abend  haengt  das Modem (endlich hab' ich mich aufgerafft =:->) allerdings
% > an  Friedrich  Genters/Henning Schmiedehausens seriellem Kaertchen (`
% >           ');  ob  sich  das  jetzt  positiv oder negativ auf den Durchsatz
% > auswirkt,  kann  ich  verstaendlicherweise  noch nicht sagen (will heiszen:
% > keine unerwarteten Werte bislang). Modem: USR DHST.
% Wenn da ein 16550 oder ein anderer Chip mit FIFO drauf ist, dann reduziert
% das auf jeden Fall den Interrupt Overhead, aber der Durchsatz erhoeht sich
% im Normalfall nicht, nur treten keine Fehler mehr auf. Ich hab meinen FIFO auf
% einem Triggerlevel von 8, d.h. es werden immer 8 Bytes am Stueck abgeholt.
% Erzaehl mal genaueres ueber die Karte, was fuer eine Hardware wird benutzt,
% laeuft das device problemlos mit allen Programmen, wieviele
% Schnittstellen hat die Karte, usw...

     Man hat  mir  soeben  einen  Newsmaulkorb verpaszt (jaja, ich und mein
Plappermaul  =:->),  frag'  mich  nach  dem Test der Karte in der A+ wieder
=:->  Werde  nachher noch ein Nullmodemkabel zwischen DU1: und SER: stecken
und  damit  ein wenig rumexperimtieren (AXSh, DNet, mal sehen, was ich noch
so finde) ...

% Hast du noch immer deinen A2090?

Freilich, sogar den mit dem `A' hinten =:-> Warum?
			kai

--  _
 _ //   Kai 'wusel' Siering, Villa Straylight, Hamburg, Germany. Go for MIME!
 \X/: <wusel@hactar.hanse.de> Exile: <wusel@lime.in-berlin.de> iso-8859-1: dv|_

"Das  News2Mail-Skript ist ein awk-Skript ..." - "Es koennte schlimmer sein: ein
amk-Skript :-)" -- Matthias Scheler, Henning Schmiedehausen, Bielefeld, 13.09.92

In article <01Nov1992.233545.185898@hactar.hanse.de>, Kai 'wusel' Siering writes:

>      Meine Programme  (sendmail,  uux, uuxqt, ...) basieren alle auf 1.15er
> Sourcen,  insbes.  auf den 1.15-Lockingmechanismen; und da m. W. der 1.16er
> getty/uucico  keinerlei  Vorteile bringt und mein System ausreichend stabil
> läuft: never change a winning team =:->  Mein `uuacct' wertet das xferstat-
> File  (SWB-Format;  ich  glaube,  es gab/gibt auch ein anderes?) des uucico
> 1.15c/1.16a  aus,  das timelog-File habe ich bloß noch nicht gelöscht, weil
> ich den Platz nicht brauche ...
Einen Vorteil hat der uucico 1.16, das timelog, das er schreibt
hat ein besseres Format, sonst kann ich aber auch keinen Unterschied zum
uucico 1.15 feststellen.

Gerrit

-- 
         Gerrit Heitsch  Moenchweg 16  7038 Holzgerlingen  Germany
  Logical adresses: UUCP: gerrit@laosinh.stgt.sub.org FIDO: (2:247/706.9)
If we will ever be visited by Aliens, it will be very hard to explain, why a
 lifeform, that is intelligent enough to build atomic weapons can be stupid
   enough to do it. (taken from GEO special about space, page 88-91)