Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!hellgate.utah.edu!cs.utexas.edu!uunet!mnetor!tmsoft!robohack!woods From: woods@robohack.uucp (Greg A. Woods) Newsgroups: news.admin Subject: Re: Warp speed Mr. Scott! Summary: Perhaps everyone should re-read the README? Message-ID: <1989Sep6.004958.29593@robohack.uucp> Date: 6 Sep 89 00:49:58 GMT References: <1989Aug21.124002.11054@robohack.uucp> <1059@aurora.AthabascaU.CA> <1989Aug29.130347.10673@robohack.uucp> <3924@ditka.UUCP> Reply-To: woods@robohack.UUCP (Greg A. Woods) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Lines: 83 [ I apologize in advance for the amount of quoting in this article, but there's a fair bit of mis-information in this discussion, and I want to make it clear who is saying what. ] In article <3924@ditka.UUCP> kls@ditka.UUCP (Karl Swartz) writes: > In article <1989Aug29.130347.10673@robohack.uucp> woods@robohack.UUCP (That's ME!) writes: > > 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. > > Why would that be misleading? That's what I've done here on ditka > and it works just fine. Ditka's actions follow what one would > expect from the map data given the published cost definitions (and > not some I made up). How might that be misleading? What would (is) be misleading would be (is) the fact that the behavior of my (your) smail does not reflect my (your) declared 'costs'. In my case it's misleading anyway, because of the way I schedule uucp jobs to try every 20 minutes best case, and every 40 minutes worst case. (HDB uucp, with retry times between 10 and 30 minutes, and with uusched running every 20 minutes.) (I've already said this, but it didn't seem to sink in.) I am collecting some data in order to graph the throughput of my system. At any rate, I think I've made a fair guess as to the through-put and capacity of my system. > > All in all, I have achieved the desired result in > > my own pathalias output, and that's what counts, no? :-) > > Not if you screw up other sites in the process. I haven't screwed up anyone, except perhaps myself. Should I declare a connection between two well connected, commonly used sites, my wee 2400 bps. modem might just get swamped. > > They are also very misleading, unless you also read the numbers. > > For some values, yes. HOURLY does not strike me as begin rougly > four times as fast as EVENING, for example. But for the lower > costs the values seem fairly reasonable to me. > > > 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 > > Nonsense. Quite a few sites (properly) use DEDICATED for links > over the Internet. By your (mis) use of DEDICATED to represent > on-demand dial up links are you suggesting that these are as > fast as a leased T1 or similar line? With the possible exception > of some extremely slow cases it just isn't so. If you'd read the README, you'd find the costs have been artificially increased by a large factor to account for an assumed delay in setting up a connection. The cost has very little to do with transmission speeds, as you'd know if you had noted the adjustments made by HIGH, LOW, and FAST are almost insignificant. In my case the "cost" (in terms of time delayed) of setting up a connection is actually quite low. Of course when the cost of making a connection drops to nil (as I believe it will in the future), as well as the increasing volume of traffic we will no doubt experience, the speed of transmission will become one of the major factors in determining route costs. By this time the routing will hopefully be a function of the network, not the transfer agent. I've made a _very_ rough guess as to the average elapsed time when mailing through my system. I will continue to adjust my published costs published as further statistics are available, since my modem usage will continue to vary in the future. I have taken a stand in this issue by publishing my map with an explanation of my actions. I had hoped this would provoke a discussion, as it indeed has. I hope the final result will be a re-evaluation of the definition of costs for published connections. (Are you listening Peter (assuming you still have interests in pathalias)?) The networks now in use, and the vast increase in numbers of point to point connections, not to mention the order of magnitude increase in sites, paints a dramatically different picture of "USENET" than was envisioned only a few years ago. -- 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