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 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
connect cost.

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.