DD> . . .[chomp]. . .

Yep, lots of that .. :)

DD>> I guess the courier feels that if a retrain is necessary
DD>> and the other end can't comply, there is no point in
DD>> continuing the connection.

IS> Yes, and the Rockwell would do that too, if the Courier
IS> refused its request, after trying 'x' retrains.  Not sure
IS> what 'x' is, though I don't think it's externally adjustable
IS> in the Rockwells .. is it in the Couriers?

Apparently not?

DD>> I can't imagine why one would want to disable retrains (in
DD>> any form) anyway...

IS> As I've said a few times recently, disabling _fallforward_
IS> requests in some Rockwells (ie, using %E1 instead of %E2)
IS> can and has solved problems on bad lines, especially
IS> _really_ bad lines, which most 'slickers have never seen.

 DD> With ASL doesn't it make sense that both ends have some sort of control?

Only later Rockwell chips have used split speed.  With these, I'd expect
%E2 would be a more useful default anyway.  Some of the older chipsets
(say, that in Maestro 144FMs and others of that vintage) had a poorer
algorithm and/or timeouts used for determining rateshifting in variable
line conditions, so setting %E1 made the difference between a usable
connect or not, to here.

You'll probably never experience the sorts of lines we had at that time,
and hopefully, neither again will we :)  I do have one caller about 10km
from the exchange, who lives halfway up a mountain via some fairly sus
aerial lines and some fairly soggy pits.  She's had a deal of trouble with
various modems, but is currently using a Netcomm M5 to good effect (where
an E5 of similar vintage just wouldn't cut it, either to here or to an ISP
in Lismore).

I'll have to see how this M7F I'm currently playing with goes in those sort
of conditions, with and without %E2, to see if that aspect has been worked
out ..

Cheers, Ian

--- MaltEd 1.0.b5