🚀 go-pugleaf

In article <4bqq0o$8d4@access4.digex.net>,
Sean Connery <bond@access4.digex.net> wrote:
>In article <4bpp4r$39m@zippy.cais.net>,
>Dr. Roger M. Firestone <rfire@cais2.cais.com> wrote:
>I do not personally feel that the problem has been with Digex advertising 
>one speed but not providing it at all....that is not it.
>
>The bigger problem is how long it took to get to the point of finding the 
>fault with the SLC96s.
[...]
>It took many...many moons for Digex to even consider themselves at 
>fault IMHO.  

I thought that by now it was pretty well established that Digex was
_not_ at fault, that they were basically screwed over (legally) by
Bell Atlantic, the reality of the existing tarriff, and some unfortunate
technology.

And although I have not been following this discussion very closely,
even I have been able to pick up that it took forever and forever for
Bell Atlantic to admit to Digex that there might possibly be a 
problem with the SLC design -- after Digex had been hassling them for
ideas and help and trying all sorts of hardware fixes on their end
(at who knows what kind of expense)!

Or did I hallucinate the messages describing adding resistors to
however many phone lines when the most likely-sounding explanation
for the problem was too high a signal level (before Bell Atlantic
finally revealed that the SLC was losing bandwidth)?  And I seem
to recall other possible explanations/solutions being discussed.


It's frustrating as H*** when a problem sits and sits and doesn't
get solved, and even when you get updates saying, "We're trying
something else now," it still feels like nothing is being done.
Folks can be scurrying around like mad and losing sleep, but out
here on the other end of the phone line that's invisible.  But
come on, people:  haven't any of you gotten stuck with a _tough_
technical problem before?  One where you don't have enough
information to be able to say, "Oh, of course, the problem is
_this_," but have to guess at the inner workings of some device
or program by trying hack after hack until one of your tries 
provides a clue?  

I've been there, and let me tell you -- it's even more frustrating
that sitting on your butt and wondering why someone else is taking
so long to fix it.

I can just imagine the looks on the faces of the Digex folks when
Bell Atlantic finally -- after they'd wasted God knows how much 
time, time that cost real money in payroll -- finally told them
that it _wasn't_ something they could have fixed after all and 
that it was all because of the SLC that Bell Atlantic supplied
and that because of the way the regulations are written there was
no recourse.  I can imagine their faces, and I'm glad I wasn't
in the room.

I can just imagine how the various techies must have felt when 
they found out that this brick wall they'd been banging their
head against lo these many months didn't have a secret door
hidden in it after all and wasn't going to crumble and someone
else had been sitting on information that could have saved them
a whole lot of headaches.

Again:
>The bigger problem is how long it took to get to the point of finding the 
>fault with the SLC96s.

And so I ask you -- without the benefit of knowing (as you do
_now_) what to look for, how long would it have taken _you_,
properly equipped with a reasonable set of diagnostic tools,
to have figured out for yourself 1) that the problem was with
the SLC96, and 2) that it was a design problem and not a configuration
one?  Remember, you're not allowed to mess with the configuration
yourself (have to go through Bell Atlantic for each new try),
you _don't_ have specifications for the SLC96, and you can't 
afford to take the whole system offline for any of your tests
('cause you're still running all your dial-up customers through
it at the same time).

It's like trying to figure out how a wristwatch works without
being allowed to open it, X-ray it, or read a book about clockwork.
Or worse, it's like trying to figure out why this one watch is
running slow, but only when certain people wear it.  You can 
guess there's a spring involved somewhere because you have to
wind it, but what _is_ that ticking noise and could it be
relevant?  (Remember, no documentation!)

And:
>I do not personally feel that the problem has been with Digex advertising 
>one speed but not providing it at all....that is not it.

No, I guess not.  It's about feeling frustrated and powerless and
wanting to take it out one somebody.  Well _grow_up_, goddammit.
You think _you_ felt frustrated and powerless?  Walk a mile in
Digex's moccassins, fercryinoutloud.

Bell Atlantic finally provided the clue that could have saved _all_
of us -- techies, management, and customers -- months of headaches
and frustration, and we're still hearing folks whine at Digex about
it?  What do you _want_?  What can be _done_ now?  If you're going
to kvetch like this, it sounds like you're still asking for 
something, but I have no clue what.  Figure it out -- ask your
pshrink to help if you have to -- and look at whether what you're 
asking/wishing for is at all reasonable.  Then state it or drop it.  
And if Digex says what you're asking for is something they can't or 
won't do, lay the matter to rest.

Hint:  If what you want involves time travel, it's not reasonable.
If what you want is an apology from Digex for sweating blood and
spending lots of time and money on something that it turned out 
they had no control over, try to think first about how that request
is going to feel to them.

My advice?  Let it go.  It's gotten repetetive and boring.  Fortunately, 
I'm just another customer like you, so I can just killfile this subject.


To recap:  The speed problem turned out to not be Digex's fault or 
something Digex has any control over.  The problem is not technically
Bell Atlantic's fault either, because according to current regulations
it's not officially a _problem_.  The ill will and frustration remain,
and _that_ could have been avoided if Bell Atlantic had been more on
the ball figuring out that the SLC96 was losing bandwidth OR had been
more forthcoming with technical documentation on it (so that Digex 
could have spotted the problem -- I'm sure they know how to read
manuals).  We ain't gonna take it out of Bell's hide (much as many
of us would like to), so why are you _still_ beating up on Digex?

-- 
        D. Glenn Arthur Jr./The Human Vibrator, glenn@access.digex.net
         <a href="http://www.access.digex.net/~glenn>Glenn's page</a>
 "Being a _man_ means knowing that one has a choice not to act like a 'man'."
  Due to health problems my newsreading time varies; I might miss followups.