david@csource.oz.au (david nugent) (12/30/90)
I'm using a HDB flavour uucp under Interactive Unix Sys V R3.2. Does anyone know of a way I can change the "time between retries" that uucico uses? It seems to use some algorithm which increases the time on each retry, but for various reasons I need to tune this a little, since my host can get a little busy at times. A fixed retry rate would work somewhat better than what's occuring now. The result is a very "lumpy" news and mail flow, which incurs some unnecessary overhead when a large inflow hits. Right now, I have a cron event set to delete /usr/spool/uucp/.Status/<site> right before the poll event, but this seems somewhat kludgy. What is the algorithm used anyway? If this CAN be changed, are there any other "interesting" things I can do to tune uucico? Also, if anyone has any experience with running fas (I'm using 1.06) on a dial/in dial/out line, I'd be interested in hearing from you. This system has a "quirk" in that uucp sessions occur to a remote system via a direct line to an MS-DOS system (it's COM2) with the trailblazer on it's COM1 - the MS-DOS system acts as a serial bridge. The result is that carrier is never present on the line running to the Unix system, and fas seems to indicate a "line lost - error 0" and uucico aborts just after it succeeds at logging in (I suspect at the point the dial script ends). I thought of fiddling with the serial cable and bridge software to raise the appropriate signal (link DTR or DCD for example), but since this bridge works fine as is with the standard Interactive drivers, and not with fas, I'm not completely sure that's the problem. Funny thing is, uucico sessions using the modem connected directly work just fine with either driver. However, I do need to run fas, since I'll be using other protocols (namely ZModem) on the Unix sytem in the near future with the modem connected directly, and I need hardware flow control which the standard drivers don't support. Thanks in advance, david
david@bacchus.esa.oz.au (David Burren [Athos]) (12/31/90)
In <772@csource.oz.au> david@csource.oz.au (david nugent) writes: >I'm using a HDB flavour uucp under Interactive Unix Sys V R3.2. >Does anyone know of a way I can change the "time between retries" that >uucico uses? It seems to use some algorithm which increases the time >on each retry, but for various reasons I need to tune this a little, >since my host can get a little busy at times. A fixed retry rate would >work somewhat better than what's occuring now. The result is a very >"lumpy" news and mail flow, which incurs some unnecessary overhead when >a large inflow hits. The time field in the Systems file has an optional "retry" subfield. daytime[;retry][/grade] Retry specifies the number of mintes before retrying a failed attempt. According to the SunOS 4.1 (which uses HDB) documentation: In the absence of the ;retry entry, an exponential backoff algorithm is used (starting with a default wait time that grows larger as the number of failed attempts increases). The initial retry time is 5 minutes, and the maximum retry time is 23 hours. If ;time is specified, that will always be the retry time. Otherwise, the backoff algorithm is used. >If this CAN be changed, are there any other "interesting" things I can >do to tune uucico? Read the documentation and find out. You can specify a maximum grade of file to send, what UUCP protocol to use, etc. _____________________________________________________________________________ David Burren [Athos] Email: david@bacchus.esa.oz.au Software Development Engineer Phone: +61 3 819 4554 Expert Solutions Australia, Hawthorn, VIC
dag@esleng.uucp (David A. Gilmour) (01/03/91)
In article <772@csource.oz.au> david@csource.oz.au (david nugent) writes: > >I'm using a HDB flavour uucp under Interactive Unix Sys V R3.2. > >Does anyone know of a way I can change the "time between retries" that >uucico uses? It seems to use some algorithm which increases the time >on each retry, but for various reasons I need to tune this a little, >since my host can get a little busy at times. A fixed retry rate would >work somewhat better than what's occuring now. The result is a very >"lumpy" news and mail flow, which incurs some unnecessary overhead when >a large inflow hits. > To change the retry limitations you must specify the retry time in the Systems file. For example: nodename Any;5 ACU 19200 5551212 in:--in: anonuucp ^ specifies a fixed minimum retry period of 5 minutes. See section 10.8.3 of the "Interactive Unix System Maintenance Procedures - Version 2.2" for details. The Nutshell book, "Managing UUCP and Usenet" says that HDB uses an exponential retry scheme, starting with 5 minutes and growing larger as the number of un- successful attemps increases. The retry field overrides this. Hope this helps. -- __________________________________________________________________________ David A. Gilmour | Excalibur Systems Limited | uunet!mitel!cunews!micor!esleng!dag Kanata, Ontario, Canada |
bruce@bmhalh.UUCP (Bruce M. Himebaugh) (01/08/91)
In article <1991Jan03.145743.10921@esleng.uucp] dag@esleng.uucp (David A. Gilmour) writes: ]In article <772@csource.oz.au> david@csource.oz.au (david nugent) writes: ]> ]>I'm using a HDB flavour uucp under Interactive Unix Sys V R3.2. ]> ]>Does anyone know of a way I can change the "time between retries" that ]>uucico uses? It seems to use some algorithm which increases the time ] ]To change the retry limitations you must specify the retry time in the ]Systems file. For example: ] ] nodename Any;5 ACU 19200 5551212 in:--in: anonuucp ] ^ ]specifies a fixed minimum retry period of 5 minutes. This works, with the exception that you can't specify less than 5 minutes, at least on SCO Xenix. If do try to specify less than 5 minutes, it raises it back up to 5. I don't know if this is the case on all *nix's, but just in case... Bruce -- Bruce M. Himebaugh bruce@bmhalh.UUCP Voice: 216-484-3528 PATHS: uunet!{ncoast,aablue}!fmsystm!mrsmouse!bmhalh!bruce (NOTE: the system name "fmsystm" is with no "e", NOT "fmsystem")
larry@nstar.rn.com (Larry Snyder) (01/09/91)
david@csource.oz.au (david nugent) writes: >Does anyone know of a way I can change the "time between retries" that >uucico uses? It seems to use some algorithm which increases the time have you tried placing a ;30 after ANY in the Systems file (this will tell uucico to wait 30 minutes before calling again) -- Larry Snyder, NSTAR Public Access Unix 219-289-0282 (HST/PEP/V.32/v.42bis) regional UUCP mapping coordinator {larry@nstar.rn.com, ..!uunet!nstar!larry, larry%nstar@iuvax.cs.indiana.edu}
snoopy@sopwith (Snoopy) (01/13/91)
In article <88@bmhalh.UUCP> bruce@bmhalh.UUCP (Bruce M. Himebaugh) writes: |In article <1991Jan03.145743.10921@esleng.uucp] dag@esleng.uucp (David A. Gilmour) writes: |] |] nodename Any;5 ACU 19200 5551212 in:--in: anonuucp |] ^ |]specifies a fixed minimum retry period of 5 minutes. | |This works, with the exception that you can't specify less than 5 minutes, at |least on SCO Xenix. If do try to specify less than 5 minutes, it raises it |back up to 5. I don't know if this is the case on all *nix's, but just in |case... 4.3 BSD will honor 1 minute. As it should. Unix is supposed to do what you tell it to. SCO is broken. _____ /_____\ Snoopy /_______\ cse.ogi.edu!sopwith!snoopy |___| sun!nosun!qiclab!sopwith!snoopy |___| uunet!tektronix!nosun!qiclab!sopwith!snoopy
guy@auspex.auspex.com (Guy Harris) (01/18/91)
>>> This works, with the exception that you can't specify less than >>> 5 minutes, at least on SCO Xenix. If do try to specify less than >>> 5 minutes, it raises it back up to 5. >> 4.3 BSD will honor 1 minute. As it should. Unix is supposed to >> do what you tell it to. SCO is broken. > >More than likely, SCO Xenix *is* doing what he tells it to -- with a >bit more exactness than he wants. Perhaps; nevertheless, the behavior described above, namely setting a lower limit on retries to 5 minutes (at least in some cases), is a standard "feature" of the UUCP that comes with System V Release 3 and S5R3.1, and perhaps with earlier versions. The code quite explictly sets the time to 300 seconds if it's less than 300 seconds.... So it's not unique to SCO Xenix, and the SCO Xenix UUCP, if it inherited that "feature" from some flavor of AT&T UUCP, isn't doing what he tells it to. (I forget whether this "helpful" "feature" was in the S5R3.2 UUCP upon which the SunOS 4.1 UUCP was based, or, if it was, whether we ripped it out.)
guy@auspex.auspex.com (Guy Harris) (01/18/91)
>Beware: Not all UUCP's know how to handle the "maximum-grade" option, >they just send everything. And note that, while the SunOS 4.1 UUCP has the "/grade" option: 1) it was *not* in the S5R3.2 UUCP from which the 4.1 UUCP is derived; we shoveled in a whole bunch of Peter Honeyman's changes into the S5R3.2 HDB, including that feature. 2) there is a bug in the 4.3BSD UUCP's negotiation of maximum grades, triggered by the way HDB with the Honeyman changes negotiates the grade, that may cause the feature not to work fully if a 4.3 site is communicating with a SunOS 4.1 site. 1) means "don't treat the SunOS 4.1 manual as a generic guide to all HDB UUCP's; we added a bunch of stuff from Honeyman, some stuff from 4.3BSD, and some stuff of our own" ("we" being Sun). 2) means that if you're running 4.3BSD/4.3-tahoe/4.3-reno UUCP and have source, you may want to patch "cico.c". The bug is that two ways for one side to tell the other what its idea of MaxGrade is in one of the initial messages. One is with the string "-pG", where "G" is the maximum grade; the other is with "-vgrade=G". The HDB one sends out only "-vgrade=G"; the 4.3 one sends out both "-pG" and "-vgrade=G". Unfortunately, the "-vgrade=" parsing code in 4.3's UUCP is broken; if it talks to a 4.3 site, this doesn't cause a problem, as the "-p" option sets the MaxGrade correctly, but if it talks to an HDB site that has MaxGrade support, it may not get the right MaxGrade value. The buggy code is: case 'v': if (strncmp(p, "grade", 5) == 0) { p += 6; MaxGrade = DefMaxGrade = *p++; DEBUG(4, "MaxGrade set to %c\n", MaxGrade); } break; and it should be changed to something like: case 'v': if (strncmp(++p, "grade=", 6) == 0) { p += 6; MaxGrade = DefMaxGrade = *p++; DEBUG(4, "MaxGrade set to %c\n", MaxGrade); } break; (I.e., at the time the "strncmp" is done, the pointer points at the "v" in "-vgrade=", not at the "g". The extra check for the equal sign is pure anal-retentiveness. :-)) (Yes, this bug has been reported to Berkeley. The suggestion that HDB send both a "-p" and a "-vgrade=" to the remote site, in case it's running a broken 4.3 UUCP, has been forwarded to Peter Honeyman and to the appropriate person at Sun.) If you don't have source, an appropriate binary patch is left as an exercise to the reader.
guy@auspex.auspex.com (Guy Harris) (01/21/91)
>Mine doesn't. What is `maximum-grade'?
A mechanisms that says "during these times of the day, don't transmit
UUCP jobs with a grade 'worse' than some particular grade". The SunOS
4.1 UUX(1C) manual page nonwithstanding, "0" seems to be the "best" grade
and "z" seems to be the "worst" grade.
Originally, all the grade of a job did was to specify when it should be
transmitted in a UUCP session; better-grade jobs were transmitted before
worse-grade jobs.
Various versions of UUCP (4.3 or so BSD, some HDB versions done by Peter
Honeyman, but *NOT* the version in S5R3.2 or earlier from AT&T) added
the "maximum grade" mechanism to tell the system that it shouldn't
transmit lower-grade jobs *at all* at certain times.
The grade can be specified with the "-g" flag to the "uucp" command, and
on later versions of UUCP with the "-g" flag to the "uux" command.
For example, mail might be assigned a grade somewhere around "A", while
netnews might be assinged a grade somewhere around "d". This will, at
minimum, make sure that if both mail and news is queued for a given
site, when a UUCP session is started with that site, the mail will get
sent first. With the "maximum-grade" mechanism, you can arrange that
the news won't get transferred *at all* during the day, but still pick
up mail.
Two sites both supporting this option are supposed to exchange their
notion of the correct maximum grade; I think the calling site sends the
notion of "maximum grade" it got from the "L.sys" or "Systems" file, and
that becomes the maximum grade for both sites. Unfortunately, the bug I
mentioned earlier may prevent this from working, and if one of the sites
doesn't know about the "maximum grade" option, it will send all jobs it
has queued up, not just the ones with the right grades.