RS> THATS whats relevant to the question we we actually discussing
RS> there, whether it tends to take the conservative route of a lower
RS> initial connect speed which then much more often INCREASES during
RS> the session than decreases. I'm damned sure that SOMEONE said that
RS> in Aust_Modems and I could have sworn it was you.

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.

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

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

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

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.

Sure, no argument there.

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

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> Have you called many (or any) other USR V.34s?  What happens with those?

RS> Both produced IDENTICAL results, with about 5 calls to
RS> each. Both with the same mindless demand for a retrain
RS> straight after the connect and both with the same roughly
RS> 30% rate of falling flat on its face after that.

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.

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

BG> Also, one of the more objectionable and
BG> time-wasting duties I had to perform at CHH

Interesting fellow in many ways, be interesting to
watch how he goes over the years. Jerking staff around
like he did with you aint exactly a terrific idea tho.

BG> was to test EVERY single modem they put up for sale
BG> (although I suppose DOAs _can_ be a tad embarrassing),

Yeah, its a complicated argument. It certainly does really
piss the customers off. OTOH it aint cheap to check the lot.
And shouldnt be necessary if the manufacturing was done properly.

BG> and this was done by calling Mike's own BBS - equipped with
BG> a Courier - and DLing a largish file.  I must have tested
BG> literally 100s of modems in this manner, the bulk of them
BG> being 14k4, yet I didn't once see the problem you describe.

Maybe. It will be interesting to see what comes out of the
close look at just what other V32bis modems get from the USR
VE. I find it rather hard to believe that it only does that
when a Supra calls, but I havent actually tested that carefully.

BG> And there must be a HELL of a lot of people
BG> calling Couriers with their Rockwell 14k4s too.

Yes, but how many can actually SEE an initial demand
by the USR for a retrain and now many would actually
notice if they can is another matter entirely.

RS> Which conveniently eliminates any possibility of
RS> it being Pauls line, or a dud USR at his place, etc.

BG> Dunno, I think it might be wise to grab another 14k4
BG> at your end if possible, and see what happens then.

Thats not saying anything useful about Pauls line or a dud USR tho.
I agree that some careful testing of what other V32bis modems report
that mindless immediate retrain demand would certainly be interesting.

BG> If it fails the same way, I'd also be pointing the finger at
BG> Couriers in general.  All you've proved so far is that YOUR Supra
BG> appears to have a minor incompatibility problem with 2 or 3 Couriers.

Nope, I have proven pretty conclusively a general problem between
the Supra and the Courier. And since disabling line quality monitoring
in the Supra has no effect, it must be the USR demanding the retrain.
It is currently possible that there is something about the Supra
specifically that causes that wart in the Courier, and calling
with other V32bis modems is the way to resolve that question.

BG> Of course, it couldn't be your Supra's ROM at fault, could it?  :)

RS> Nope, not when its only seen when calling a USR VE, particularly when
RS> the line quality to get a V32bis 14400 session isnt exactly what you
RS> might call demanding. Its totally fucked behaviour by the USR VE.

BG> Maybe, maybe not.

Not on the question of the immediate retrain demand. THAT must be
something fucking up the test for the desirability of that or doing
it mindlessly regardless of line quality, and that HAS to be the USR.
Corse its conceivable that it only exhibits that wart with a Supra.

BG> I have no faith at all in the builders'
BG> ability to get it right in such edifices.

RS> Its not the builders that do it with phone wiring.

BG> No, it's usually the electrician (with an Austel licence).

Nope, not in NSW. There aint many who bother with Austel
licences. Particularly for blocks of flats. And that system
wasnt even available when Pauls block was built anyway.

BG> And I still wouldn't trust all of them to get it right 100% of the time.

Oh sure. But we were discussing your claims that its more likely to
be stuffed up in blocks of flats. I think thats distinctly dubious.

--- PQWK202