[NCLUG] ISP suggestions
Frank Whiteley
techzone at greeleynet.com
Sat Aug 3 22:27:55 MDT 2002
---- Original Message -----
From: "J. Paul Reed" <preed at sigkill.com>
To: <nclug at nclug.org>
Sent: Saturday, August 03, 2002 7:53 PM
Subject: Re: [NCLUG] ISP suggestions
> On Sat, 3 Aug 2002, Frank Whiteley wrote:
>
> > Some routers are capable of delaying pings as lower priority.
>
> Yeah, but we're talking on the order of ms, there... here, we're talking
on
> the order of 10s of seconds (into the minutes).
>
Yeah, the file is pretty strange.
> > Are you doing anything else during this time? If you are using the
pings
> > to keep this connection alive, this is against FRII's AUP as dedicated
> > access <> unlimited access.
>
> Yup... I'm doing normal surfing/pulling email down/etc. I keep the ping up
> in a remote window so I can see if it's Internet slowness, or if the
> connection's totally been lost.
>
> I'm running a ping inside of a 'script', so I can capture the output and
> attach it so you can see what I'm talking about; it's a very odd condition
> which I've never seen before.
>
Never seen it before either.
> (update: it happened while I was reading this email and doing nothing
> else... so, see attached/annotated file for details; so, could this be
> modem 'retraining'? I never had this problem with my trusty 28.8, but that
> was on a different line (same house, though) and was 4 years ago.
>
Doesn't look like re-training. V.90 is much more susceptible than V.34 or
lower, plus you'd likely lose packets.
> > The techs can see some of the reasons for connectivity issues, e.g. lost
> > carrier, remote terminate, idle out, ppp drop channel (load based) on
> > multilink. However, they can't see retrains or renegotiations on
dynamic
> > IP circuits as they are using ICG ports.
>
> Yeah, I noticed that... another "win" for their customers... selling us
> ports they don't even own/maintain/are capable of debugging.
>
Very few ISPs maintain their own ports any longer. As I understand it, FRII
was to have had the same granularity as before, but ICG didn't come through.
There was also another issue that cropped up, that is, if a user
disconnected and that port was accessed again too quickly, there were
frequently routing problems. ICG built some latency into releasing the
ports to allow the connection to reset properly. I don't know the technical
specs, but when the stock market was thrashing a week ago Monday, they hit
100% port utilization. At one point, busy signals were still being
generated for a few seconds when ports where churning rapidly and load was
only at 90%. So although the latency is relatively short, extraordinary
conditions can cause odd results. I like the modem on-hold idea, it's
supported, but the timing is wrong according to original detection of the
problem. FRII says they haven't tested it yet, but does sound like a
plausible reason for what you're seeing, except for the V.92 implementation
date. Maybe before you were seeing the routing issue, now something else.
> > Try dropping your max speed by 1.3-3.9k and see if it doesn't disappear.
> > I've found that tuning for a 'sweet spot' does a lot for connection
> > reliability and overall throughput.
>
> I'll try that... I started doing some tuning of my own before I had to
> leave, but I didn't get very far... and it's hard with an intermittent
> problem like this.
>
Agreed.
BTW, is there call-waiting on either number? If so, you are initializing
calls with *70, ?
TIA,
Frank Whiteley
More information about the NCLUG
mailing list