DH> Training going on during connect phase isn't all that reliable.

RS> Possibly valid at V34, not at V32bis tho.

IS> In marginal conditions (i.e on poorer lines and
IS> exchanges) the same is certainly true at V.32bis.

RS> Nope, you are confusing RETRAINS and rate negotiation. Yes, the normal
RS> behaviour is to fall back and fall forward if the characteristics
RS> change, and I do actually see that on one specific line on one system
RS> I call. BUT this is an IMMEDIATE demand for a FULL RETRAIN, straight
RS> after the connect. THATS nothing like normal V32bis behaviour and
RS> I have never seen that except when I call a USR V34+ Courier.

IS> I used to see that when being called on bad lines by a metal-case
IS> 144FM with %E2 set.  Connect 14400/Lap-M (0r 12000 or 9600,
IS> depending), followed by an immediate retrain - not a rate shift.
IS> Now which end decides the data's crook enough to need a full
IS> retrain is pretty hard to find out .. that one was fixed by using
IS> %E1 on the 144FM, and setting a 20-second sigqual monitor here.

Yes, but thats clearly dud behaviour, full retrains shouldnt be
being used, the whole point of the enhancement to V32 to get V32bis
was the much more efficient rate renegotiation which allowed much
better handling of the line characteristics changing during the call.

Its possibly valid on atrocious lines which are too bad for a viable
rate renegotiation, but that clearly isnt the case here where all the
other V32bis calls to anything other than USR Couriers never even see
a rate renegotiation, let alone a retrain. Apart form one known less
than ideal BBS line I call.

AND the Courier is DEMANDING a full retrain
STRAIGHT after the connect. Thats completely nuts.

IS> It's the old problem - if modem A and modem B aren't getting along,
IS> and both work well with modems C, D and E - whose 'fault' is it?

RS> Yes, but mindlessly demanding a full retrain ALWAYS immediately
RS> just after the connect at V32bis is VERY dud behaviour. Both
RS> because its already at the maximum speed anyway, and the rate
RS> negotiation should be used, not retrain, and the good sessions
RS> are always perfect after that mindless retrain, and it clearly
RS> cant be the Supra demanding it coz %e0 has no effect at all.

IS> The last bit doesn't necessarily follow.

Fraid so.

IS> Either end can decide it needs to retrain, the

Nope, %E0 SPECIFICALLY tells my modem to NOT monitor line quality
and ask for a retrain when the line quality is bad enough. So when
I have %e0 set, the OTHER end must be initiating the retrains.

That can be confirmed too by calling another modem which
also has its retrains disabled and deliberately buggering
around with the call say with a voice phone in the circuit.

IS> negotiations are complex enough to be fraught with
IS> possible misunderstandings or disagreements over timings;

You are talking about how the retrain is done, I am talking about
the much more basic question of whether one is even attempted at all.

IS> there's no real way (short of a complete time-logged datascope picture
IS> of the session) to analyse just who's doing what to whom, and when.

Sure there is on the question of INITIATION of a retrain.

RS> Yes, its possible that only the Supra V32bis causes the USR to
RS> have that massive brain fart, but that shouldnt be hard to confirm.

IS> You're still assuming it must be the USR 'at fault'.

It aint no assumption if that particular mindless behaviour is ONLY
seen when calling a USR Courier, AND its completely inappropriate to
do that on a V32bis call, AND the Supra has been told to never retrain.

IS> It may well be, by the V.32bis spec and who's interpreting
IS> it which way, but it could just as well be the Supra.

Come no Ian, there is no way that the V32bis specs can be read to be
saying that a full retrain STRAIGHT AFTER a successful connect when
the line is already at the highest possible speed makes any sense.

IS> These things _very rarely_ turn out to be anyone in particular's 'fault',

Welp, when nothing like that is seen with the USR Sportster V34,
its certainly looking pretty compelling that is a wart in the Courier,
particularly when that particular extremely bizarre behaviour for
a V32bis call is NEVER EVER seen with anything except a Courier.

IS> yet require relaxation of the specs to accommodate other modems -

In fact we KNOW that USR has deliberately chosen to play clever buggers with
the initial handshaking and negotiation between the modems to try to get a
fast connect in V32bis mode. I bet thats actually biting them on the bum.

IS> and sometimes doing that can muck up other
IS> connections that were working fine.  As you yourself
IS> are fond of saying, Rod, "it ain't that simple."

Sure, but you know as well as I do that there is a hell of a tendency
to just try finger pointing and blaming the other end. We have seen
that repeatedly here, trying to blame pauls line, his particular modem
copy, or his lousy setup. Pity that identical behaviour with Poes and
the bulldogs Couriers blows that out of the water so comprehensively.

IS> Usually, but not always, there's a workaround
IS> that can be applied to one or the other modem -

RS> Oh sure, and thats what I have been pursuing, even
RS> if Paul doesnt end up with a USR when he buys one.

IS> Fair enough.  More grist for the croos-connection database mill 

Yeah, certainly interesting. We are unlikely ever die of boredom with modems |-
@EOT:

---