RM> Apart from that, I get a funny connect maybe once in 20, the modem rejects
RM> it cos it's not ARQ, the comms prog redials, the next connect works.

RM> More precisely, it used to connect with a bare 14400, no ARQ, no nothing.

Yeah, thats the fault.

RM> Such a connect was invariably hopeless, junk chars just
RM> poured out of the modem.

There is some suggestion that its not actually
a proper 14400 no protocol connect at all.

RM> So I altered the init string to reject non-ARQ calls, to save the hassle.

Yeah, thats the cleanest solution, minimising the online time,
so the failures shouldnt be costing you more than say 15c

RS> And a bad line shouldnt give that particular symptom anyway,

RM> Good point - if the line was funny, why don't the modems negotiate
RM> a lower speed instead of connecting at 14400 with no error checking?

Not necessary a lower speed unless its grossly bad. Yes, they
should still negotiate an error correcting session and just
transparently repair the errors between themselves. That should
only be visible as a marginally lower thruput, and be visible in
the modem's session stats with an increased count of resent blocks.

RS> you should get a proper V42bis connect with a higher than usual error
RS> rate which drops the thruput a bit. Not that that normally happens
RS> either for me tho. OTOH I am on a decent modern digital exchange.

RM> (I may have mentioned this before, but never mind)

RM> More often than not, I get an error
RM> prone connect when calling my local bbs.

Again, you should be still getting an error correction
session, with a lower thruput as the only visible symptom.

RM> He lives only a short distance away, but our phone#
RM> prefixes are different - I'll have to find a telecom
RM> friend to work out which exchanges we're using.

Looks likely its irrelevant.

RM> The modems connect correctly at 14400 every time,
RM> but Zmodem works very poorly, dropping back to shorter
RM> and shorter packets every time it strikes a glitch.

Thats not right. You should be getting a say LAPM (V42) session,
with *IT* fixing the errors between the modems, and NOT seeing
errors at the Zmodem protocol level, in the Zmodem status display.

Sounds more like you have an interrupt latency
problem, nothing to do with the phone line at all.

RM> I use Sealink with him now, it runs quite smoothly.

Which also supports the interrupt latency possibility,
because it ACKs the blocks as they are sent and so is
less prone to interrupt latency problems.

RM> OTOH, I point off that system as well as call it in bbs mode,
RM> and the point software doesn't seem to have much trouble. Odd.

Thats graphic evidence of an interrupt latency problem. When its
just on the edge, the smallest thing can push it over, in this
case the slightly different timing detail when you call it as a
BBS. What is the story on the hardware and the software used again ?

RM> Maybe you need to move north.

RS> Bob uses the same modem as you have, no problems at all.

RM> ? He has no trouble talking to Paul's Spirit?

Yeah, Brenton neither when he called it. With the SAME modem interestingly
enough. Bet its some simple difference on the phone line detail, say the
length of the line to the exchange or the exchange technology, perfectly
acceptible spec wise, just different to say Bills and yours enough that
it trips the Spirits defective handshaking code and it periodically falls
flat on its face and produces a non protocol connect.

--- PQWK202