Rod, at 09:23 on Feb 01 1996, you wrote to Bill Grimsley...

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.

By the same token, I've had calls where the link rate has shifted upwards
from 26400 to 28800, then at sometime during the call, it's dropped back
again to a logged rate of 21600/24000.  Although there's a LED on the front
panel which indicates when retraining is occurring, I have to agree that a
decent digital display would make life a HELL of a lot easier.

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 have my suspicions (unconfirmed) that this may have well been done to
cater for those Rockwell V.34s which, if they connect at say 28800, will
drop out without retraining, whereas a 26400 connect appears to work just
fine.  The Courier does actually have an undocumented command which will
force it to be more aggressive with its V.34 connects, but given the
problem with earlier Rockwells, it may well be best left alone at this
stage.

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.

Look at the major problems with V.FC too, where the modems were so
aggressive that they connected at 28800 all right, but dropped out soon
afterwards.  I'm also rather disappointed that the major players in
developing V.34 appear to have got their implementations pretty right, but
Rockwell appear to have chosen not to implement the ITU recommendation 100%
(look at the trellis coding and symbol rates for a start).

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.

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

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.

Agreed, although it would appear that the vast majority of modems are not
affected by the retrain request.  Even the later V.34 Supras work just fine
with USRs (ref. Russell Brooks, who imported quite a few of these).

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.

Dunno, V.32bis retrains aren't transparent like those under V.34, and take
around 8 seconds to renegotiate.  Surely others would notice something like
that?  I know I didn't with all of those modems at CHH.  And although I
wasn't looking for anything like that, I doubt I'd have overlooked such an
occurrence.

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

RS> Interesting fellow in many ways,

A two-faced hypocrite, in fact.

RS> be interesting to watch how he goes over the years. Jerking staff around
RS> like he did with you aint exactly a terrific idea tho.

He's still holding a MAJOR grudge about that, too.  Did I ever end up
telling you the full story?  Can't remember now, so I'll do so again.

I was employed to replace a fellow who had burned himself out, but after 6
weeks, he (Roger) decided to come back, so my services were no longer
required.  Unfortunately, he chose not to be honest about this, and used
some lame excuse about my not getting on with the other technical staff. 
Utter bullshit too.

Anyway, he called me into the office one afternoon, handed me a cheque for
my pay to that date, and wished me well in the future.  What he DIDN'T do
was pay me accrued holiday pay, nor a week's pay in lieu of notice, and
when I claimed this amount (to which I was fully and legally entitled), he
became extremely stroppy.  Still had to write me another cheque for around
$750 though.  :)

Since then, he's attemnpted to make things really difficult for me, WRT the
replacement of a faulty 1.2Gb WD drive an my father's machine.  I also
returned dad's faulty MS mouse late last year, and 9 weeks later, a
replacement STILL hasn't arrived!  So much for their purportedly excellent
customer service.

Re the drive, because I need to change it myself (Jack's not at all
technically minded), I need to take a replacement HD with me, swap the
data, then return the faulty HD to CHH.  Mike spat the dummy at this
suggestion, demanding that I return the drive to CHH, pay them $40 to
transfer the data, then wait until they receive a replacement HD from
Westan.  Needless to say, that simply wasn't acceptable from the POV of the
timeframe involved, so I suggested to him that I actually BUY a new HD
outright, take it with me, do the work required, then return the faulty
drive to him, at which time he either refunds the cost of the replacement
drive, or just tears up my cheque, doesn't really matter either way.  He
didn't like that idea either, but when I pointed out to him that there
wasn't a damn thing he could do to prevent that, he finally acquiesced
(then told me that as WD no longer make 1,2Gb drives, I'd have to pay
$180-odd for an upgrade to a 1.6Gb drive).

Yeah, it looks like he's trying awfully hard to make life difficult for me,
but if he wants to involve Jack in this pettiness, he's going to get a very
nasty shock.  Maybe a few messages re his attitude in Z3_TECH or AUST_ADS
would help him see the error of his ways?  

Fuck him, maybe I'll do so anyway.  :)

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

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

Sure, but DOAs are simply a fact of life, avoidable only by checking every
single modem as it comes off the production line.  One could argue that
this should be done too, but it just adds more to the overall cost anyway.

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.

RS> Maybe.

No "maybe" about it, Rod, it's quite true.  I've nothing to gain
by telling porkies either (unlike that fuckwit mate of yours, RTL).  :)

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

Well, I tested most of the currently available brands of V.32bis modems
(I've ignored V.34s here, as it appears to be a V.32bis problem), and not
one of them failed to connect at their full speed of 14400 bps.  Of course,
all of these were Austel models, so it wasn't possible to test a Supra.  :)

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

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

Your Supra aside, does it really matter though?  If the calling modem isn't
being adversely affected by the retrain request, surely it makes no
difference whether the request is being issued or not.

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.

RS> Thats not saying anything useful about Pauls line or a dud USR tho.

No, not now that you've had the same results from Dave and Poe.

RS> I agree that some careful testing of what other V32bis modems report
RS> that mindless immediate retrain demand would certainly be interesting.

Yeah, but it's not a particularly easy thing for an end-user to get hold of
a swag of 14k4 modems for testing...

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.

RS> Nope, I have proven pretty conclusively a general problem between
RS> the Supra and the Courier.

The Supra V.34s don't exhibit this problem, so to date, you've really only
proved that YOUR specific Supra barfs at the USR.  I'd like to see some
hard evidence that OTHER V.32bis Supra owners are seeing the same thing
before I start pointing my finger at the Courier.

Regards, Bill

--- Msgedsq/2 3.20