TR> Re: Alleged Spirit II  Spirit II V42 "doublesending"

RS> Pity it aint anything remotely like a single instance

TR> I have been through the archives for the SPIRIT_SUPPORT
TR> echo since I started the echo and there is only ONE
TR> instance of it ever having been reported (by Dave Hatch).

DH> Confirm.  That's not only my recollection, that's the only
DH> instance even I ever saw.  I'm still of the opinion it was
DH> valid - and it's certain that it was a very rare bird indeed.

You told me explicitly that you had seen it more than once
when Trev made that once only claim, quite some time ago.

TR> If you wish to provide other instances feel free. Put up or shut up.

DH> Nah.  'E will just beller "yer wrong" - like usual..:-)

Is that right Dave ?
---------------------------------------------------------------------------
Conference: 21,Spirit_Suppo
Number: 201
Reply-to: 0
Private: No
Receipt: No
Date: 1993-07-02,20:00
From: Dave Hatch
To: All
Subject: Spirit - Maestro bug
Flags: 

Well - this is going to put the cat among the pigeons!

This afternoon, I got a sample of the double block send at
v42bis bug between two Spirit II's.

The fault was triggered at my end, when I opened a third DV
window.  (For the system in question, that's normal
operation.  It rarely falls below 3, and 4 to 5 windows is
common.  Never before a problem.)

The download I was doing promptly went into constant MR pulse, the rate
halved, and it remained there.  After the first incredulous
look, I let it continue for about a minute and a half.  It
did not fix itself - the pair were quite content to double
send ad infinitum.

Per SOP, I hit the "pause" key.  Halt, light stops
flickering.  Hit "Enter".  Transfer resumes, full speed.
Undoubtable case - all symptoms exactly to spec for the bug.

Both ends Spirit II, both ends running 2A19/2931.

Note: this is a rare bird indeed - opening a DV window is normal operation,
and I'd have opened at least several hundred during various
downloads since that particular ROM was installed.
Presumably, the trigger was a very low probablity
occurence.  The major item of interest being that once the
fault was triggered, both ends of the link were quite
content to continue in double send mode until the cows came
home and then some.
--------------------------------------------------------------------------
Looks like a pretty definitive bit of PROOF that it is indeed seen
between a pair of Spirits to me Dave. Sure, its clearly sensitive
to the timing in the software behind the modem, but thats no surprise
given that you can eliminate the problem forever with a modified Binkley
behind the Spirit with a tiny timing detail difference.

We do have DEFINITIVE proof tho that since in this observation,
carefully tested by the use of the PAUSE to be a real double send,
that the fault MUST lie in the Spirit, coz thats the only modem present.
--------------------------------------------------------------------------
Conference: 21,Spirit_Suppo
Number: 935
Reply-to: 934
Private: No
Receipt: No
Date: 1994-01-09,21:58
From: Dave Hatch
To: Trev Roydhouse
Subject: Re: Spirit 2 in spotlight
Flags: 

 TR> Netcomm were apparently using the same Rockwell chipset as
 TR> Maestro, the only functional difference being that the Netcomm
 TR> didn't use the Rockwell code.

 > The problem with that theory is that the double block
 > sending has been seen between a pair of Spirits.

 TR> The problem with that statement is that there was a only single
 TR> instance of similar behaviour observed and the reason for it is
 TR> not known.

I've since seen it twice more - and that out of a sample of
literally hundreds of transfers.   About 3 in 10^3
probability, wet finger sez.   The Maestro version has a
probability of over 80% of going straight into the error.

I still can't come up with a solid explanation of why
pausing the transfer fixes the problem for that file on a
Maestro, if the fault rate is so high.

(Presumably it has something to do with v42 link negotiation?????)

Regards, Dave Hatch
---------------------------------------------------------------------------
Oops.
@EOT:

---