RS> Yeah, I agree that its pure speculation on my part at this stage, that
 RS> line noise is getting in the road of negotiating an MNP4 connect. Mainly
 RS> because that is a known weakness of the V32bis approach, it assumes
 RS> enough line quality to allow negotiation and the line may infact not be
 RS> good enough for successful negotiation. Infact some modems like the
 RS> Supra allow a low speed connect, even down to 4800, which is used in the
 RS> negotiation phase, then when the modems have agreed on everything they
 RS> both step up to what ever the line will support, normally 14400.

 RS> Your modem wont allow that style of connect tho, I did try it at one
 RS> stage. If I set the negotiation speed at 9600 it will get thru the
 RS> negotiation phase fine but it never steps up from that. Quite a few
 RS> modems dont support fall forward and thats technically what it is, an
 RS> immediate fall forward from the negotiation speed up the the full speed.

Maybe it would if I allowed Adaptive Retrain?  I can try switching it on,
can't see that it would cause any harm.  I'd like to see some evidence of
line noise first though.  Like Zmodem errors on a non-protocol connect.

 PE>> I never see the MR light flashing either - I presume it is supposed to
 PE>> flash for MNP4 as well as V42.

 RS> Thats a different issue, many error indicators like that dont actually
 RS> show line errors until after the protocol negotiation. Infact they
 RS> indicate protocol errors and during a non protocol connect with line
 RS> errors they wont be showing errors anyway, there arent any protocol
 RS> errors, just line errors. The distinction is important.

Yeah, I'm talking about MNP4.  If it has to resend blocks because of line
noise, the MR light should flash right?  I've never seen it flash connected
to you, therefor it isn't doing any error correction, therefor straight
14400 should be fine.  Go on, let your hair out and connect at vanilla
V32bis one day.

 PE>> So I'm still proposing the theory that the problem is some timings of
 PE>> the MNP negotiation.  My end thinks it has MNP4 and yours doesn't.

 RS> Yeah, it does seem clear that we are seen a failure to successfully
 RS> negotiate MNP4. Not clear why tho yet. Interesting to that the big batch
 RS> of attempts got some MNP4s and some no MNP4s at your end. Clearly
 RS> negotiation is failing for some reason.

 PE>> Can you tell me what the sequence of MNP negotiation is, and which
 PE>> S-register settings would govern that.

 RS> There is very little control over the detail of the MNP negotiation
 RS> phase with most modems. And your modem is likely to use different S
 RS> registers for it too so I cant tell you what your modem can do. For
 RS> example the Spirits retrain and stuff settings are very different to
 RS> those in a Rockwell based modem.

Ok, can you tell me what the sequence of events is with MNP anyway.  Does
my modem put out a string (how many bytes BTW), your modem respond or what?

 PE>> Thursday morning after you had called successfully the first time, you
 PE>> called again and I got a lot of straight 14400 connections.  What did
 PE>> you get???  MNP4?

 RS> Dunno, unfortunately mine dont get into the log. I could do a series of
 RS> calls from terminal mode and in addition use the S86 to see the
 RS> connection failure reason. I must do some and get more info.

You mean all those connects were successful?  Aaaargh!

 PE>> You should have been able to log on, I would have expected both to be
 PE>> 14400.  Anyway, why don't you try forcing MNP4, and if you don't get
 PE>> it, disable it completely, and see what happens.

 RS> Cant quite understand that. Thats what I was doing, I told my modem to
 RS> attempt an MNP4 and if it couldnt get one to accept a normal non
 RS> protocol connect instead. In contrast to previously where I told it to
 RS> demand an MNP4 and hangup if it couldnt get one. But even when my modem
 RS> is told to accept a non protocol connect, it never actually got one to
 RS> use, something hungup, I assume your end but I dont know that for an
 RS> absolute fact.

Vanilla V32bis.

 PE>> Presumably you will log on, do a file transfer, and find not a single
 PE>> Zmodem error, which means the problem is not line noise.

 RS> Yeah, I agree with that in general.

So give it a go!

 RS> I have just finished some test calls, finished at Sat 15:14.

 RS> These were all made from the terminal mode, mainly so the all the
 RS> connect details are logged to disk.

Ok, how about posting a copy of it, and I'll post a copy of mine.

 RS> Rather inconclusive on the  calls. OTW
 RS> got on fine on almost every call. There were a couple of failures,
 RS> particularly the first one where I got the symptom I see a bit, MNP4
 RS> connect at 14400, then my modem front panel display shows 12K. Apparently
 RS> for some reason mine attempts to shift down in speed, presumably because
 RS> the line quality is poor. But yours either never agreed or agreed and
 RS> didnt manage to do it successfully. In those cases I never see anything
 RS> sent by your software, Binkley in this case. I have to manually hang
 RS> these up from my end.

Hmmm, try switching off adaptive retrain, because I've got it switched off
here.  We can either have both on or both off, which would you prefer? BTW,
you never told me before that your modem showed 12K.

 RS> There were quite a few situations where your end was left in an
 RS> unsatisfactory state, calling back gave me busy which took minutes to
 RS> clear.

And that was with S10=2.  Dear oh dear.

 RS> Then the last series had all protocol disabled, both MNP4 and V42
 RS> disabled. Interestingly on atleast half of the calls I got the usual
 RS> initial connect and then the line drops out. So it cant be dropping out
 RS> due to a disagreement on MNP4, since I'm not even asking for it on these
 RS> calls.

Oh, you have let your hair out.  Did it drop down to 12K?  If that is the
case then the adaptive retrain is the problem for sure.  I think this is
the most valuable data.  Who is dropping out?

 RS> And I got about half of the calls with quite a bit of line noise on the
 RS> screen. Some good connects right thru to Binkley with no line noise
 RS> visible too.

Line noise + data or just line noise?  A 12k pseudo-connect would have the
latter effect.  You only ever went to the BBS once or so, so the only data
you should have had was the EMSI string and press Escape or something.

 RS> So the short story is that we arent any further than we were in
 RS> understanding why I cant just call in and always get a good connect. It
 RS> is clear tho that demanding MNP4 isnt a problem. And that it wont help
 RS> to call denying any protocol.

It would mean less things clouding the air.  I reckon a few days of
non-protocol connects could give some more insight.  Presumably this 12k
bug which you never told me about before is the answer.  BFN.

Paul

--- GoldED 2.40