jiro@shaman.com (Jiro Nakamura) (06/11/91)
In an earlier article, I expressed my unhappiness with UUNET's current performance (slow, almost dead UUCP transfers, busy lines, timeouts, etc). I hypothesized that it was due to UUNET's computers being overloaded. As it turns out, that isn't the case. I received the following e-mail message from UUNET, responding to my message: >> We are beginning to experience timeouts when >> communicating via UUCP to UUNET. These timeouts are most probably >> because UUNET's computer is overextended. However, as a paying >> customer, I must tell you that these timeouts are absolutely >> unacceptable. As long as UUNET makes us pay by the minute, I >> think that they are obligated to make sure that they are >> transmitting at an optimum speed. > >This is unrelated to the load on UUNET. We had a disk controller >& disk flake out on us this week, which caused all manner of >problems for the processes trying to access them. > >kyle jones <postmaster@uunet.uu.net> ...!uunet!postmaster This reply was, to say the least, irritating. Kyle Jones seems to not care about the situation. He offered no apology for UUNET's performance. Yes, yes, the problem was not his fault, but he (or someone at UUNET) should have notified their customers that they were experiencing problems. As such, I have wasted a good deal of this month's communication charges because of UUNET's problems. Only one out of two polls to UUNET will succeed, most of them time-out after transferring one or two files. This is simply inexcusable. This was my direct reply to Kyle Jones e-mail message: > Why didn't you notify your customers of this? If we had been > notified ahead of time that you were experiencing this problem, that > you were working on it, and were going to fix it by a certain, specified > date, then it may not have generated as much ill feelings at this site. > If this has affected as many other sites as it has mine, then UUNET has > cheated many companies out of a lot of money. > Not notifying your customers of computer trouble that had > severely affected UUCP communications is absolutely inexcusable for > a UUCP communications service provider. UUNET should be ashamed of > themselves. Up to last week, I have had nothing but the best feelings toward UUNET. They have provided with one of the industry's best customer and technical support. Because of that, I was willing to overlook the fact that they were not providing same quality in their UUCP service. Now with this incidence, I am reconsidering whether or not I want to continue having UUNET as my primary e-mail and news feed. If I cannot trust them with being able to carry my data, then I will not stick with them. Kyle Jone's brazenness and uncaring attitude towards his customers will have its effect. I hope his attitude does not reflect a new policy of UUNET towards its customers. I hope UUNET takes the necessary steps to rectify this situation. I am sad to see an industry leader cover itself with mud. - Jiro Nakamura jiro@shaman.com ps. Please do not flame me telling me how wonderful UUNET is. Until last week, I too believed that it was the best thing since string telephones. pps. IMHO, I think UUNET should notify all of its customers of its recent problems and give sites that experienced severe problems (such as mine) credit towards this month's bill. -- Jiro Nakamura jiro@shaman.com Shaman Consulting (607) 256-5125 VOICE "Bring your dead, dying shamans here!" (607) 277-1440 FAX/Data
jp@tygra.Michigan.COM (John Palmer) (06/11/91)
In article <1991Jun11.010801.8920@shaman.com> jiro@shaman.com (Jiro Nakamura) writes:
"
" Kyle Jone's brazenness and uncaring attitude towards his customers
"will have its effect. I hope his attitude does not reflect a new policy
"of UUNET towards its customers. I hope UUNET takes the necessary steps
"to rectify this situation. I am sad to see an industry leader cover
"itself with mud.
"
I got a similar note from UUNET when I asked about the slow V.32
service. We dial in with a T2500 in V.32 mode with V.42/V.42bis
enabled to the CompuServe V.32 numbers and the best throughput I
can get is 270cps. Come one now - I can do nearly as well with a
cheap-o 2400 bps modem.
UUNET claims its CompuServe's problem and suggests that I contact
them. Excuse me, but the problem would have to be the internal
link between UUNET and CompuServe, so why should I have to call
them? Furthermore, the attitude that UUNET displays (ho hum, its
not our problem) is not the best for a service organization. From
what I understand, many other UUNET customers who call in via Compu-
Serve's V.32 modems are having identical problems.
Well, at least its better than dialing UUNET direct. A PEP modem
connection couldn't get "110cps. (I tried twice, during different
times of the day: noon and 3 am).
--
CAT-TALK Conferencing System | "Buster Bunny is an abused | E-MAIL:
+1 313 343 0800 (USR HST) | child. Trust me - I'm a | jp@Michigan.COM
+1 313 343 2925 (TELEBIT PEP) | professional..." |
********EIGHT NODES*********** | -- Roger Rabbit | kre@cs.mu.oz.au (Robert Elz) (06/12/91)
jp@tygra.Michigan.COM (John Palmer) writes: >UUNET claims its CompuServe's problem and suggests that I contact >them. Excuse me, but the problem would have to be the internal >link between UUNET and CompuServe, How on earth do you conclude that? From the other side of the world I can't guess what the problem might be, but I am sure that you can't simply write off congestion inside compuserve's network without extensive analysis. kre
time@ice.com (Tim Endres) (06/12/91)
In article <1991Jun11.143710.17578@tygra.Michigan.COM>, jp@tygra.Michigan.COM (John Palmer) writes: > UUNET claims its CompuServe's problem and suggests that I contact > them. Excuse me, but the problem would have to be the internal > link between UUNET and CompuServe, so why should I have to call > them? Furthermore, the attitude that UUNET displays (ho hum, its Uh, I would not be so certain. It is certainly possible that UUNET can feed CompuServe at full bandwidth, and that the CS network has a bottleneck on its way to you. Some person at CompuServe should be able to help verify their network's bandwidth. > not our problem) is not the best for a service organization. From > what I understand, many other UUNET customers who call in via Compu- > Serve's V.32 modems are having identical problems. Doesn't this sort of suggest that the problem is with CS? Are you able to dial in direct for comparison? If the direct connection is very slow, then it is obviously a swamped CPU. > Well, at least its better than dialing UUNET direct. A PEP modem > connection couldn't get "110cps. (I tried twice, during different > times of the day: noon and 3 am). This is definitely wrong. I would be very suspicious of my register settings. Here are mine (S58 and S111 are important): E1 F1 M0 Q0 T V1 W0 X1 Y0 &P0 &T4 Version GF7.00-T2500SA S00=001 S01=000 S02=043 S03=013 S04=010 S05=008 S06=002 S07=040 S08=002 S09=006 S10=007 S11=070 S12=050 S18=000 S25=005 S26=000 S38=000 S41=000 S45=000 S47=004 S48=000 S49=000 S50=000 S51:254 S52:002 S54=000 S55=000 S56=017 S57=019 S58:000 S59=000 S61=150 S62=003 S63=001 S64=000 S65=000 S66=000 S67=000 S68=255 S69=000 S90=000 S91=000 S92:001 S93=008 S94=001 S95=000 S96=001 S97=000 S98=003 S100=000 S101=000 S102=000 S104=000 S105=001 S106=000 S107=020 S110:000 S111:030 S112=001 S120:016 S121=000 S130=002 S131:001 S150=000 S151=004 S152=001 S153=001 S154=000 S155=000 S157=000 S158=000 S160=010 S161=020 S162=002 S163=003 S164=007 S169=000 S255=000 tim. ------------------------------------------------------------- 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
tinguely@plains.NoDak.edu (Mark Tinguely) (06/12/91)
In article <1991Jun11.143710.17578@tygra.Michigan.COM> jp@tygra.Michigan.COM (John Palmer) writes: >UUNET claims its CompuServe's problem and suggests that I contact >them. Our TCP UUCP connection to uunet is also timing out during peak times. UUNET in the past has been VERY informative whenever there is a problem through a direct mailing list (and with the volume they work on, them not having more major problems in a year is amazing). I think we should give them all the information we have, and let them find the problem. Anyone who has not followed (and advertised) a blind alley in problem resolution, must have a single user system. If anyone thinks they deserves a refund for survices not delivered, then that is your buisness to pursue. Mark Tinguely North Dakota State University Fargo, ND 58105. (701) 237-7786 tinguely@plains.NoDak.edu || uunet!plains!tinguely || tinguely@plains.bitnet
karl.kleinpaste@osc.edu (06/12/91)
jp@tygra.Michigan.COM writes:
Excuse me, but the problem would have to be the internal
link between UUNET and CompuServe...
Naive conclusion. That's no surprise, coming from you, Mr Palmer.
No, the problem would not have to be the UUNET/CompuServe link. It
could be, but by no means has to be. Rather, and more likely, the
problem is internal to CompuServe's own network, e.g., packet queueing
overruns between their own nodes. Considering what their network is
built from, that's more than a little bit likely.
I could tell a horror story or three about local 9600bps access here
in Columbus with high packet latency due to travel through no less
than 7 CompuServe switching nodes before reaching the final host in
question.
Before making illogical leaps, consider the set of possibilities a
little more carefully, Mr Palmer.
--karljp@tygra.Michigan.COM (John Palmer) (06/13/91)
In article <kre.676686360@mundamutti.cs.mu.OZ.AU> kre@cs.mu.oz.au (Robert Elz) writes: "jp@tygra.Michigan.COM (John Palmer) writes: " ">UUNET claims its CompuServe's problem and suggests that I contact ">them. Excuse me, but the problem would have to be the internal ">link between UUNET and CompuServe, " "How on earth do you conclude that? From the other side of the world "I can't guess what the problem might be, but I am sure that you can't "simply write off congestion inside compuserve's network without "extensive analysis. " What I mean is that it is not a problem with my modem or anything like that and I feel that UUNET should take it up with CompuServe. -- CAT-TALK Conferencing System | "Buster Bunny is an abused | E-MAIL: +1 313 343 0800 (USR HST) | child. Trust me - I'm a | jp@Michigan.COM +1 313 343 2925 (TELEBIT PEP) | professional..." | ********EIGHT NODES*********** | -- Roger Rabbit |
randy@m2xenix.psg.com (Randy Bush) (06/14/91)
> Uh, I would not be so certain. It is certainly possible that UUNET > can feed CompuServe at full bandwidth, and that the CS network has > a bottleneck on its way to you. Some person at CompuServe should be > able to help verify their network's bandwidth. Are we talking uucp-g layered over X.25? This is not going to be something to write home to Mom about. My experience of layering over X.25 is that seatbelts are not required. > Doesn't this sort of suggest that the problem is with CS? > Are you able to dial in direct for comparison? If the direct connection > is very slow, then it is obviously a swamped CPU. I have timed CI$ vs. direct. It came out just as UUNET suggested it might. Evenings it is marginally cheaper then direct PEP, as the CI$ rate has fallen far more than the telco. But all other times go direct PEP. Your mileage will vary. randy -- randy@psg.com ..!uunet!m2xenix!randy
karl.kleinpaste@osc.edu (06/14/91)
jp@tygra.Michigan.COM writes:
What I mean is that it is not a problem with my modem or anything like
that and I feel that UUNET should take it up with CompuServe.
Mr Palmer, you've elevated cluelessness to an art form.
UUNET isn't in control of the CompuServe side of their connection to
CompuServe; CompuServe is. So all UUNET can do, at the very best, is
call them up and relay a small amount of information: "Hi, CompuServe,
UUNET here. We've got a customer experiencing poor throughput to us
when connecting through your network." Now, just what exactly is
UUNET supposed to do beyond that point? Argue with them? Tell them
to fix their network? Act as a low-SNR relay between you and
CompuServe about your modem settings, your local access dial number,
your machine setup, etc ad nauseum?
No. They told you what they know, which is that their end of things
looks fine, and that CompuServe's is broken. If you want CompuServe
fixed (assuming it's broken; personally, your report is unconvincing),
babble at CompuServe.
It's not UUNET's problem, and UUNET is almost certainly utterly
powerless to fix it. The problem is yours and CompuServe's -- so
_you_ take charge of the problem, and deal with CompuServe yourself.
Sprinkling "personal responsibility"
bits across the Usenet this week,
--karljp@tygra.Michigan.COM (John Palmer) (06/15/91)
In article <1991Jun14.121801.27595@oar.net> karl.kleinpaste@osc.edu writes: "jp@tygra.Michigan.COM writes: " "Mr Palmer, you've elevated cluelessness to an art form. " Personal attacks are low class in a business-like group like this. Perhaps you ought to save them for talk.bizarre. "UUNET isn't in control of the CompuServe side of their connection to "call them up and relay a small amount of information: "Hi, CompuServe, "UUNET here. We've got a customer experiencing poor throughput to us "when connecting through your network." Now, just what exactly is "UUNET supposed to do beyond that point? Argue with them? Tell them "to fix their network? Act as a low-SNR relay between you and "CompuServe about your modem settings, your local access dial number, "your machine setup, etc ad nauseum? " There isn't anything wrong with my modem setup or machine. "No. They told you what they know, which is that their end of things "looks fine, and that CompuServe's is broken. If you want CompuServe "fixed (assuming it's broken; personally, your report is unconvincing), "babble at CompuServe. " "It's not UUNET's problem, and UUNET is almost certainly utterly "powerless to fix it. The problem is yours and CompuServe's -- so "_you_ take charge of the problem, and deal with CompuServe yourself. " Hey - I DON'T WRITE CompuServe a check every month - I PAY UUNET! AND A DAMN LOT OF MONEY They provide a service in which they get you a leased line and provide internet access. They act as the liason with the telco's and whom ever provides the inter-LATA leased line. The customer need only call UUNET to get a problem resolved. Part of the service is that the customer shouldn't have to deal with a 20 different people at the BOC's and US Sprint/MCI/ATT, whatever. When I pay my monthly UUNET bill - thats part of what I'm paying for, even though I'm only a dial-up customer. I expect and demand that kind of service. Anyways - someone from UUNET says its probably due to the fact that their machine is overloaded, so that settles it. "Sprinkling "personal responsibility" "bits across the Usenet this week, "--karl Where - personal attacks outside of alt/talk is far from responsible. John "I'm headin to Kentucky for the weekend - YEEHAAA" Palmer -- CAT-TALK Conferencing System | "Buster Bunny is an abused | E-MAIL: +1 313 343 0800 (USR HST) | child. Trust me - I'm a | jp@Michigan.COM +1 313 343 2925 (TELEBIT PEP) | professional..." | ********EIGHT NODES*********** | -- Roger Rabbit |
time@ice.com (Tim Endres) (06/15/91)
In article <1991Jun14.233558.18610@tygra.Michigan.COM>, jp@tygra.Michigan.COM (John Palmer) writes: > Personal attacks are low class in a business-like group like this. Perhaps ^^^^^^^^^^^^^ > you ought to save them for talk.bizarre. FLAME ON EXCUSE ME!!!!!! When did this become a "business-like" group?!?!?!?!?!? This is USENET. The fact that you are attempting to run YOUR business over USENET does not make it a business-like group. The only problem with the original posting was that it did not start out with "FLAME ON". You want a business-like group, go hire on with EDS. FLAME OFF tim. ------------------------------------------------------------- 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