Xref: utzoo can.uucp:92 news.admin:6662
Newsgroups: can.uucp,news.admin
Path: utzoo!telly!robohack!woods
From: woods@robohack.uucp (Greg A. Woods)
Subject: Re: Warp speed Mr. Scott!
Message-ID: <1989Aug29.130347.10673@robohack.uucp>
Summary: UUCP map data may be warped, due to poor use of "costs".
Reply-To: woods@robohack.UUCP (Greg A. Woods)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
References: <1989Aug21.124002.11054@robohack.uucp> <1059@aurora.AthabascaU.CA>
Date: Tue, 29 Aug 89 13:03:47 GMT

In article <1059@aurora.AthabascaU.CA> lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) writes:
> [ Followups are in news.admin ... ]

Which didn't work too well, I had to chop news.config from the
Newsgroups line.  :-)

> I was going to bring this up a while ago, but thought "it's not that big
> of a problem."  The following posting made me change my mind.

I nearly started a discussion on this topic a long while back (2 years
or so) as well.

> In article <1989Aug21.124002.11054@robohack.uucp> woods@robohack.UUCP (Greg A. Woods) writes:
> >#N	robohack
> [ ... ]
> >#	NOTE:  I've used DEDICATED to mean those sites who's mail is
> >#	delivered immediately, and DIRECT for those queued 'til the next
> >#	uudemon.hour run.
> 
> It seems to me that everyone has assigned their own arbitrary
> definitions to DIRECT, DEMAND, HOURLY, etc., that bear no relation
> to the definitions in the README file posted to comp.mail.maps.
> In particular, everyone seems to use DIRECT when in fact they
> should be using HOURLY. I recently scanned through the
> Canadian maps, and found this to be the case for about 85% of
> the sites I am familiar with. It turns out that the "well connected"
> sites (using Gene Spafford's definition) are the most likely to be
> guilty of this practise.

Most of my connections are what one would philosophically call
DEMAND.  I guess with respect to the README, they are DIRECT.

First off, my uucp polling scheme has no concept of hourly (in the
bigger picture).  Second, with respect to mail delivery, my system
will attempt to punch through on a tight polling schedule once work is
queued to go.  For the best rated sites this is every 20 mins.
Remember that with HDB, work cannot be queued till the next regular
poll (without adjusting the time field in Systems), but is only queued
until the next run of uusched.  If you look at my map entry, you will
find one site labeled HOURLY, and that's 'cause they call me at least
once per hour except from 9 to 5, but do not accept calls.

In order to fudge my paths generation, I want some sites to be a bit
less than DEMAND.  Perhaps DAILY/4 or EVENING/2 or something would
have been closer.  The problem turns out to be a conflict between both
the real world and the README, and between the README and smail2.5.  I
suppose I could change the #define in smail such that mail will only
be queued with a cost of HOURLY or more (i.e. >=500), but that would
also be misleading.  All in all, I have achieved the desired result in
my own pathalias output, and that's what counts, no?  :-)

> The result is, I'm starting to see some sub-optimal paths being
> generated. Take the case where 'a' and 'b' both claim DIRECT
> connections to 'c', and 'mysite' consider 'a' and 'b' to be HOURLY
> links. There is a 50% chance that pathalias will generate a route
> through either of 'a' or 'b' on the way to 'c'. As it turns out,
> the b!c link is a truly DIRECT connection, whereas a!c is in fact
> an HOURLY call. You get the idea ...

Of course this would be easy if we all used the same definitions.
However, what I'm saying, both here, and by explicitly commenting upon
my actions in my map entry, is that the definitions are no longer
sufficient.  They are also very misleading, unless you also read the
numbers.  In fact, if you use the definition of cost:  "measured very
roughly in elapsed time"; the costs I have defined in my map are more
than likely very nearly right, if not pessimistic, except for
adjustments made manually to keep the load down on certain links.

There have always been sub-optimal paths generated from the map data,
no matter where you are, unless you connect to 1/2 the known universe.
-- 
						Greg A. Woods

woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET}
+1-416-443-1734 [h]	+1-416-595-5425 [w]	Toronto, Ontario;  CANADA