[CLUE-Tech] DSL QoS monitoring.

[BOF]

Hello,

I am glad to see that the Americanisp was able to solve the problem of not being
able to connect to them between 0500 - 0800. Had they been able to solve this
problem in September, I would still be a customer of theirs.

Based upon the information in Brad's message, it would that appear that my blaming
Americanisp as the SOLE cause of the connection problem was unjust, as the fault
also appears to be QWest's. For this unfairness, I publically apologize. Since Brad
replied to clue-tech, I will post this here also.

I do not want it to appear that I have an ax to grind for Americanisp. I do not. It
was simply that, although I had been happy with Americanisp's service up until the
time of these connection problems, when they were repeatedly, over a period of at
least a month, unable to solve what I saw as a major problem, I felt that I had
every right to try another ISP. There are simply too many ISP's in Denver not to
have to pay for and put up with poor service from one of them. Unfortunately, if the
cause of the problem is as Brad has stated it is, as long as Qwest is the virtual
sole provider of residential DSL in Denver, we may have to.

BOF

Brad wrote:

> Inline-
>
> On Fri, 26 Oct 2001, Cyberclops wrote:
>
> > I can't speak to your problem, but there have been a lot of similar problems
> > with TechAngle's service lately.  They say it is the phone company's fault.  I
> > can't say.  Sometimes I do believe it is the phone company and other times it
> > seems more like a glitch in the TechAngle service.  Whatever the cause, it's
> > the weak link in the Linux operating system.  I use Libranet Linux (Debian) and
> > it's absolutely a solid performer, but I can't say the same for the ISP
> > services associated with Linux.
> >
> > B O'Fallon wrote:
> >
> > > Dan Harris wrote:
> > >
> > > > I used to use AmericanISP also
> > >
> > > About a month ago, I switched from AmericanISP to PCIsys. I had been a
> > > customer of AmericanISP for almost 18 months.
> > >
> > > At random intervals their service would go down. When I first started using
> > > them, this happened perhaps once a month, once for two days, but more
> > > recently might be for just a couple of hours every other month.
> > >
> > > The reason I finally left was because I could not connect to them between
> > > 0500 - 0800 each morning. I use DSL and if I left the system on overnight,
> > > and the connection was not broken, I had no problems with getting my mail
> > > and browsing. But if the connection got broken (and it got broken a lot --
> > > just about every day), I could not connect at all. It was like they were
> > > non-existant.
>
> Hmm.  About a month ago- we found a cleanup script which
> caused this problem for some of our customers- where they
> could not connect early in the mornings.  It has been
> fixed since.
>
> > > Now they swore up and down that I was not connecting, and that the problem
> > > was with Qwest's DSL service. And, of course, Qwest swore up and down that
> > > it was AmericanISP's problem. Qwest's line checks showed that I was
> > > connecting to AmericanISP at that time, but it was like they were ignoring
> > > me: I would get "Hostname not found" and pings would come back timed out.
>
> We have been documenting many cases where Qwest's Interprise
> ATM DSL network causes this problem.  Qwest will always
> swear it is the ISPs problem if the customer can 'train' to
> the Central Office hardware- no matter what the problem
> really is.
>
> In *every* case, we have to get a 3-way conference call
> going with the customer, us, and Qwest- just to proove to
> qwest that their ATM network sucks (and eventaully open a
> interprise trouble ticket for resolution).
>
> Our diagnostic abilities are limited to a few critical
> facts-
> Does the user hit a DSL gateway on our facility?
> Does the user hit our RADIUS authentication server?
>
> In all of these cases, the answers to the above questions
> are both 'no'.  Qwest was simply not delivering the data to
> our facility.  The user will show the line being trained,
> but will not be able to authenticate or ping anything.
> Qwest will say it it our fault because the customer's line
> trains.  The process takes a minimum of three hours per
> subscriber to diagnose with qwest's help.
> Fortunately, Qwest only breaks about 2% of our customers.
> Still enough to file weekly PUC complaints though.
>
> > > So while they swore up and down, I just swore. I finally got tired of not
> > > being able to get my morning dose of Slashdot until 0830 or 0900, and having
> > > to rearrange my schedule for the rest of the day, so I dropped them.
> > >
> > > To this day, I still think that they had a block out period on me. This
> > > problem never occurred at any other time of the day. Of course, they said
> > > that they didn't, but it seemed suspicious that it could have been anything
> > > else.
>
> I apologize for the cleanup script problem.  If we had found
> it when you were still a customer, we would have given you
> downtime credit.
>
> You see- (I can actually explain the process to technical
> people) Our customer data is stored in a MySQL database.
> This database is constantly queried to generate
> configuration files, password files, DNS zone files, etc,
> etc... Just about everyting right down to Cisco RSP VLAN
> configuration for colocation customers and hand geometry
> backup data for hand readers in our facility.
> The cleanup script that kept you from connecting had a flaw
> with it.  When the database went down in those morning hours
> for backup and self-check, the script was not aware of this,
> and overwrote a config file ommiting SQL gathered info.  It
> now properly checks for these things, and everything works
> great in that department.  I assure you, we had no
> block-outs on you or any of our other customers.  Filtering
> or blocking any of our customers or their content strongly
> violates our policies.
>
> > > I have (not yet) had this problem with PCIsys. I can connect at any time,
> > > just like a real ISP.
> > >
> > > But I never noticed any problem with slowdown in their connections. My
> > > downloads were usually about the same speed as with PCIsys.
>
> We do not put any download restrictions on our clients.
> Qwest will set the train-rate for the line, and we will pass
> whatever they can push through that ATM network.
>
> > > BOF
>
> Thanks,
> Brad Baker
> Director: Network Operations
> American ISP
> brad at americanisp.net
> +1 303 984 5700 x12
> http://www.americanisp.net/
>
> _______________________________________________
> CLUE-Tech mailing list
> CLUE-Tech at clue.denver.co.us
> http://clue.denver.co.us/mailman/listinfo/clue-tech