PE> 1. After receiving an "ATZ" command at a particular baud rate,

BG> No need to go into that one again, as we know how to work around it.  Such 
BG> behaviour is certainly quirky, but no way could it be called a bug.

Ok, design fault.  I think I just called them "problems" anyway, not
specifying specifically that it was a bug, as opposed to a design
fault.

PE> 2. Regularly getting 26400 connects with a Netcomm instead of
PE> 28800.  Actually, that was with the 1995-07-18 Supervisor Date.
PE> It has got worse since I went back to 1995-07-05, with almost
PE> all connects at 24000, the occasional at 26400 and 21600.

BG> If the highest average link rate varies according to the SDL in use, it 
BG> would make sense to try them all, and use the one(s) which gives the best 
BG> overall connects.  Some people might even consider the ready availability 
BG> of ROM code to be an distinct advantage, rather than a problem.

Some people consider that if the ROM doesn't connect at 28800 whilst
another modem can, the ROM has a bug in it.  Not sure why you're 
dancing around that one.

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

BG> As far as I can recall, you were never able to prove that this was 
BG> happening with any modem other than Rod's Supra, and nobody else ever 

That is correct.

BG> reported similar instances, despite this peculiarity being discussed at 

That is correct.

BG> great length in Aust_Modems.  Insufficient data to blame the Courier, IMO.

I wasn't actually blaming the Courier.  It is up to USR to ask Rod to
call their US BBS at a particular time of the day, so that they can 
do a datascope trace.  Instead, they said "Is it an international
modem - try calling the UK!".  Oh, very clever.  God only knows what
goes through manufacturers minds.  Why wouldn't they be interested
in squashing bugs?  All they need to do is get Rod to call.

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

BG> That's not right at all, Paul.  Rod has told me himself that it was less 
BG> than 1 call in 10, and even he wasn't convinced that the Courier was at 
BG> fault here.  In fact, I seem to recall that call-waiting may have caused 
BG> this problem.

No, you're confused.  He was having 30% failures, not due to call
waiting.  This was when I had V.32terbo enabled.  The circumstances
you describe were for when I disabled V.34terbo.

PE> 5. AT&F1 sets S56 equal to 16 instead of the default of 0 listed
PE> in the manual.  Actually, this problem happens with the
PE> 1995-07-18 Supervisor Date, and is gone with the 1995-07-05 one.

BG> Not a bug.  Refer the explanation in my previous message WRT the necessity 
BG> of using different defaults for certain S registers with some SDLs.

Ok, I'll take your word for that.  Should have mentioned it at the
time and I would have verified it.  More than one ROM at that "feature".

PE> 6. A Spirit Thunder is getting connects with me at 2400 bps far
PE> more often than 19200.  1200 bps connects too.  Actually, this
PE> problem occurred with the 1995-07-18 Supervisor Date and one
PE> from 1995-01-25, and has gone away with 1995-07-05 ROMs.  It
PE> seems to have not occurred too many times with the 1995-07-18
PE> ROMs either.

BG> Could be either modem at fault here, although my gut reaction is that it's 

ALL of the problems could be either modem at fault, but ALL of the
problems can be worked around EITHER end.

BG> the Thunder which is the problem, especially when one considers that David 
BG> D has 5 or 6 Thunder callers who connect without any difficulties at all.

Say that again?  You think it's a Thunder problem, because 6 Thunders
are connecting fine to another USR?!  Hint - even if 7000 Thunders
were connecting fine to DD, it doesn't actually give one shred of
evidence which modem is at fault, if either, when the Thunder here
calls the Courier here.

PE> 7. USR to USR connect failed due to a retrain failure.  Also,
PE> USR to USR is showing 21600/2400 as the connect rate.  This
PE> was done with the 1995-07-18 ROMs and being fairly rare has
PE> not yet happened with the new ROMs.

BG> Dave Hatch saw this once, too.  Because it's so rare (I've never seen it 
BG> happen with any of my USRs), I'd tend to put it down to a major line 
BG> glitch.

21600/2400?  Only half the line is bad???

PE> 8. Failed to connect to Hayes modem at all.  Very weird sounds
PE> coming out.  No problem when I was using a Spirit.  This actually
PE> happened with an older revision of the ROMs (1995-01-25), and 
PE> cannot confirm at this stage whether it still exists because the 
PE> modem was taken offline so that I could connect.

BG> It's impossible to say who's at fault here.  However, if it was only the 

It's impossible to say who's at fault on ANY of the problems.  That's
the manufacturers job.  It's a great shame so few take bugs seriously.
Like none that I've ever seen, USR included.

BG> Courier which failed to connect with the Hayes (forget the Spirit, you need 
BG> another V.34 modem to prove the point), then I'd tend to point the finger 
BG> at the USR.  However, I'd have really liked to have tried another SDL 
BG> here.

Sure, he never made it available, so it's a problem-in-waiting
until I have a Courier sitting here with the latest ROM levels and
Dave has the Hayes online.  Since that circumstance is likely to
never occur, I don't mind if USR don't fix that one, and just say
either "Yes, we know about that, fixed with a later SDL" or "No,
we don't know about that, can you verify that the problem exists
with the latest SDL".

PE> 9. A Netcomm Cardmodem V.34 modem (PCMCIA or something) gets 
PE> connects of 1200, 2400, 14400 and 28800 with me.  This also 
PE> happened with the older (1995-01-25) ROMs, and appears to have 
PE> gone away with both 1995-07-05 and 1995-07-18 ROMs.

BG> Lots of weird shit happened with the 25-01-1995 SDL.  Far too many problems 
BG> with it for it to be coincidental IMO.  Probably fucked ROM code.

Another problem-in-waiting.

PE> 10. Previous user (using the 1995-01-25 roms) says that whenever 
PE> he is connected to his Internet Service Provider for more than an
PE> hour, the USR invariably drops out.  I don't connect for that
PE> long so cannot confirm this problem first hand with new roms.

BG> Could be anything, although there's that dodgy ROM date again.

Another problem-in-waiting.

PE> 11. The following stats obtained from ATI11 + 6 apparently defy
PE> various Laws of Physics, but this was on the 1995-07-18 ROMs...
PE> Carrier Freq (Hz)        44672/44672
PE> Symbol Rate              48905/48905
PE> Speed                  21600/2400

BG> I saw another very similar stats display not all that long ago, and general 
BG> consensus was that the line had suffered a major glitch.

Even if the line gets hit by a nuclear strike, the modem should not
defy the laws of physics.

PE> 12. I set S34=128 to disable V32terbo.  This had the result
PE> of making the calling Supra NOT show retrains on his display.
PE> This is a Good Thing.  The Supra is a V32bis modem.  It seems
PE> that V32terbo logic is affecting V32bis calls when it 
PE> shouldn't be.  However, now, instead of the Supra getting 30%
PE> failed calls (screwing up in the retrain AFTER connect), the
PE> Supra now gets somewhere around 30% connects at lower speeds, 
PE> such as 12000 and 7200.  Later trials were unable to reproduce
PE> this problem, got solid 14400 connects always, so probably not
PE> a problem after all.

BG> Rod told me that the failure rate was never 30%, but I should wait for 
BG> verification anyway.  Any idea if that was the 25-01-1995 ROM code?

No, that was with the 1995-07-05 code.  And also, that is a 
problem-in-waiting because I was unable to reproduce it on a later
trial, so needed more testing of that, which I was not able to do.

PE> 13. I set ATS27=48 as someone suggested I do.  The result of
PE> this was that I connected on my outgoing call with LAPM, my
PE> incoming calls were all MNP, except for some which failed
PE> completely.  I would have expected the results of ATS27=48 to
PE> be consistent.

BG> "S27=48 ... disables LAPM detection phase".  I'd suggest
that the resulting 
BG> connect would be entirely dependant upon the type of remote modem.

Like I say, I would expect it to be consistent.  And no failures
either.  I would actually expect connects at MNP and connects
without EC.

PE> 14. Got a 28800 (no EC) connect to a Spirit Viper.  The call
PE> was actually successful, I just had to put up with garbage
PE> appearing on my screen every now and again.  Called again
PE> and it connected with EC.  Sysop confirmed that he had not
PE> been fiddling at the time.

BG> I know what causes that problem!  It's almost certainly shitty lines!  :)

Nope, there's a bug.  Shitty lines should have caused a 16800, 14400,
or 9600 connect, WITH EC.

PE> 15. A Spirit II was getting 9600 bps connects to me.  Replacing
PE> the Courier with a Netcomm M34F or a Spirit Viper restored the
PE> 14400 bps connections.

BG> Given the problems I've had between Spirit IIs and USRs over the years, 
BG> nothing would surprise me with that pair in use.  Indeed, I believe the S2 
BG> to be such a crappy modem, that I'm going to ignore that problem 
BG> altogether.

That's a copout on USRs part.  The fact that the Netcomm and Viper
can handle it means that the USR is worse than Netcomm in this
circumstance.  A decent modem manufacturer would do something about
rectifying this, as I have explained before.  You either:

1. Say that it is the other modem at fault, but provide a workaround
in your own code

or

2. Say that it is the other modem at fault, and although you have
provided a workaround, the workaround has some serious unavoidable
side-effects, so it is a NON-DEFAULT OPTION.

That's how things work with a decent modem manufacturer, anyway.  It's
a shame I've never seen one.  BFN.  Paul.
@EOT:

---