This is a discussion on Re: Can ISP detect when dial-ins are 'overloaded' ? - Networking ; On 2008-08-27, problems@gmail wrote: > > Surely ISP's can detect when the 'queue of dial-ins has > > increased so that the wait until next-stage will be excessive' ? > > > My ppp-script is set to [say] 99 seconds ...
On 2008-08-27, problems@gmail
> > Surely ISP's can detect when the 'queue of dial-ins has
> > increased so that the wait until next-stage will be excessive' ?
> > My ppp-script is set to [say] 99 seconds to exit if PAP hasn't
> > confirmed. This means that when the ISP's load is high, I don't
> > get an engaged signal, but rather I get the cost of a dud-call
> > and a PAP timeout exit/abort-call.
> > WTF don't the ISP[s] just send an engaged signal to their
> > input-modem/s, to save their clients unnecesaary costs ?
Burkhard Ott wrote:-
> the problem is more the quality of your line
Bill Marcum wrote:-
> Shorten the timeout in your script, and maybe change the
> modem settings so that it doesn't wait as long for a carrier.
> Of course the details depend on whether you use Windows
> or Linux, which Linux distro, which versionof Windows -
> you didn't say and you cross-posted.
> Microsoft tends to drop support for "obsolete" hardware.
> Does Vista even do dial-up?
Is this really SO difficult to understand !?!
If you don't realise that internet communication via dialup
[and also not via dialup] entails a series of traffic flows,
consider the following analogy.
You plan to make a pysical journey thus:
1. collect your documents.
2. lock the house.
3. walk to the bus stop.
4. board the bus
5. walk from the bus to your destination.
If there's a bus 'strike' causing busses to be much
delayed, and you KNOW of such then you can make an
intelligent decision to re-schedule your journey to another
Similarly the ISP's system knows that congestion is
causing an extra wait before the client is PAP-confirmed.
And by feeding back a telco engaged signal to before
receiving modem will save their client the futile telco
Similarly if you KNOW that there will be a long
queue/wait at a facility, you can intelligently decide to
NOT start your 'journey' and rather 'try another time'.
But NOT if the 'signal' is not fed back from the
over-loaded facility to the client.