PE> Could you do me a favour and call me with your Dataplex modem

IS> No indication of retraining or any delays here
IS> (apart from a longish wait till hangup after receiving
IS> your filelist?) What do your stats have to say?

PE> I will insert them below.  Not that they give me
PE> any info. The info I was after was whether YOU would
PE> see a retrain request reported on your modem.

IS> Yes, I was watching that call very closely.

Fine, that is useful evidence.

IS> Your log entry shows clearly enough that ring to connect was about 11
IS> seconds; average, and nowhere near time for a full retrain after trainup.

Thats useless, the retrain happens AFTER the connect. And
thats nuts too. My dud call times are the same there as yours.

IS> Nine seconds later it was into session - again, about average for YooHoo.

Again, that ones not that useful either, mainly because some of
that does get thru BEFORE the USR mindlessly demands the retrain.

Its not at all clear where you are timing this one, but my dud calls
which show the retrain get about that for what you are likely calling
'into session', in fact the log shows the REQ received before then.

One oddity is that the retrain doesnt appear to be
as long as you would expect from the V32bis docs.

IS> Whether it only happens when some/all Supras of that vintage call
IS> Couriers, is perhaps what's worth finding out. I rather doubt USR
IS> would be interested in investing development time if it doesn't effect
IS> more than a few oldish modems, though it may cover some generic range

Well, turns out thats not very relevant
when the Sportsters dont have and problem.

PE> Yeah, but all that does is lump USR with every other
PE> manufacturer. You're on your own when you walk out the door.

IS> That hardly appears to be the case.  Until we get reports of
IS> other V.32bis modems having this problem with Couriers, there's
IS> nothing to go on.  If you expect every modem to work with every
IS> other modem, especially older models no longer in development,
IS> your expectations are much higher than those of any modem
IS> manufacturer I've come across. How are Supra handling enquiries?

I hadnt said anything to them, mainly because I wanted to have more
complete info on the range of USRs that exhibited the problem first,
particularly Austel/US domestic. Turns out that the Courier/Sportster
was more important and now the disabling of V32terbo on the Courier
is even more compelling evidence that its some quirk in the Courier.

I also want to do more V32bis calls to Couriers to see how
many do exhibit that quirk, but thats harder to do when
most users wouldnt notice the retrain happening anyway.

Seems pretty clear its a USR problem tho, tho it may well not
be seen by all V32bis modems calling one. Particularly nutty
that its demanding a retrain straight after a connect when
its already at full speed. And only when V32terbo is enabled.

IS> Thanks for the log.

PE> # 09 Feb 02:29:31.53   USRobotics Courier V.32bis Dual Standard V.34+ Fax L
PE> # 09 Feb 02:29:32.03   Modulation               V.32/bis/terbo

IS> Terbo?

It says that even when terbo is disabled. Presumably its
just not bothering to distinguish the actual one achieved
in that line, leaving you to work that out from the other
detail like the speed figures specifically.



IS> Hmm, have you already had Binkley issue an ATZ at this stage?

IS> [..]

PE> # 09 Feb 02:29:32.37   Blocks resent                 0 # 09 Feb
PE> 02:29:32.40   Retrains Requested            0 Retrains Granted       
PE>       0 # 09 Feb 02:29:32.43   Line Reversals                0 Blers 
PE>                        0 # 09 Feb 02:29:32.46   Link Timeouts        
PE>         0 Link Naks                     0 # 09 Feb 02:29:32.50   Data
PE> Compression       V42BIS 2048/32 # 09 Feb 02:29:32.50   Equalization 
PE>          Long # 09 Feb 02:29:32.53   Fallback               Disabled

IS> Er, fallback disabled where?  It sure isn't here (%F1).

PE> # 09 Feb 02:29:32.53   Protocol               LAPM 128/15

IS> Hmm, no 256 byte frames, despite 'Connect 14400/Lap-M/Compression'
IS> here ..

PE> # 09 Feb 02:29:32.56   Speed                  14400 # 09 Feb
PE> 02:29:32.56   Last Call              00:00:47

IS> # 09 Feb 01:34:41 BINK 000:47    -- modem reported time online # 09
IS> Feb 01:34:42 BINK 007       -- sig. qual. out of 7

IS> .. which is all the stats data I'm reporting, with 'Aftercall 2
IS> ATKS69?'

IS> Ian
@EOT:

---