henry@utzoo.uucp (Henry Spencer) (08/11/89)
I recently sent the following to our Trailblazer-equipped neighbors, and dialup congestion is now noticeably less common here. It occurred to me that others might be interested as well: --------- [Original addressees] get news from us, and have Trailblazer links for it. Utzoo's uucp throughput at 2400 baud these days is unfortunately not very good; it's not much faster than 1200, probably because of Sun's scummy ALM-1 multiplexor getting in the way. Now, consider the following two scenarios, which start simultaneously: Site A tries to call utzoo with its Trailblazer. Call fails, say because zoo's fast lines are busy. So site A falls back to 2400 and calls zoo again. This time the call succeeds, either because zoo does have a slow line free or (worse) because the fast line got freed up and A is now coming in at 2400 baud on a Trailblazer line. Effective transfer rate is now about 130 cps, so A stays on the line for a long time transferring news. Site B tries to call utzoo with its Trailblazer. Call fails, say because zoo's fast lines are busy. Site B does not try to fall back; it's PEP or nothing for them. They try again an hour later, and get through. Effective transfer rate is maybe 1000 cps. (I don't have actual numbers for this one on hand, but that's probably not far wrong.) How long does it take before site B has transferred more data than site A, despite A's one-hour head start? About nine minutes. Waving a magic wand and making zoo's 2400-baud connections run at ~200 cps, the way they used to when zoo was a pdp11 [!], increases that number only slightly. Discounting the PEP throughput a bit, ditto. I would suggest that unless there are factors I'm not aware of, it is in everyone's best interests, including yours, if you do *not* fall back to slow speeds when you can't get through to utzoo at high speed. Trying the high-speed call more frequently works much better. Some of you may already have implemented such a policy, but I know some of you haven't. I haven't made a systematic survey, but I see some of your sites on the slow lines with some frequency. Worse, I see some of them on the fast lines at low speed with some frequency, and that's hurting other sites by tying up the Trailblazers unnecessarily. I kill such connections when I notice them, but they really shouldn't be initiated at all. --------- -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
sl@van-bc.UUCP (Stuart Lynne) (08/11/89)
In article <1989Aug10.175458.20369@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I recently sent the following to our Trailblazer-equipped neighbors, and >dialup congestion is now noticeably less common here. It occurred to me >that others might be interested as well: >slow lines with some frequency. Worse, I see some of them on the fast >lines at low speed with some frequency, and that's hurting other sites by >tying up the Trailblazers unnecessarily. I kill such connections when I >notice them, but they really shouldn't be initiated at all. I recently added another 2400 bps line (gives van-bc two) and turned *OFF* everything but PEP on the two Trailblazer lines. I now tell all sites dialing in that they have a choice: stay with 2400 and compete for heavily used lines, with long duration calls or switch to PEP and get access to lines that are used less, for shorter duration calls. This gives other sites a valid reason for wanting to switch to PEP other than Long Distance charges (all but two of our neigbours don't pay for calls). Switching to PEP means faster access to send / receive mail / news. Staying with 2400 means you don't get in as often. My policy in future will probably be to expand lines as needed. Add a 2400 bps line when usage is in excess of say about 75%. Add a PEP line when usage exceeds about 50%. At this point in time the PEP lines are fairly lightly used compared to the 2400 bps lines and account for over two thirds of our news traffic (by volume). There have been some grumbling from the 2400 bps sites but not alot (they have been cut back from three lines to two effectively). And the PEP sites are quite happy. -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
amanda@intercon.uu.net (Amanda Walker) (08/11/89)
In article <1989Aug10.175458.20369@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > I would suggest that unless there are factors I'm not aware of, it is in > everyone's best interests, including yours, if you do *not* fall back to > slow speeds when you can't get through to utzoo at high speed. Trying > the high-speed call more frequently works much better. The same thing is true for uunet (from whom we get our news & mail feed). For some time now I've had our machine only accept PEP mode when talking to uunet, and it works very well. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda -- "It can hardly be a coincidence that no language on earth has ever produced the expression 'As pretty as an airport'" --Douglas Adams, _The_Long_
henry@utzoo.uucp (Henry Spencer) (08/11/89)
A friend points out that at least some versions of HDB (aka BNU) uucp are capable of restricting the grade of traffic on specific connections; this could be used to send mail, but not news, on a low-speed link to a site which also has high-speed links. (However, if you've got people who transfer files via mail, you may still want to consider the frequent-fast-calls-but-no-slow-calls strategy.) -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
edm@nwnexus.WA.COM (Ed Morin) (08/12/89)
In the same vein, here is another situation which gives pause to consider
whether to PEP or not. I'll try to be concise by using a somewhat contrived
example involving the machine "homesite":
1. homesite has all TrailBlazer dialins and dialouts.
2. homesite has crummy multiplexers (not uncommon) and gets about 12kb
sending and 8kb receiving performance for one line with *no other
activity*.
3. When other lines are active (possibly in PEP), the performance
degrades significantly. In fact, over a 3 week period it tends to
average about 4kb for received data (faster for sent data)!
4. Now, since homesite connects to UUNET, and homesite's pocketbook is
not infinite, there is incentive to optimize the connection. Roughly
speaking, if you say that a 2400 baud connection averages around 2kb
(which it seems to for a small sample) then any 2400 baud solution
needs to be multiplied by 2 to make it somewhat equivalent to a PEP
connection. Here is a brief comparison of per hour rates normalized
to a 4kb transfer rate:
Day Evening Night
UUNET 800 16 13 10
CompuServe 10 10 10
As you can see, CompuServe is cheaper, even at a slower baud rate,
than the UUNET 800 dialin during the day and evening! But that's
only because the multiplexers aren't taking full advantage of the
TrailBlazer speeds! And there are even cheaper possibilities than
this with slow speed connections...
So, my question is, has anybody else done this exercise in more detail.
I have more notes, but didn't post them in order to keep things simple.
My reaction to all this was "No wonder there are people in the world
who do nothing but manage datacommunications connections." Sigh.
--
Ed Morin
Northwest Nexus Inc.
"Unix Public Access for the Masses!"
edm@nwnexus.WA.COMedm@nwnexus.WA.COM (Ed Morin) (08/12/89)
henry@utzoo.uucp (Henry Spencer) writes: >(However, if you've got people who transfer files via mail, you may still >want to consider the frequent-fast-calls-but-no-slow-calls strategy.) My solution was to hack smail to downgrade mail messages that exceed a certain size. I've been experimenting with grading messages > 5k as 'a' rather than the default 'A' (or 'C' on some systems). This scheme allows small E-mail to be shipped quickly, but to hold onto the larger transfers for a more economical time of the day... -- Ed Morin Northwest Nexus Inc. "Unix Public Access for the Masses!" edm@nwnexus.WA.COM
grr@cbmvax.UUCP (George Robbins) (08/13/89)
In article <1989Aug10.175458.20369@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > I recently sent the following to our Trailblazer-equipped neighbors, and > dialup congestion is now noticeably less common here. It occurred to me > that others might be interested as well: > ... > I would suggest that unless there are factors I'm not aware of, it is in > everyone's best interests, including yours, if you do *not* fall back to > slow speeds when you can't get through to utzoo at high speed. Yes, I've done something similar here. Initially, I had fallbacks for all the PEP numbers, but busy conditions on either end resulted in calls gettings started on the fallback lines, so that large amounts of transfers will still taking place at 2400 baud. The downside to yanking the fall backs is that often it seems that the other guys 8-) trailblazer(s) will occasisionally wedge and be offline for a day or longer or simply be unreliable. Ideally you want some kind of adaptived fallback where after a day or so it breaks down and tries the 2400 baud numbers. The compromise is the keep all the cruft in the sys file and uncomment it when things get bad. I've also worked with my neighbors to jack up news batch sizes from around 50K (before compression) to 500K. This seems to be a little bit more efficient - 2 or 3 files per call per feed, than flood of the little ones. Surprisingly, no problems have shown up, but I'd hate to have to fallback to 1200 baud with a backlog of those suckers. It begins to seem like it would be nice if there was a widely distributed batch mail protocol - most of the little, high overhead transfers are now mail, often 13 messages forwarded to the same person from some non-digested mailing list. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
chip@ateng.com (Chip Salzenberg) (08/15/89)
According to grr@cbmvax.UUCP (George Robbins): >It begins to seem like it would be nice if there was a widely distributed >batch mail protocol - most of the little, high overhead transfers are now >mail, often 13 messages forwarded to the same person from some non-digested >mailing list. I'll bet many people are tired of hearing this: "It's in Smail 3." Batch SMTP is directly supported by Smail 3. I really wish that Smail 3.1 could be posted, even though Smail 3.2 will be different; it's an extremely useful program, even with a few (tiny) warts. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg | <chip@ateng.com> or <uunet!ateng!chip> A T Engineering | Me? Speak for my company? Surely you jest!