RS>> I also havent made it clear enough that the Spirit problem doesnt
 RS>> bother me at all now that we appear to have a workaround in using
 RS>> MNP4 instead. Infact MNP4 is marginally faster than V42 anyway so its
 RS>> no problem at all from my point of view. Presumably the Spirit
 RS>> problem will eventually bite enough people to actually get it fixed.

 PE>> What do you mean it's faster?  You're getting throughput of about
 PE>> 100% instead of 108-115%.

 RS> I was just talking about the MNP4/V42 relativitys alone. V42 has a
 RS> little more protocol overhead in the packets, the CRC is twice as long
 RS> for one thing. V42 is more robust in very bad noise situations too, no
 RS> coincidence either, that the main reason for adding the extra protocol
 RS> overhead.

I think there must be something you aren't telling me.  We are getting
clean phone lines, no doubt about it.  Yet V42 gives better throughput on
clean lines, perhaps an extra 10%, no?  What CPS rates do you get with the
City?

 PE>> It seems pretty academic now, but I still don't see how you draw this
 PE>> conclusion.  The code that is in error could be AFTER the decision to
 PE>> make the light flash or not.

 RS> Thats not normally the way hardware driving code is written. Normally the
 RS> status type display stuff is an after the event thing to the actual
 RS> work. In this case the code handles detection of errors and the request
 RS> for a retransmit and only after all of that worrys about indicating its
 RS> done that on the status display. Infact its normal to have the display
 RS> as completely independent code which does nothing except maintain the
 RS> display, operating asynchronously to the code doing the work and at a
 RS> low priority, because the status display doesnt matter if it gets a bit
 RS> behind at times.

Fair enough.  You left out the automatic-compensation-for-Paul-Edwards's-
lack-of-technical-expertise in the last message!

 PE>> BTW, I still think that this bug in the Spirit's V42 ROM code has
 PE>> absolutely nothing to do with the Earthing problem, as I'm sure
 PE>> you'll see in the response to the question I asked of Dave Hatch in
 PE>> the Spirit echo.

 RS> Depends on what you mean by 'absolutely nothing to do with'. I still
 RS> think its likely that whats happening is that something makes the Spirit
 RS> decide that a retransmit is necessary. Then it goes mental and
 RS> retransmits every block after that. It may be that the hum involved with
 RS> the earthing produces a real error, and the need to retransmit, and then
 RS> the code bug makes the Spirit go mental. So in a sense its a completely
 RS> separate problem, in another sense its a trigger which makes the code
 RS> bug visible. As I said, its pretty likely that the bug must be
 RS> ephemeral, otherwise it would have been seen in the factory testing, it
 RS> needs a trigger to make it visible.

Even if there was a hardware bug which caused the initial error, it is a
software bug that continues on, and this problem has only just surfaced,
whereas the old hardware bug has been around for a long time.

 RS> Thats precisely what happens with the old time MNP4 bug too, it needs a
 RS> real line error to trigger it off. Doesnt matter how the error is
 RS> caused, just needs one.

This is getting to be a bit like problems I was experiencing with Paul
Markham. He was getting garbage coming through to Binkley in unattended
mode, but getting the proper "Ring ring" in terminal mode under
Binkley. He was using version 2.50.  I was using 2.56 and I was getting the
"Ring Ring" going to unattended mode, but garbage in terminal
mode.  He suggested that they must have moved the bug from Unattended mode
to Terminal mode because it affected less people!!!!  :-)

 PE>> P.S. The reason I didn't get any information from Meng Shi- Lim or
 PE>> whoever was because it was vague enough to suggest anything you care
 PE>> to name.  Bit like Nostradameus really.

 RS> The main reason I though it important was the characteristic poor 50%
 RS> thruput. Thats not a common symptom at all and when combined with the
 RS> file leaving the Spirit, it looked interesting. OTOH I agree about the
 RS> detail, not very well described or quantified, definitely the worst of
 RS> the test reports.

Yes, but I'm sure if I said that I'm getting 85% throughput instead of 50%
throughput, Meng would have said "I get exactly the same problem
talking to my wife"!  :-)

Paul

--- GoldED 2.40