PE> After receiving an "AT" command at a particular baud
PE> rate, the modem does not adjust to that baud rate, and
PE> instead stays at the rate at the time of last "AT&W".

DH> That's common to nearly every high performance modem I know of nowdays.
DH> Any change in the locked baud rate to the UART requires a fresh AT&W.

I'm yet to be convinced it is actually all that common.

PE> The last &W was done at 57600.  I then go and use 38400.
PE> I type in ATZ.  It auto-detects the AT and sends the response,
PE> "OK" back to me at 38400.  I then proceeds to send the
"RING"
PE> word to me at 57600. It's either designed wrong, or it's a bug.
PE> There is absolutely no sense in using two different baud rates
PE> to my session. Didn't happen with my Spirit II either.

Doesnt happen with a V32bis Supra either.

DH> This is as dangerous as walking on razor blades.

I'm not convinced its actually any more dangerous than the approach the
USR takes. In fact since the USR approach is rather counter intuitive,
if anything its more dangerous. Let alone being special to the USR.

DH> It's held together by the dynamic ATZ that it may or may not
DH> see in time.  If the RING comes in first, you get rubbish.

Well, given that mailers do check the modem is responding properly,
and that the ring be ignored in that unusual case, I cant see it.

The problem is MUCH worse the other way actually, if you dont remember
to do an &W at the new port speed you want to use you NEVER see the RING.

DH> It's not USR's fault - it's inherent in the situation.

I'm not convinced. All modern comms software does send an AT
command to the modem initially, and I think its mad to be
adopting that counter intuitive approach because of the remote
possibility that the AT command wont be seen by the modem

DH> After a reset, the modem has no record of the DTE baud rate -

Yes, its clearly appropriate to use the &W rate when there is no other
rate available. BUT it makes NO sense to ignore the speed of the next
AT command. The modem already put the OK back at the new speed and it
makes no sense whatever to be changing BACK to the &W for the RING.

DH> but it can, and does, remember the last AT&W baud rate, that's permanent.

And VERY counter intuitive if you forget you have to do another after
a port speed change. Particularly with the modern approach of storing
the basic config you want to use with &W and using ATZ as an init string.

PE> You reckon this happens on Rockwell-based modems?

DH> Yep.  Including the Spirit.  Do a power up, say
DH> nothing to it, and send in a ring.  Guaranteed,
DH> "RING" will come out at the speed of the last AT&W.

Thats got nothing to do with what he is talking about, clearly if its
never ever had an AT command since power up, the speed has to come
from the NVRAM. What we are actually discussing tho is IGNORING the
speed of an AT command except to respond with OK, and REUSING the &W
speed for the RING. I dont believe that behaviour is common at all.

DH> "Power up" includes a glitch on the supply that didn't reset
DH> the computer, at least now and then, on most modems I've seen.

Yes, but the mailer is periodically resetting the modem anyway.

DH> The cyclic init that Bink does is a genius class
DH> idea, to handle a very necessary situation.

So it makes no sense to just keep using the &W speed forever.

PE> 3. Modem is initiating a retrain straight after each connect, even
PE> with V32bis modems.  I would expect that the initial negotiation
PE> would have figured that out, no need for a retrain on every single
PE> bloody call.  Yet the ATI6 does not show that a retrain was requested.

DH> "Standard Operating Procedure".  Works better.  Much.

Not with *V32BIS* modems, and CERTAINLY not a full retrain, as opposed to
a rate negotiation, fall forward/back. Its demanding a full retrain. Nuts.

DH> The handshake time is going on while the equalizer is settling,
DH> the exchange is still buggering about, and generally the worst
DH> of all possible worlds.  10 seconds later is a lot more stable.

Yes, it may make sense with V34, but its nuts with
V32bis. Particularly when the session is ALREADY at
the maximum speed, and its demanding a full retrain.

DH> As near as I can see, what USR have done is to do a fast
DH> and rough approximate, and make it on the conservative side.

Corse it might be a side effect of their USR specific attempt at
very fast initial negotiation too. Still makes no sense at V32bis
tho. Presumably someone has had a brain fart and left it in for V32bis.

DH> Follow through with a final polish on the desirable
DH> parameters for this call several seconds in.

For V34, sure, V32bis, mad.

DH> This is the major reason for success where other
DH> modems fail - the USR is designed to connect VERY
DH> conservatively - then train up if indications warrant.

Maybe, but V32bis has a completely different approach of allowing the
initial handshaking at a lower line rate and moving up to what the line can
handle AS PART OF the negotiation, no need to do that AFTER the CONNECT stuff.

DH> Training going on during connect phase isn't all that reliable.

Possibly valid at V34, not at V32bis tho.

PE> So it trains up after every call by design?
PE> Ok, then why doesn't ATI6 show the retrain?

DH> 'Cause it's not a genuine retrain, which would
DH> take extra time. It's a forced "fall forward".

It is a genuine retrain tho, rate negotiation doesnt produce
the same display on the front of a Supra. And its already at
the maximum rate anyway, pointless to see if you can go faster.

DH> Don't know the V34 spec well enough to hit the exact terminology.

Its usually called rate negotiation.

PE> 4. Having problems talking to a Supra modem, 50% dropouts
PE> where previously there were none (with a Spirit Thunder modem).

DH>> Supra on v34 or VFC?

PE> V32bis.

DH> Bloody HELL.  That's a serious indication of drastic problems.

You could say that |-)
Specially when its only seen when a USR V34+ is called.

DH> 14400 should get through almost a barbwire fence.


(Continued to next message)

--- PQWK202