BG> Possibly because I agreed with the majority of VE user's
BG> observations that the link rate does actually increase,
BG> often within seconds of the initial connect.

RS> Thats all I have been saying all along, that it does
RS> appear to be doing that, rather than just adjusting the
RS> rate to match changing line conditions during the call.

BG> By the same token, I've had calls where the link rate has
BG> shifted upwards from 26400 to 28800, then at sometime during
BG> the call, it's dropped back again to a logged rate of 21600/24000.

Sure but the point we have been discussing is the general
tendency to INCREASE over the initial connect rate, NOT whether
it ALWAYS does. I was saying that it increases a lot more often
than it doesnt, and that means that that must be a deliberate
design choice made by USR, because otherwise you would expect
an increase to be just as likely as a decrease, and it isnt.

BG> Although there's a LED on the front panel which indicates
BG> when retraining is occurring, I have to agree that a decent
BG> digital display would make life a HELL of a lot easier.

Yeah, only way to go IMO. Unfortunately as far as I know
there is no modem with all the ideal stuff, a really good
front panel display of that stuff, and everything in DSP
so its trivial to change any code if a wart is fixed.

BG> So you're basically suggesting that V.34 should be
BG> slightly more aggressive in its negotiation, are you?

RS> I'd want to see the rationalisation for why they chose to
RS> go that route. There may be a good reason for it with V34.
RS> For example you may be able to show that that approach
RS> does produce the most bytes shove thru the session.

I've since thought about it some more and its possible that it may
actually be a byproduct of USRs obscession with very quick initial
handshaking between the modems. In other words dont analyse the line too
carefully initially, coz thats being done during the session anyway. In
those circumstances, particularly when the very early part of the true
session often doesnt have the highest volume of data being moved, it may
well make considerable sense in the sense of the total session time, to
deliberately go for less that the maximum thruput on the initial connect.

Corse it also appears that they have had a massive
brain fart applying that philosophy to a V32bis connect
which is already at the maximum line speed anyway.

BG> I have my suspicions (unconfirmed) that this may have
BG> well been done to cater for those Rockwell V.34s which, if
BG> they connect at say 28800, will drop out without retraining,
BG> whereas a 26400 connect appears to work just fine.

Dunno, the more I think about it, the more it makes sense to
do it the way the USR VE does, just to minimise the total phone
time, particularly minimising the initial handshake time. If you
step up in line speed very quickly after the CONNECT, then you
havent even paid a penalty in data thruput significantly.

And you get that more likely to succeed stuff as a bonus too.

The only real downside is that the numbers in the CONNECT
string arent very meaningful. But its only fido type
operations that log that stuff very enthusiastically anyway.

BG> The Courier does actually have an undocumented command which
BG> will force it to be more aggressive with its V.34 connects,

Interesting. Certainly looks like someone has put some thought into
it and it isnt just the result of some choice made without analysis.

BG> but given the problem with earlier Rockwells,
BG> it may well be best left alone at this stage.

Yeah, I think its likely to be the best strategy anyway
for V34, tho without some hard numbers on the effect on
the initial handshake time its hard to be too categorical.

The only real problem is the totally
mindless application of it to V32bis calls.

BG> My initial reaction would be to agree, but I can't help wondering
BG> why the manufacturers chose to do it the other way.  And it ain't
BG> just USR either.  Quite a few modems start low, and shift upwards.

RS> Sure, no argument there.

BG> Look at the major problems with V.FC too, where
BG> the modems were so aggressive that they connected
BG> at 28800 all right, but dropped out soon afterwards.

Well, thats just shit code, clearly they
should have fallen back, not dropped out.

BG> I'm also rather disappointed that the major players in developing
BG> V.34 appear to have got their implementations pretty right, but
BG> Rockwell appear to have chosen not to implement the ITU recommendation
BG> 100% (look at the trellis coding and symbol rates for a start).

Dunno, I have always been rather dubious about USRs claims on that sort
of stuff, I have seen too much obvious faking from USR in the past.

I'm not saying they are wrong this time, but I would want
to see the argument from the other side first on that.

RS> I wouldnt be surprised if they have carefully chosen to go that route
RS> for V34 for good reasons, and have mindlessly extended that to V32bis
RS> sessions as well, where it makes no sense whatever. Particularly the
RS> use of a full V32bis retrain instead of a rate negotiation.

BG> If that is indeed what's happeneing, then I must agree.
BG> I can see very little need at all for V.32bis retrains
BG> these days (mediaeval X-bar exchanges excluded of course).

Well, you shouldnt need a retrain at all, thats what the rate negotiation
is for, the much more efficient way to handle varying line conditions. And
it works too, one of the City BBS lines was pretty poor and you could see
it fall back one step and often pick up again later too, without any
retrain at all, just the V32bis rate negotiation. Worked very well.

RS> Even sillier with a V32bis call, the modems negotiate a 14400
RS> connect fine, and then the damned USR virtually IMMEDIATELY demands
RS> a retrain, on every single call I have made so far. Nuts IMO.

BG> Agreed, although it would appear that the vast majority
BG> of modems are not affected by the retrain request.

I'm not convinced on that either, I think its much more
likely that most people arent even aware they are happening

BG> Even the later V.34 Supras work just fine with USRs
BG> (ref. Russell Brooks, who imported quite a few of these).

Thats irrelevant, they are obviously doing the V34 stuff.

BG> Easy to say that the Courier shouldn't be demanding a retrain
BG> immediately following the connect, but if that's its normal operation,
BG> I'd have fully expected to be hearing other complaints about that.

RS> Or maybe its much more visible to me, and I monitor whats
RS> happening much more closely than most people, so I notice that.

BG> Dunno, V.32bis retrains aren't transparent like those
BG> under V.34, and take around 8 seconds to renegotiate.

(Continued to next message)
@EOT:

---