IS> I've never seen one retrain on me after a 14400 connect,
IS> and yes, I get good indication on the front panel of retrains,

 RS> Do you actually look at the front of your modem to notice tho ?

You bet.  Until quite recently I've run with the speaker on more often than
not, to the point where I usually knew exactly who was calling.  Lately
I've been silent running (except on o/seas calls), so I tend to watch the
lights more.  See my message to Sunny, re that :)

IS> and when the modem has fallen back (Dataplex DPX-596) .

RS> For V34, sure, V32bis, mad.

IS> It's never a trivial matter to properly setup a modem of
IS> this type, if you're getting away from fatory settings.

 RS> It cant be that when Poes and the bulldogs behave exactly the same.

No, you're right.  Looks more like a problem between Couriers and your
model Supra all the time.

IS> Of course, Paul may have lucked upon a crook one; no modem
IS> manufacturer has a 100% success rate with deliveries.

 RS> Ditto.

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 change,
 RS> and I do actually see that on one specific line on one system I call.
 RS> BUT this is an IMMEDIATE demand for a FULL RETRAIN, straight after the
 RS> connect. THATS nothing like normal V32bis behaviour and I have never
 RS> seen that except when I call a USR V34+ Courier.

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

[.. cutting heaps, not to go round in circles ..]

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
 RS> immediately just after
 RS> the connect at V32bis is VERY dud behaviour. Both because
 RS> its already at the
 RS> maximum speed anyway, and the rate negotiation should be
 RS> used, not retrain,
 RS> and the good sessions are always perfect after that mindless retrain, and
 RS> it clearly cant be the Supra demanding it coz %e0 has no effect at all.

The last bit doesn't necessarily follow.  Either end can decide it needs to
retrain, the negotiations are complex enough to be fraught with possible
misunderstandings or disagreements over timings; there's no real way (short
of a complete time-logged datascope picture of the session) to analyse just
who's doing what to whom, and when.

 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.

You're still assuming it must be the USR 'at fault'.  It may well be, by
the V.32bis spec and who's interpreting it which way, but it could just as
well be the Supra.  These things _very rarely_ turn out to be anyone in
particular's 'fault', yet require relaxation of the specs to accommodate
other modems - and sometimes doing that can muck up other connections that
were working fine.  As you yourself are fond of saying, Rod, "it ain't
that simple."

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.

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

Ian

--- MaltEd 1.0.b5