IS> It's certainly common to every USR Courier for many years, but it's not
IS> common to other brands, no.  This quite often comes up in the BINKLEY

 PE> Also, what possible rationale can you think of in USRs defence
 PE> for sending "OK" at 38400 but "RING" at 57600? 
My terminal
 PE> can't be set to both speeds simultaneously.  And there's
 PE> further info from Bill (not verified by me yet) that ATZ will
 PE> fail to auto-baud detect for the subsequent RING, but any other
 PE> command, such as AT&F1, will!

See my msg to Bill; ATZ should restore all &W settings.  I'm not going
to buy into arguing about what USR ought or ought not to do with their
modems.

IS> Must be setup differently to any of the ones I've called at V.32bis; I've
IS> never seen one retrain on me after a 14400 connect, and yes, I get good
IS> indication on the front panel of retrains, and when the modem has fallen
IS> back (Dataplex DPX-596) .

 PE> Could you do me a favour and call me with your Dataplex modem
 PE> and see if this is true of my modem too?  My system is 3:711/934,
 PE> phone 02-436-1785.  FREQing "FILES" will be a good enough test.

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

IS> problem is related to the Supra or not will show by other Courier owners
IS> experiences with them.  Your indication that it happens with Poe's and
IS> Davids (?) as well, would indicate a Supra/Courier problem, perhaps.
IS> Doesn't happen here, though.

 PE> When you say "doesn't happen here", are you referring above to your
 PE> Dataplex modem, or are you saying you have a Courier online and no
 PE> Supras have problems?  If the latter, Rod can call you and try.

No, I've the DPX596 only, currently.  What doesn't happen here is any
connect difficulties, obvious retraining or rateshifting, nor any other
problems when calling any Couriers, to date.  No Supras call here, to my
knowledge.

IS> It's the old problem - if modem A and modem B aren't getting along, and
IS> both work well with modems C, D and E - whose 'fault' is it?
 IS>  Usually, but
IS> not always, there's a workaround that can be applied to one or the other

 PE> Exactly, it needs to be analysed by a manufacturer and then
 PE> a workaround done.  Having seen manufacturers (Digicom, Maestro,
 PE> Supra)'s responses to the LAPM double-send problem, I wouldn't
 PE> hold out any hopes of seeing this fixed.

If it was happening from many V.32bis modems calling Couriers, I guess we'd
have heard about it?  Whether it only happens when some/all Supras of that
vintage call Couriers, is perhaps what's worth finding out.  I rather doubt
USR would be interested in investing development time if it doesn't effect
more than a few oldish modems, though it may cover some generic range ..

Them's the breaks; I had to get new firmware for mine about 2 years ago,
when Rockwell released a new chipset (the first V.FC one, as used in early
Maestro V.FCs and a few others) with some quirk that killed LAPM
performance, after mine had been stable with virtually every V.32bis modem
for 4 years prior.

Do I gather from later streams of messages that new flashware may have
fixed this, anyway?

Ian

--- MaltEd 1.0.b5