BG> Anyway Paul, as you profess to be so good at locating
BG> and curing bugs, perhaps you'd care to explain why
BG> I've only ever seen 28800/NONE connects with TML ?

RS> Rather obvious really. The code in USR modems which exhibit
RS> that in some circumstances only does that in some circumstances.

BG> I've been having this problem on and off (depending upon which ROM code
BG> was being used) for several months now, as you know, yet I'd never heard
BG> of it happening to anybody else.  However, in the last 2 days, I've seen
BG> a reference to one fellow in the US having it happen, and now the same
BG> thing (albeit only once) with Peter McGrath, locally (between Couriers too)

Thats certainly interesting, particularly the between Couriers bit.

There is some evidence that V42 wasnt designed quite as robustly as it
might have been on that error correction capability negotiation and that
if you arent careful, that can bite code that trys to implement it.

BG> When it was just me, it was rather hard to categorically point
BG> the finger at USR, but there is now some evidence that it does
BG> appear that the code does have a defect which allows this to
BG> happen, especially when disabling the 3429 symbol rate apparently
BG> fixes it. It also now looks like that defect which was fixed in
BG> the Sportster's EPROM (accidentally, by the look of it) also
BG> exists in at least the two latest revisions of the Courier code.

RS> Clearly, if PARTICULAR rom in a Sportster
RS> fixes that, it must be fixable by USR.

BG> Agreed, but as I said, they may have fluked it unintentionally.

Yep, thats certainly quite possible. Bet they just ignore that
comment you made to them tho, when they should look very closely
at it to see what fluked it and add that to the Courier SDLs too.

Corse thats not trivial if you cant setup the test config that exhibits
the problem. Maybe you should offer to flog them your house, they come
over here and thoroughly massage the Courier code on the spot |-)

RS> Think for a moment about when you said the same sort of thing
RS> based on the heaps of modems you tested when working for CHH. What
RS> you said was right, in THAT situation, you didnt see any problem.

BG> Quite so.  Any problems have been from here, and only here.

RS> Boy did you get ONE HELL of a surprise when you used the
RS> Sportster at home with the old rom calling it tho. Which
RS> went away completely when you installed the best rom.

BG> Which also happened to be the one which increased the speed
BG> to 33600, and as the 28800 code also used the 3429 symbol
BG> rate, it can't have been that alone causing the problem.

Yeah, the 3429 symbol rate story looks rather iffy.

BG> Looks more like defective code now, but until I'd
BG> heard about others with the same problem, I was
BG> loathe to blame USR based on just one sample (mine).

True, the bulldogs results calling Pauls Netcomm was
interesting, and Petes even more so since its between Couriers.

BG> I'm also not convinced that the M34F is completely blameless either,
BG> given that it happened FAR less frequently with Paul's Viper.

Thats another area you never really have grasped, that
RATES dont say anything useful about where the fault lies.

RS> I'm not being snide Bill, you really do want to think this
RS> thru. Coz if you can grasp it, it really does signify a
RS> HELL of a lot about testing in complex fault situations.

BG> I understand testing quite well, Rod.
BG> 18 years of fixing sodding VCRs has seen to that,

Nope, they are far easier, you can change bits.

Dial up comms has always been absolutely notorious for being
very difficult to deal with because of the vast combination
of modems at each end, combined with a quite bizarre variety
of different detail in the local loop at each end alone.

Its these more complex fault situations that really sorts out those
who can do it from those who cant. You only have to look a the bulldogs
complete load of silly rubbish on V32terbo to see that while he may
well be able to deal with configuring PC etc, he hasnt actually got
a fucking clue about that much more complex fault situation.

Most people havent.

BG> and after a while you tend to see the same
BG> faults cropping up with great regularity.

Yes, but these complex fault situations with dial up comms aint like that.

You do get quite a bit of that, the most obvious one hardware flow
control not working where you get the classic symptoms of downloads
fine, uploads fucked. But this /NONE problem is a classic example
of a very complex fault situation which you really need to know
what you are doing to analyse and come to useful conclusions on.
PARTICULARLY when you cant datascope the protocol negotiation phase.

BG> However, until I'd heard of others with the same non-EC problem,
BG> I was simply not prepared to blame USR's code based on just one
BG> sample, and from just the one location (i.e. line conditions).

Welp, thats where you were going wrong Bill. Thats the deficiency
in your approach to analysing the problem. Or one of them anyway.

AND its not just one sample either, you have been plagued with
/NONE connects even with V32bis Sportsters and a Spirit AND THATS
ABSOLUTELY VITAL EVIDENCE when others with V32bis Sportsters were not.

The V34+ Sportster rom evidence is absolutely compelling.

BG> I've called heaps of V.34 modems all over Australia (and a few
BG> in the US), and have NEVER seen a non-EC connect anywhere but
BG> on your board. Same with DD as well, now that I think about it.

RS> Yes, but you said the same thing about tests done from CHH too.
RS> And got one HELL of a surprise when you did it from home instead.
RS> And an even bigger one when a new Sportster rom fixed the problem too.

BG> Sure, I'm happy to acknowledge that the latest EPROM fixed the problem,

I was making a point there about your propensity to make sweeping
unwarranted proclamations when the evidence doesnt allow them tho.
Thats now dumped you face down in the mud time after time after time.

BG> but there's still no real way of determining whether
BG> or not the M34F also has some quirk in it's code which
BG> triggers the fault in certain USR code revisions.

Sure there is, CHH wasnt running any of those.

BG> Otherwise, I'd expect the failure rate with the Viper to be
BG> much the same, yet it was nowhere near that with the NetComm.

Again, you have never really grasped this rate question at all.

RS> Its more useful to recognise that USR clearly can
RS> eliminate the problem, coz the Sportster rom did.
RS> Presumably thats not in the Courier SDL for some reason.

BG> Makes me think the Sportster fix was more accidental than intentional.

Thats certainly possible, but not relevant to where
they can learn from that and fix the Courier SDLs too.

BG> Poltergeists, perhaps ?

RS> A deficiency in the USR which they obviously know
RS> how to fix if the latest Sportster rom did so.

BG> Unless it was accidental.

Yeah, could have said that more carefully, either now already
or can analyse and work out why if it was accidental. Doesnt
require Netcom to do anything and since the Viper exhibits
it too, the best place to fix it is in the Courier SDL.

BG> Otherwise, that fix would surely have been
BG> carried over to the later Courier SDLs.

Dunno, I have seen a quite disturbing variance on the service tone
detection variability between Courier SDLs and Sportster roms. Looks
very much like USR isnt actually administering that fix stuff well.

RS> PARTICULARLY when its primarily USR Couriers
RS> seeing that /NONE when calling Paul now.

BG> Just one (mine) regularly, and David's once or twice.

Come on Bill, ALL that matters is that Dave sees it
AT ALL. Particularly when he calls Paul so rarely.

BG> That's still not as large a sample as I'd like,

Sure, if I was the USR person chasing that down, I would
certainly do a few hundred calls first to be quite sure.

BG> but given the other recent reports about this in
BG> the USR_Modems echo, it may also now be adequate.

Yeah, looks like it. Corse they will probably just ignore
it like they have done the ATY11 problem which is completely
reproducible at will and they can test themselves anytime too.
@EOT:

---