jiro@shaman.com (Jiro Nakamura) (06/09/91)
Does anyone know if UUNET is going to get an upgrade soon? I know about their recent upgrade, but I've been experiencing severe delays when communicating with them -- sometimes so severe my machine timeouts and stops talking. It sounds like their Sequent is all decked out and can't be upgraded any further. Is this true? What I was thinking would be beneficial for them is if they split into two or three hub computers, rather than just their main one. They could place these computers around the U.S. in strategic locations (kind of like major-POPs). This would be beneficial for them since it would reduce the load on any one machine. If they NFS mounted their files across the network, then they wouldn't have to have their whole archive on one computer too. I think it's time UUNET expanded. What do you others think? Replies to comp.mail.uucp or news.admin please, I want to get a discussion going. - Jiro Nakamura jiro@shaman.com -- Jiro Nakamura jiro@shaman.com The Shaman Group (607) 256-5125 VOICE "Bring your dead, dying shamans here!" (607) 277-1440 FAX/Data
root@mjbtn.JOBSOFT.COM (Mark J. Bailey [ADMIN]) (06/10/91)
In <1991Jun8.210644.4897@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > Does anyone know if UUNET is going to get an upgrade soon? I know >about their recent upgrade, but I've been experiencing severe delays when >communicating with them -- sometimes so severe my machine timeouts and >stops talking. Hi, Well, I was beginning to think it was me! :-) I have the following failure almost everytime I talk with uunet more than a few minutes: uucp uunet (6/10-5:22:55,20864,32) REMOTE REQUESTED (uunet!D.uunetByCz2 --> mjbtn!D.uunetSyCz2 (uucp)) uucp uunet (6/10-5:23:12,20864,33) REMOTE REQUESTED (uunet!D.uunetXyCz0 --> mjbtn!X.uunetEyCz3 (uucp)) uucp uunet (6/10-5:26:44,20864,34) BAD READ (expected ANY got FAIL) uucp uunet (6/10-5:26:44,20864,34) FAILED (conversation complete tty2C 402) The real killer for me has been that NOTHING has changed in my site config- uration in MONTHS! All of this started around the time of their last "upgrade" as Jiro is indicating. I have also had a marked increase in the number of login failures (both to 800-lines and regular line) on the front end. In the past, uunet connections were almost never interrupted from start to finish. As Jiro has emphasized, something does need to be done. I have addressed my problems to postmaster@uunet (and while I know they are busy) but I have not been responded to yet. It seems that at a certain point, they will start moving "backwards" in time (much like the imense load on Simtel20 - a incomparibly valuable resource on a system that almost cannot operate with the load of archivees). Now, don't get me wrong, I am a very satisfied UUNET customer, and have been for a while. Surely new hardware and network topology should be possible with the revenues they must be generating (or are going to potentially generate - if looked at from possibly a banker's point of view). I too would like to hear other's feelings and comments on the situation and possibly some shared input from some of the uunet crew as well. The service is invaluable, but competition is growing, and I am not exactly thrilled that I am paying for 3 minutes (in some cases) of "dead" time when the timeout/ alarm sequence begins before a failure is reported. I am not mad, just a little concerned. Mark. -- Mark J. Bailey, N4XHX _______/====X11====\_______ USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 | JobSoft | VOICE: +1 615 893 0098 | Design & Development Co.| UUCP: ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb | Murfreesboro, TN USA | DOMAIN: mjb@mjbtn.JOBSOFT.COM CIS: 76314,160 --------------------------- <KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>
randy@m2xenix.psg.com (Randy Bush) (06/10/91)
m2xenix is moving a few megabytes a day to/fro uunet via uucp, and has seen no degradation in service/throughput. As to the subject of the message, I think they're continually upgrading. I do like the idea of decentralizing, as I fear the single point of failure problem. But managing a distributed system is nowhere near as 'easy' as a central site. -- randy@psg.com ..!uunet!m2xenix!randy
alek@spatial.com ( Alek O. Komarnitsky ) (06/11/91)
In article <1991Jun8.210644.4897@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > > Does anyone know if UUNET is going to get an upgrade soon? I know >about their recent upgrade, but I've been experiencing severe delays when >communicating with them -- sometimes so severe my machine timeouts and >stops talking. > It sounds like their Sequent is all decked out and can't be >upgraded any further. Is this true? What I was thinking would be beneficial >for them is if they split into two or three hub computers, rather than >just their main one. They could place these computers around the U.S. >in strategic locations (kind of like major-POPs). > This would be beneficial for them since it would reduce the >load on any one machine. If they NFS mounted their files across the >network, then they wouldn't have to have their whole archive on one >computer too. > I think it's time UUNET expanded. What do you others think? >Replies to comp.mail.uucp or news.admin please, I want to get a >discussion going. How about using a local feed? Another posting discussed feeds from the local University. For those not-so-non-profit organizations, my impression is that there are other sources available - are the PSI's of the world really that bad/expensive? We have the Colorado Supernet locally which looks very promising and seems reasonably priced. Although I hope to continue getting our news feed from a friendly neighbor, we will probably switch our E-mail over to CSN soon. I would hope that as additional funding (ala Gore's bill) becomes available, more and more regional hubs will be opened up with relaxed restrictions. Alek Komarnitsky 303-449-0649 Software Tools Manager, Spatial Technology, Inc. 2425 55th Street, Bldg A alek@spatial.com Boulder, CO 80301-5704 P.S. Ok co.general, my apologies for not including a Miller Moth/etc. story. But I think the guys from Golden have a good thing going.
rfarris@rfengr.com (Rick Farris) (06/11/91)
In article <1991Jun10.144434.21216@m2xenix.psg.com> randy@m2xenix.psg.com (Randy Bush) writes: > m2xenix is moving a few megabytes a day to/fro uunet via > uucp, and has seen no degradation in service/throughput. I get a *lot* of login failures. I'm considering calling a V.32 CompuServe node instead of the (cheaper) direct node, just so I don't have to pay for login failures. > I do like the idea of decentralizing, as I fear the single > point of failure problem. But managing a distributed > system is nowhere near as 'easy' as a central site. I don't see much advantage (other than redundancy) to decentralizing. For instance, calls out of state are generally cheaper than long distance calls in-state, and it doesn't matter which of the lower 48 you're calling; with Reach-Out America, it's $6.30 an hour, no matter what. If they were to put a node on the other side of San Diego from me, it would still be cheaper to call VA. -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
tneff@well.sf.ca.us (Tom Neff) (06/11/91)
To those of you who were wondering what happened to UUNET: | From uunet.uu.net!liaison Tue Jun 11 09:37:28 1991 | From: liaison@uunet.uu.net (UUNET Customer Liaison) | Message-Id: <9106111336.AA10720@uunet.UU.NET> | Subject: Re: No News? | Date: Tue, 11 Jun 91 9:36:42 EDT | X-Mailer: ELM [version 2.3 PL10] | | > I haven't had news batches for a day. When will things get going again? | | We have been having hardware problems (controller board) on they server | that does news (machine name batch, how clever!) since last Thursday. | The machine started crashing Friday morning and continued to do so throughout | the weekend. Each time it crashed it took pot shots at uucico on the | other servers. | | We are working with the system manufacturer to correct the problem. In | the meantime, batch has been disabled in order to save uucico on the | other servers. | | I have no time-frame for correction of the problem....and so it goes..... | | -- | Lori Leonard liaison@uunet.uu.net | Customer Liaison uunet!liaison -- Tom Neff tneff@well.UUCP or tneff@dasys1.UUCP
gary@sci34hub.sci.com (Gary Heston) (06/12/91)
In article <1991Jun8.210644.4897@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > [ moan, groan, and suggestion deleted... ] > I think it's time UUNET expanded. What do you others think? >Replies to comp.mail.uucp or news.admin please, I want to get a >discussion going. I'm sure if you wanted to donate a couple of more Sequents, a few disc farms, and the T-3 links, they'd be glad to install them around the country so your thruput would be higher. I believe they already have multiple machines at Falls Church; trying to operate multiple sites across the country would cost lots more than the link charges do now. I've ask about what it would take to get a POP here, but haven't received a reply yet. They're probably trying to figure out just what kind of a nut I am.... :-) You might schedule your connections during low-traffic periods; the postmaster there might be able to recommend some times. It would be to all our (their customers) benefit to spread the load around. -- Gary Heston System Mismanager and technoflunky uunet!sci34hub!gary or My opinions, not theirs. SCI Systems, Inc. gary@sci34hub.sci.com I support drug testing. I believe every public official should be given a shot of sodium pentathol and ask "Which laws have you broken this week?".
chip@osh3.OSHA.GOV (Chip Yamasaki) (06/12/91)
In <1991Jun8.210644.4897@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > Does anyone know if UUNET is going to get an upgrade soon? I know >about their recent upgrade, but I've been experiencing severe delays when >communicating with them -- sometimes so severe my machine timeouts and >stops talking. > [details deleted] > I think it's time UUNET expanded. What do you others think? >Replies to comp.mail.uucp or news.admin please, I want to get a >discussion going. Well, I've been a satisfied customer for a few months now, but after looking at the xferstats file recently I have to agree. It disturbs me that I am paying for connect time and sometimes the rates are terrible, and other times the rates are great. I have reason to believe it's not me because my system load is relatively stable and I converse with another system that maintains consistant rates. It does bother me that they are charging for connect time and the inadequacy of their system is costing me money. Sounds crazy, but maybe they should drop their rates during peak hours when they know their system can't give you peak performance. -- -----------------------+--------------------------------------------------- Charles "Chip" Yamasaki| The opinions expressed here are my own and are not chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) -----------------------+---------------------------------------------------
tneff@bfmny0.BFM.COM (Tom Neff) (06/12/91)
I should note that I posted that note from Lori Leonard without asking her permission; I ought to know better, and I apologize. I was upset because UUNET has become pretty darn important to the connectivity of Usenet, and when they know they're going to have to go down for a while they really ought to let the world know (at least their customers). If you agree with me, let them know. In the meantime, they're back up and batching like mad...
jiro@shaman.com (Jiro Nakamura) (06/12/91)
In article <1991Jun11.053825.13936@rfengr.com> rfarris@rfengr.com (Rick Farris) > I don't see much advantage (other than redundancy) to > decentralizing. For instance, calls out of state are > generally cheaper than long distance calls in-state, and it > doesn't matter which of the lower 48 you're calling; with > Reach-Out America, it's $6.30 an hour, no matter what. > > If they were to put a node on the other side of San Diego > from me, it would still be cheaper to call VA. > > -- > Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 > rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757 What happens if it was in area code 619? Then, I think you would see the advantage. :-) I use ROA too, so it doesn't make much difference. Althought if I moved to a metropolitan area, it would be nice. We're switching the bulk of our traffic to PSI, which *does* have a POP in Ithaca. I hear PSI has a centralized news and e-mail server, even though their distribution system (POPs) are decentralized. Sigh... Which means if uu.psi.com fails.... Which is also why I requested that my MX forwarding records look like: 200 uu.psi.com 300 relay1.uu.net 300 relay2.uu.net Which means that if PSI goes down, then my mail *should* go through UUNET (I'm retaining subscriptions on both systems). This seems the best for right now. The problem is if PSI goes only half down, like UUNET does, and limps for a long time. E-mail will still go to them, but may not make it to me. - Jiro Nakamura jiro@shaman.com -- Jiro Nakamura jiro@shaman.com Shaman Consulting (607) 256-5125 VOICE "Bring your dead, dying shamans here!" (607) 277-1440 FAX/Data
rfarris@rfengr.com (Rick Farris) (06/13/91)
In article <1991Jun12.124917.1760@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > In article <1991Jun11.053825.13936@rfengr.com> rfarris@rfengr.com (Rick Farris) > > If they were to put a node on the other side of San Diego > > from me, it would still be cheaper to call VA. > What happens if it was in area code 619? Then, I think you would see > the advantage. :-) No, that's why I mentioned "the other side of San Diego". Long distance intra-lata phone calls here in San Diego county are as expensive as $20/hour! -- Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757
rog@ingres.com (Roger Taranto) (06/13/91)
In article <1991Jun12.124917.1760@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: >> If they were to put a node on the other side of San Diego >> from me, it would still be cheaper to call VA. >> Rick Farris RF Engineering POB M Del Mar, CA 92014 voice (619) 259-6793 >> rfarris@rfengr.com ...!ucsd!serene!rfarris serenity bbs 259-7757 > >What happens if it was in area code 619? Then, I think you would see >the advantage. :-) Actually, no. At least in California, the way the CPUC allows telephone companies to set rates, it's cheaper to call out of state than to call to the other side of your area code. For example, it's cheaper for me to make a call from Alameda to Boston than to call from Alameda to Mountain View (which is just across the bay). From what I understand, UUNET has a POP in Mountain View. A friend of mine found that it was cheaper for him to call Virginia than to call Mountain View. I find it very curious that there have been no responses from UUNET on this thread. -Roger {mtxinu,pacbell,amdahl,sun,hoptoad}!rtech!rog rog@ingres.com
fdr@fdrpc.UUCP (Frank Rockenstein) (06/13/91)
> > Does anyone know if UUNET is going to get an upgrade soon? I know > about their recent upgrade, but I've been experiencing severe delays when > communicating with them -- sometimes so severe my machine timeouts and > stops talking. I am experiencing the same problem. Your solution sounds like a fine idea - except I would vote for running "Waffle" on a dos board ( one line per board ) with NFS . At $100 per board 286 16 mhz - you could do a thousand lines for $100,000 mas o menos. Yeah I know Waffle lacks a few necessary features and you will need some function servers for the accounts but this is a design your own network kind of thread isn,t it?? Alternately, lets put an etherbone in every telco CO ( I've already proposed this Ha Ha) instead of the CO lan "data switch virtual circuit" set ups which are now being implemented. Forget ISDN thru the switch - just let me have the v. 32 bis 192 kbit local loop digital link running slip into the bone. Come out of there ds2 to a regional hub running FDDI or MAN ( Does MAN still exist??) thence ds3 on to the national hub in DC where UUNET can have a direct fddi protocol port to its MIT GIGAFLOP 90,000 (just guessing) dos board multiprocessor IP server - think how much they will save on telebits... That should take care of the timeout problem.... &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& I am my own node now. If you too would like to be your own node, mail to node@fdrpc.UUCP ++++++++++++++++++++++++++++++++++++++++++++++++
csg@pyramid.pyramid.com (Carl S. Gutekunst) (06/13/91)
As an outside observer who gets a close look inside every now and then, I'd say that the Number 1 concern at UUNet is machine resources, and has been for several years. Everyone here on the Net seems to keep coming up with clever solutions, and wondering why UUNet doesn't try something like that. Trust me: all the easy ideas have been tried already. In article <1991Jun8.210644.4897@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > > Does anyone know if UUNET is going to get an upgrade soon? I know >about their recent upgrade, but I've been experiencing severe delays when >communicating with them -- sometimes so severe my machine timeouts and >stops talking. > It sounds like their Sequent is all decked out and can't be >upgraded any further. Is this true? What I was thinking would be beneficial >for them is if they split into two or three hub computers, rather than >just their main one. They could place these computers around the U.S. >in strategic locations (kind of like major-POPs). > This would be beneficial for them since it would reduce the >load on any one machine. If they NFS mounted their files across the >network, then they wouldn't have to have their whole archive on one >computer too. > I think it's time UUNET expanded. What do you others think? >Replies to comp.mail.uucp or news.admin please, I want to get a >discussion going. > > - Jiro Nakamura > jiro@shaman.com > > >-- >Jiro Nakamura jiro@shaman.com >The Shaman Group (607) 256-5125 VOICE >"Bring your dead, dying shamans here!" (607) 277-1440 FAX/Data
ake@dayton.saic.com (Earle Ake) (06/14/91)
In article <1991Jun12.012806.25633@osh3.OSHA.GOV>, chip@osh3.OSHA.GOV (Chip Yamasaki) writes: > In <1991Jun8.210644.4897@shaman.com> jiro@shaman.com (Jiro Nakamura) writes: > >> Does anyone know if UUNET is going to get an upgrade soon? I know >>about their recent upgrade, but I've been experiencing severe delays when >>communicating with them -- sometimes so severe my machine timeouts and >>stops talking. >> [details deleted] >> I think it's time UUNET expanded. What do you others think? >>Replies to comp.mail.uucp or news.admin please, I want to get a >>discussion going. > > Well, I've been a satisfied customer for a few months now, but after > looking at the xferstats file recently I have to agree. It disturbs me > that I am paying for connect time and sometimes the rates are terrible, > and other times the rates are great. I have reason to believe it's not > me because my system load is relatively stable and I converse with > another system that maintains consistant rates. > > It does bother me that they are charging for connect time and the > inadequacy of their system is costing me money. Sounds crazy, but maybe > they should drop their rates during peak hours when they know their > system can't give you peak performance. I always wondered why they charged for connect time. If you have a 2400 baud modem and pay for your own phone call you get it twice as bad. First you pay the long distance carrier for a longer call duration then uunet hits you for more connect time. I guess the assumption if they want everyone to get trailblazers to increase throughput. I think the problem now is so many have gotten the high speed modems that their system can't handle the throughput! If they continue to have a problem it might be fairer to charge by the kbyte of data transferred then add a small sur-charge for slower speed modems. This would charge evenly even if the system at their end is going slow. It would not reduce the phone bill however. Right now, what is the driving factor to speed up their system? If it runs slower then customers will use more connect time and their bill will be higher. Let's hope they use some of the additional money they collect due to the slower throughput and upgrade their systems. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake
fg041@unocss.unomaha.edu (fg041) (06/15/91)
> Does anyone know if UUNET is going to get an upgrade soon? I know >about their recent upgrade, but I've been experiencing severe delays when >communicating with them -- sometimes so severe my machine timeouts and >stops talking. Last week we (not this site, another one) had several sessions with UUNET which croaked due to timeouts. I sent them a note about this and got an apology and they explained it was a disk controller problem and that it would be fixed Real Soon Now. It was, and sessions since Tuesday have been ok. (We still see frequent 1-2 second pauses, but everyone tells me this is normal for UUNET.) > ... This would be beneficial for them since it would reduce the >load on any one machine. If they NFS mounted their files across the >network, then they wouldn't have to have their whole archive on one >computer too. The note I received implied that they were running different machines for news and mail. I watched a couple of the bad sessions and saw it hang just at the point all mail came in and it would normally start sending the news batches. A couple of times I forced uucico to do an immediate re-poll and got the news to come through fine, but again sometimes it did not. > I think it's time UUNET expanded. What do you others think? >Replies to comp.mail.uucp or news.admin please, I want to get a >discussion going. The only gripe I have is that the throughput is less than at other sites. However, we recently switched from a few 'good buddy' type news feeds to UUNET and it is a world of difference as far as quality of the feed. After putting up with delayed stuff, missing stuff, massive dupes, and frequent drought-flood cycles, I can live with the slight delays, although I do think they should do something about it. I have found that by polling at times NOT on the hour or half hour, I get better throughput. Good Day! JSW postmaster@ivgate.uucp
time@ice.com (Tim Endres) (06/15/91)
In article <3303@unocss.unomaha.edu>, fg041@unocss.unomaha.edu (fg041) writes: > I do think they should do something about it. I have found that by polling > at times NOT on the hour or half hour, I get better throughput. I wonder if UUNET has thought of gathering all those UUCICO scheduling files and trying to distribute call time suggestions based on some type of analysis? :-) ------------------------------------------------------------- Tim Endres | time@ice.com ICE Engineering | uupsi!ice.com!time 8840 Main Street | Voice FAX Whitmore Lake MI. 48189 | (313) 449 8288 (313) 449 9208
asp@uunet.uu.net (Andrew Partan) (06/18/91)
In article <1991Jun10.144434.21216@m2xenix.psg.com>, randy@m2xenix.psg.com (Randy Bush) writes: > As to the subject of the message, I think they're continually upgrading. We currently have one machine handling nothing but the UUCP traffic (with 100+ modems on it), 2 machines handling the mail, 4 machines for news (1 for nntp, 1 for batching, 2 for compressing), and 1 machine for the nameserver. Recent additions have been the 2nd machine for mail & the 3 machines for news. The current bottleneck (its always changing) is the uucp machine, especially late at night when everyone is calling it. Unfortunately, to upgrade that large monolithic machine to a larger monolithic machine is going to cost something like $150,000- plus. Instead what we are doing is working on rewritting uucp to make it run across multiple machines. This is not an easy task. The current estimate of when this will be done is sometime later this summer. In the meantime, we are looking at other hacks to make things better then they currently are. Adding additional machines for mail is easy. Its almost as easy to add additional machines for news. The nameserver is unloaded & a 2nd nameserver would be easy to add, if needed. --asp@uunet.uu.net (Andrew Partan)
herrickd@iccgcc.decnet.ab.com (06/19/91)
In article <1991Jun12.012806.25633@osh3.OSHA.GOV>, chip@osh3.OSHA.GOV (Chip Yamasaki) writes: > inadequacy of their system is costing me money. Sounds crazy, but maybe > they should drop their rates during peak hours when they know their > system can't give you peak performance. It's not crazy, just backwards. If there is an hour during the day that the load is too high for them to serve, they should *raise* their rates for that time of day. This would let their customers make a clear economic decision to pay the higher rates because they really need access during that hour or move to a different hour when the rates are lower. If the demand for the service is higher than the supply, this is a signal that the price is too low. Prices communicate. It should cost more to cross the George Washington Bridge during peak traffic times and less during times of essentially no traffic. This would move discretionary travel to non-peak times and even out the load some making for less congestion during the peak time. Uunet already experiences some of this in the phone company tolls that are less at some times of day than other times of day. Anyone, including uunet, who has a service that is congested some times in the day and idle other times of the day, should use differential pricing to move some of the load to the less popular times. dan herrick > -- > -----------------------+--------------------------------------------------- > Charles "Chip" Yamasaki| The opinions expressed here are my own and are not > chip@oshcomm.osha.gov | supported or even generally accepted by OSHA. :-) > -----------------------+---------------------------------------------------
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <1991Jun18.124131.4910@iccgcc.decnet.ab.com> herrickd@iccgcc.decnet.ab.com writes: >It's not crazy, just backwards. If there is an hour during the day >that the load is too high for them to serve, they should *raise* their >rates for that time of day... If I recall Rick's comments one or two Usenixes ago correctly, he has thought about it, but doesn't feel like explaining over and over and over again why his rates are higher when everyone else's are lower. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
bill@camco.Celestial.COM (Bill Campbell) (06/19/91)
In <1991Jun18.024342.1387@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes:
:stuff deleted....
:The current bottleneck (its always changing) is the uucp machine,
:especially late at night when everyone is calling it. Unfortunately, to
:upgrade that large monolithic machine to a larger monolithic machine is
:going to cost something like $150,000- plus.
:Instead what we are doing is working on rewritting uucp to make it run
:across multiple machines. This is not an easy task. The current
:estimate of when this will be done is sometime later this summer. In
:the meantime, we are looking at other hacks to make things better then
:they currently are.
I would think it would be easier to implement some kind of mail
batching capabilities rather than rewriting uucp for multiple
machines. I think I've seen postings about mail batchers similar
to news batching that would cut uucp down significantly by
eliminating the startup times on many small messages.
uutraf reports on camco typically report total times for uunet at
less that half that billed. I think this is the inter-file times
since uutraf is only reporting individual file transfer times,
not connect times. Cutting this time in half would save me
several hours each month :-)
Bill
--
INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software
UUCP: ...!thebes!camco!bill 6641 East Mercer Way
uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591chip@tct.com (Chip Salzenberg) (06/20/91)
According to bill@camco.Celestial.COM (Bill Campbell): >I would think it would be easier to implement some kind of mail >batching capabilities rather than rewriting uucp for multiple >machines. Quite! Batch SMTP already exists and is supported by Smail 3.1 (among other transports). What say you, UUNET? BSMTP could cut down significantly on E-Mail processing overhead, and lots of us out here in modemland are already using it. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "You can call Usenet a democracy if you want to. You can call it a totalitarian dictatorship run by space aliens and the ghost of Elvis. It doesn't matter either way." -- Dave Mack
emv@msen.com (Ed Vielmetti) (06/21/91)
In article <28609F47.1E0D@tct.com> chip@tct.com (Chip Salzenberg) writes:
Quite! Batch SMTP already exists and is supported by Smail 3.1 (among
other transports). What say you, UUNET? BSMTP could cut down
significantly on E-Mail processing overhead, and lots of us out here
in modemland are already using it.
Chip, could you give a tutorial on compressed batched SMTP ? That
would seem to be the ideal thing for long-haul links with high modem
costs. How to set it up within smail, what the gotchas are, how much
of a savings in on-line time there is and at what cost in extra
compression vs. benefit in fewer uuxes done.
Numbers would be nice to know, if they're convincing we'll start to
offer the service on our dialups.
--
Edward Vielmetti, MSEN Inc. moderator, comp.archives emv@msen.combill@ssbn.WLK.COM (Bill Kennedy) (06/21/91)
>According to bill@camco.Celestial.COM (Bill Campbell): [ wants batched mail... ] chip@tct.com (Chip Salzenberg) replies: >Quite! Batch SMTP already exists and is supported by Smail 3.1 (among >other transports). What say you, UUNET? BSMTP could cut down >significantly on E-Mail processing overhead, and lots of us out here >in modemland are already using it. I'm not a uunet subscriber but I can vouch for the efficiency and reliability of the BSMTP in smail3. This site gateways for several others and being able to receive their mail in compressed batches is a huge win. Here are the problems with it and perhaps the very reason that uunet might be reluctant to implement it. If you're using compressed batches (I can't think of why you'd batch but not compress) and something goes wrong with the decompression everything delivers to /dev/null. This has happened down here (TX) twice that I'm aware of, I did it and a Dallas site did it. In both cases it was a dumb mistake by the SA (me) but in every case the mail was permanently lost. This is uncharacteristic of an smail3 site but you have to realize that the lossage isn't smail3, it happens before it ever gets into the act. Smail3 goes to every extreme to avoid losing mail, sometimes I think to the extent that if all else fails and there's a radio on in the room it would play it out there :-) The other disadvantage to BSMTP is minor unless you have a lot of addressees at the same site for the same message. It's the nature of SMTP, you queue up one copy of the message for each addressee. If you use the uux transport a single copy of the message is sent. Further, when you apply compression, I still think BSMTP is a win. Since I'm not a subscriber I think that I can recklessly speculate on why they have a conservative nature about both news and mail. Think about the combinations and permutations that they must serve. They probably talk to every OS version, hardware configuration, and SA skill level. If they get ambitious, sophisticated, or exotic they're sure to break or confuse one or more subscribers. Accordingly, IMHO, they must opt for the least complicated approach even when it's not the most efficient. It's easy for me and Chip to hum the praises of BSMTP (I *love* it!) but if I was administering mail at uunet I might shudder at the "collateral damage" it could/would cause. -- Bill Kennedy internet bill@ssbn.WLK.COM or ssbn!bill@attmail.COM uucp {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill
dlr@daver.bungi.com (Dave Rand) (06/22/91)
In article <EMV.91Jun21004543@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: >Chip, could you give a tutorial on compressed batched SMTP ? That >would seem to be the ideal thing for long-haul links with high modem >costs. How to set it up within smail, what the gotchas are, how much >of a savings in on-line time there is and at what cost in extra >compression vs. benefit in fewer uuxes done. > >Numbers would be nice to know, if they're convincing we'll start to >offer the service on our dialups. > I will leap in here as well. I run CBSMTP to many sites now, including decwrl.dec.com. This offers several advantages: o Some sites have expensive/restricted calling times. I can defer batching mail to them until this time, and collect 20-50 messages in one batch. Compressing on this volume of mail is a huge win, with compression ratios of 3:1 or more. The best savings, however, is the 10 second or so UUCP turnaround per file - most CBSMTP links are now sitting at 1-2 minute connects (details below). o Proper "smtp"-like addressing. This prevents having to whip back and forth between "!" and "@" addressing on sites that understand both forms. o Unlimited multi-drop recipients. I run a large mailing list from bungi.com, and I get the advantage of having a (quite) large list of recipients of one mail message. Yes, you can do this with rmail as well (on those sites that support this), but it still has the command line limit of 1024 characters (or 10K characters, depending on your UNIX flavour). Now, on to numbers. Site cheers.bungi.com is only a hundred or so miles from daver.bungi.com, so of course it is a hyper-expensive call (within California). I connect to it only in the wee hours (0100-0600), and queue mail the rest of the day. Over the past few days, here is the connect information: uucp cheers (6/17-1:27:38,11787,2) OK (conversation complete ttyh2 57) uucp cheers (6/18-1:27:17,27604,2) OK (conversation complete ttyh4 65) uucp cheers (6/18-6:08:37,307,2) OK (conversation complete ttyh3 145) uucp cheers (6/19-1:07:17,9530,4) OK (conversation complete ttyh2 66) uucp cheers (6/20-1:07:05,26502,2) OK (conversation complete ttyh2 54) uucp cheers (6/21-1:07:12,14722,4) OK (conversation complete ttyh2 61) uucp cheers (6/21-3:57:12,16022,2) OK (conversation complete ttyh2 47) System # Files Bytes Rx Bytes Tx Connect Rx Avg Rx Max Tx Avg Tx Max TTY cheers 14 0 47762 0:00:28 0 0 1668 1740 ttyh2 cheers 2 0 2961 0:00:01 0 0 1701 1701 ttyh3 cheers 2 0 22382 0:00:15 0 0 1453 1452 ttyh4 System # Files Bytes Rx Bytes Tx Connect Rx Avg Tx Avg cheers 18 0 73105 0:00:45 0 1597 Site Name Peak Evening Night Total cheers 0.0 / $0.00 0.0 / $0.00 0.2 / $1.23 0.2 / $1.23 TOTAL 0 / $0.00 0 / $0.00 0 / $1.23 0 / $1.23 So far, they have received 264 messages, but I have sent them only 18 files (9 D. and 9 X. files), totalling 73,105 bytes (compressed), at an average transfer speed of 1597 bytes/sec, using 45 real seconds of transfering data. Note that the login overhead/uucp overhead means that we paid for 9 minutes of connect time, but only used 45 seconds of actual TX/RX. Sigh. Facts of life. I suspect that CBSMTP has saved me (this week) over $4. Each uucp transaction would have taken at least 10 seconds, or about 44 minutes of connect time. Ignoring the effect of the first minute/subsequent minute charges (which are considerable - 0.21/0.15 prime, 0.17/0.12 evening, 0.12/0.09 night), this is 8.25 minutes vs 44. $16/month - $192/year. For the cost of a _very_ small amount of CPU time here to do the compress, and there to do the uncompress. This is a small example - most of the sites that I talk to do much more mail traffic than cheers.bungi.com. CBSMTP is a BIG win. I wish everyone would use it - sun.com for example gets a lot of traffic from daver.bungi.com via uucp. 1230 files so far, meaning 615 messages so far this week. I bet the connect time could be at least halved... 9 hours so far this week! System # Files Bytes Rx Bytes Tx Connect Rx Avg Rx Max Tx Avg Tx Max TTY sun 51 55634 13405 0:01:36 626 1094 1773 1900 ttyh1 sun 318 36778 4758207 0:54:49 500 958 1479 1884 ttyh2 sun 80 69188 40373 0:02:52 463 1139 1706 1821 ttyh3 sun 698 1272223 3750093 1:44:37 773 1149 809 1898 ttyh4 sun 83 29018 39527 0:04:57 176 213 296 273 ttyh6 System # Files Bytes Rx Bytes Tx Connect Rx Avg Tx Avg sun 1230 1462841 8601605 2:48:54 689 1073 Site Name Peak Evening Night Total sun 4.0 / $14.88 2.0 / $5.84 3.3 / $5.64 9.4 / $26.36 TOTAL 4 / $14.88 2 / $5.84 3 / $5.64 9 / $26.36 -- Dave Rand {pyramid|mips|bct|vsi1}!daver!dlr Internet: dlr@daver.bungi.com
bill@camco.Celestial.COM (Bill Campbell) (06/22/91)
A got to thinking more about batched mail last night while
reading the c-news installation documentation, and it occurred to
me that it would be possible to use news and deliver to batch
mail rather painlessly.
1. I would have deliver.post look at the final mail address,
and if the first hop was to a batched site inject it into
a news group (say to.batchsite) and DROP it from the mail.
2. The /usr/lib/mail/sys entry at the receiving site would
look something like 'tomail:to.batchsite::rmail unbatchmail'
3. When the global deliver routine sees the 'To: ununbatchmail'
it can extract the real 'To: ...' from the header and
send it on its merry way.
Am I missing something here? This wouldn't require any new
software and really minimal processing by deliver.
Bill
--
INTERNET: bill@Celestial.COM Bill Campbell; Celestial Software
UUCP: ...!thebes!camco!bill 6641 East Mercer Way
uunet!camco!bill Mercer Island, WA 98040; (206) 947-5591david@twg.com (David S. Herron) (06/24/91)
In article <2085@ssbn.WLK.COM> bill@ssbn.WLK.COM (Bill Kennedy) writes: >>According to bill@camco.Celestial.COM (Bill Campbell): >If you're using compressed batches (I can't think of why you'd batch but >not compress) Easy .. by using BSMTP you don't downgrade your mail to RFC976/UUCP format and addressing styles. I see *this* as the big win.. but then my personal mail needs from home are not that large. >The other disadvantage to BSMTP is minor unless you have a lot of >addressees at the same site for the same message. It's the nature >of SMTP, you queue up one copy of the message for each addressee. >If you use the uux transport a single copy of the message is sent. >Further, when you apply compression, I still think BSMTP is a win. This is completely untrue. BSMTP (as does SMTP) allows, and was specifically designed to do: HELO <domain> MAIL FROM:<joe@place.com> RCPT TO:<...> RCPT TO:<...> RCPT TO:<...> RCPT TO:<...> You can repeat that RCPT line as many times as you want. If the smail3 implementation does not allow for this, then it is broken. My BSMTP implementation specifically allowed for that, BTW. David -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
chip@tct.com (Chip Salzenberg) (06/24/91)
According to david@twg.com (David S. Herron): >BSMTP (as does SMTP) allows, and was specifically designed to do: > HELO <domain> > MAIL FROM:<joe@place.com> > RCPT TO:<...> > RCPT TO:<...> > RCPT TO:<...> > RCPT TO:<...> > >You can repeat that RCPT line as many times as you want. If the smail3 >implementation does not allow for this, then it is broken. Smail 3.1 accepts this construct. It even generates it. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "You can call Usenet a democracy if you want to. You can call it a totalitarian dictatorship run by space aliens and the ghost of Elvis. It doesn't matter either way." -- Dave Mack
chip@tct.com (Chip Salzenberg) (06/25/91)
According to bill@camco.Celestial.COM (Bill Campbell): >A got to thinking more about batched mail last night while >reading the c-news installation documentation, and it occurred to >me that it would be possible to use news and deliver to batch >mail rather painlessly. It would not be very hard to use Deliver to do some kind of E-Mail batching. But it would be special, a one-site-only protocol -- not worth doing, given that Smail 3.1 already does BSMTP so well. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "I want to mention that my opinions whether real or not are MY opinions." -- the inevitable William "Billy" Steinmetz
les@chinet.chi.il.us (Leslie Mikesell) (06/26/91)
In article <EMV.91Jun21004543@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: > Quite! Batch SMTP already exists and is supported by Smail 3.1 (among > other transports). What say you, UUNET? BSMTP could cut down > significantly on E-Mail processing overhead, and lots of us out here > in modemland are already using it. > >Chip, could you give a tutorial on compressed batched SMTP ? That >would seem to be the ideal thing for long-haul links with high modem >costs. How to set it up within smail, what the gotchas are, how much >of a savings in on-line time there is and at what cost in extra >compression vs. benefit in fewer uuxes done. In addition to the compression (which could be done apart from the batching if you have large mail messages) the real savings is in having fewer files for uucico to handle, especially if you are using PEP modems with spoofing. The spoofing mode only works within a file with the upper-level handshaking for each file suffering from the modem's slow turn around time. Since normaly uucp mail takes two files per message (data in one, command in the other) reducing this to two files per batch can be a big win. In addition you get the ability to use SMPT addressing with unlimited recipients per message which is nice if you run list expanders. The down side is that (a) the receiving site must be set up to match, (b) you need to impose an arbitrary delay in delivery to accumulate a batch and you may not be able to syncronize the batching with inbound calls, and (c) Smail3's (B)SMTP transport isn't quite binary transparent in that the convertion of LF's to CR/LF and extra leading '.'s on lines that start with '.' doesn't always invert (for example if the message body contains CR's with no LF). >Numbers would be nice to know, if they're convincing we'll start to >offer the service on our dialups. Look at real time (from your phone bill) vs. uucp's xferstats numbers to get an idea of how much time you spend in the between-file handshakes. Les Mikesell les@chinet.chi.il.us
jeh@cmkrnl.uucp (06/27/91)
In article <1991Jun18.024342.1387@uunet.uu.net>, asp@uunet.uu.net (Andrew Partan) writes: > The current bottleneck (its always changing) is the uucp machine, > especially late at night when everyone is calling it. Unfortunately, to > upgrade that large monolithic machine to a larger monolithic machine is > going to cost something like $150,000- plus. > Instead what we are doing is working on rewritting uucp to make it run > across multiple machines. This is not an easy task. [...] gee, if you were running on VMS in a VAXcluster you could add nodes to your heart's content, and the cluster software takes care of everything necessary to allow all nodes to handle uucp calls. Oh, did you say that cost per mip is a concern? Oh, well... :-) Now for a HELPFUL suggestion! I am not a uunet subscriber, but last night I needed to download many things from them via their 900 number. During the first long transfer I noticed the PEP light on my modem blinking. This is evidence of a PEP "retrain". Naturally, the RD light indicated no data being received during this period. This happened several times, so I killed the call and dug through some old saved messages. Someone had said that setting S120=16 might help in cases where the modem seemed to be retraining frequently. I changed my telebit dial script to set S120=16 and let my uucico daemon call uunet again. This time there were no retrains, and I got about 1400 char/second, which is as good as the Trailblazer ever does, on the remaining significant-size files. Both calls were in the 0300 to 0400 time frame, east coast time. Obviously this is a poor sample, consisting of only two calls. I might have just happened to hit lots of noise on the first call and very little on the second. My modem is a Telebit T2500, ROM version GF7.00. Your mileage may vary. --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA uucp protocol guru, VMSnet [DECUS uucp] Working Group, DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh
karl@ddsw1.MCS.COM (Karl Denninger) (06/28/91)
In article <2866103E.4D7F@tct.com> chip@tct.com (Chip Salzenberg) writes: >According to david@twg.com (David S. Herron): >>BSMTP (as does SMTP) allows, and was specifically designed to do: >> HELO <domain> >> MAIL FROM:<joe@place.com> >> RCPT TO:<...> >> RCPT TO:<...> >> RCPT TO:<...> >> RCPT TO:<...> >> >>You can repeat that RCPT line as many times as you want. If the smail3 >>implementation does not allow for this, then it is broken. > >Smail 3.1 accepts this construct. It even generates it. Smail3.1 can also be told how many RCPT's it can send to in one batch. Since the specs only call for a minimum of 100, I usually set it to 100 (to prevent blowing someone's mind on the other end with something they can't handle). If you send through a 400-person mailing list, it will generate 4 copies of the message in this case, each with 100 addresses in it. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Anon. arch. (nuucp) 00:00-06:00 C[SD]T, req: /u/public/sources/DIRECTORY/README
jiro@shaman.com (Jiro Nakamura) (06/28/91)
In article <1991Jun26.221821.134@cmkrnl.uucp> jeh@cmkrnl.uucp writes: > Now for a HELPFUL suggestion! I am not a uunet subscriber, but last night I > needed to download many things from them via their 900 number. During the > first long transfer I noticed the PEP light on my modem blinking. This is > evidence of a PEP "retrain". Naturally, the RD light indicated no data being > received during this period. > > This happened several times, so I killed the call and dug through some old > saved messages. Someone had said that setting S120=16 might help in cases > where the modem seemed to be retraining frequently. Oddly enough, I get this often too. I'm wondering if it's a common problem with PEP or UUNET or Fall Church, VA's phone lines. I may try the S120=16 yet (although I would think that it would be a performance loss during the login sequence and the inter-file handshaking). - jiro nakamura jiro@shaman.com -- Jiro Nakamura jiro@shaman.com Shaman Consulting +1 607 277-1440 Voice/Fax/Data "Bring your dead, dying shamans here!"
les@chinet.chi.il.us (Leslie Mikesell) (06/29/91)
In article <1991Jun18.024342.1387@uunet.uu.net>, asp@uunet.uu.net (Andrew Partan) writes: > going to cost something like $150,000- plus. > Instead what we are doing is working on rewritting uucp to make it run > across multiple machines. This is not an easy task. [...] What would break if you simply NFS or RFS mount your main machine's /usr/spool into some other machines setting up the passwd, Systems, Permissions, etc. to be identical or symlinks? I suppose the device names for the tty lines should all be unique. Then just set up the uucp's to lie about the machine name so it all pretends to be one machine, and only run uuxqt on the main system. I'm pretty sure this would work reliably using RFS, and the only thing NFS might mess up would be creating the LCK..machine lockfiles. Anyway it's time to set up a satellite broadcast of the news and reserve the modems for inbound traffic and mail. Les Mikesell les@chinet.chi.il.us
asp@uunet.uu.net (Andrew Partan) (06/30/91)
In article <1991Jun28.222708.27277@chinet.chi.il.us>, les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <1991Jun18.024342.1387@uunet.uu.net>, asp@uunet.uu.net > (Andrew Partan) writes: > > Instead what we are doing is working on rewritting uucp to make it run > > across multiple machines. This is not an easy task. [...] > What would break if you simply NFS or RFS mount your main machine's We have tried this & its does not work. We avoid NFS stuff like the plague. You have all sorts of problems if machines go down, but the real reason is that NFS is just so damm slow. We have a couple of r-commands (rcp, rmv, ruux) that do most of the work & that fail gracefully (with queueing) when things fail. We are using this now for mail & news. --asp@uunet.uu.net (Andrew Partan)