(Continued from previous message)

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,

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

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.

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

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

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.

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

PE> So it trains up after every call by design?
PE> Ok, then why doesn't ATI6 show the retrain?

DH> 'Cause it's not a genuine retrain, which would
DH> take extra time. It's a forced "fall forward".

RS> It is a genuine retrain tho, rate negotiation doesnt produce
RS> the same display on the front of a Supra. And its already at
RS> the maximum rate anyway, pointless to see if you can go faster.

IS> Still looks like a setup problem (or faulty unit) to me.

Cant be either when Poes and the bulldogs behave PRECISELY the
same. That particular set of calls was very useful because they
do so definitively eliminate any possibility of a dud setup, a
particular dud modem, or a dud phone line even, at Pauls.

IS> Whether the problem is related to the Supra or not will
IS> show by other Courier owners experiences with them.

Yeah, still more work clearly needed, even just with non
Austel Couriers. I just havent got around to it, had a hassle
turning the USR_Modems echo on thats now been resolved.

IS> Your indication that it happens with Poe's and Davids (?) as well, would
IS> indicate a Supra/Courier problem, perhaps.  Doesn't happen here, though.

Yeah, I would have been rather surprised if all V32bis modems
get that calling a Courier, but its not a trivial thing to get
non techys to report on, whether they do get retrains immediately
after the connect or not. I was leaving that till I saw if Supra
already knew of the problem, or USR for that matter.

DH> Don't know the V34 spec well enough to hit the exact terminology.

RS> Its usually called rate negotiation.

IS> Yes, as (optionally) done by V.32bis too - though not all do it that
IS> well.

DH> Bloody HELL.  That's a serious indication of drastic problems.

RS> You could say that |-)
RS> Specially when its only seen when a USR V34+ is called.

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? 

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

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

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

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

---