PE> David Drummond saw the Supra problem.

RL> And I'll say again. The supra that I used to D.D.s USR never
RL> failed to connect at top speed at any stage. Supra 288i.

RS> That doesnt actually prove a damned thing. Clearly it would negotiate a
RS> V34 or VFC session. The problem is with V32bis sessions, and the weird way
RS> that a Courier attempts to see if V32terbo is possible. It aint ever gunna
RS> even contemplate V32terbo when its called by a V34 or VFC capable modem.

RL> OK, then my v32bis Avtek also connected without fault (and still does).

Sure, certainly some V32bis modems dont have a problem.

RL> Wouldn't this come down to a problem with the Supra,
RL> if it is the only v32bis modem to have this problem??

Nope. The problem is essentially that the Courier has a rather
weird way of working out whether V32terbo is possible. It connects
at V32bis, and does that perfectly every time even with the Supra
V32bis. It THEN attempts a retrain, because there is no way to ask
a V32bis modem 'can you do V32terbo' You have to use some kludge
instead like that. That does sometimes fail with a V32bis Supra.

The fundamental problem is actually that V32terbo was well known to
be a rather nasty kludge patched on later, PARTICULARLY on that robust
compatibility with the vast range of V32bis modems already in the field.

The fact that the V32bis Supra has no problem at all with V34 and VFC
shows that when the capability negotiation is done properly, you dont
get that problem with the V32bis modems which know nothing about the
new modes. Thats what a robust negotiation protocol is all about when
you want the best results on full backward compat. It takes some time
to design and test that, and V32terbo was a crude kludge used without
bothering to do that, because that allowed it to be quick to market.

You cant go blaming the inevitable visible warts with the mass
of modems already in the field on them, the problem is the kludge
that V32terbo is, and the weird way the Courier chooses to see
if V32terbo is feasible. It can bite with some V32bis modems.

RS> We KNOW that V32terbo is a monster kludge, particularly on capability
RS> negotiation with V32bis modems that know nothing about V32terbo,

RL> a la my Avtek..

Proves sweet fuck all, any kludge works part of the
time or there wouldnt be any point in using it at all.

There have other problems with other V32terbo modems like the Spirit
Thunder when called by V32bis modems too. In fact its quite trivial
to work around that with a V32bis Supra. The problem is that in that
case, when its used as a BBS modem, there is no way to tell people
in advance what to do to their modem to get a good connect.

Just another visible wart with a rather crude kludge,
V32terbo. Its no surprise that we see some, and why V34 and
VFC have a much more robust capability negotiation design.

RS> thats part of why V34 took so long to formalise, it was
RS> attempting bulletproof robust capability detection with
RS> the vast number of modems in the field that knew nothing
RS> about the later protocols. It achieved that, if you disable
RS> V32terbo in a Courier, the problem is completely eliminated.

RL> In respect to your Supra...The problem doesn't manifest itself with mine.

Says nothing useful at all about where the fault lies. The
problem is that the capability negotiation of V32terbo is
fucked. That inevitably produces visible warts with the V32bis
modems in the field which know nothing about V32terbo, and is
why V34 and VFC do it much better, so you dont get that problem.
@EOT:

---