PE> It does recover from errors in transmission, but you
PE> aren't likely to see any of those either, with EC modems.

JT> Apparently you haven't seen the condition of line quality
JT> around our place. I sorta often get Zmodem picking up errors,
JT> yet on a clean line I transfer stacks of data without a hitch.

RS> That cant be line errors producing that, you are confusing line errors
RS> which are transparently fixed between the error correcting modems, and
RS> other deficiencys in the total collection of two PCs, two modems etc.

JT> I call some bbs's, and download at full clapper cps rates
JT> for anything up to an hour at a time and have no problems.

Says nothing useful about errors at all,
clearly not many are occurring with those calls.

Its also possible to call systems where the download is nothing
like full cps rates, and the modem is showing that the EC is
correcting errors, AND you dont ever see a single error at the
Zmodem level and THAT proves very conclusively that the errors
aint getting past the modems to be fixed at the Zmodem error level.

JT> Yet on a bad day when I call a particular bbs, I
JT> might get several errors over the whole download.

The usual cause of that is because something is dropping chars
on the serial line between the modem and the PC, at either end.

Usually due to interrupt latency on the receiving end
and a flow control problem on the transmitting end.

JT> On the same line, it tends to drop out more
JT> often, but it sometimes stays on with errors.

You shouldnt be getting drop outs at all on normal calls.
On calls that do drop out most likely the modems are retraining
because the line is shithouse and you can certainly Zmodem errors
in those circumstance, tho usually they are timeouts, not line errors.

When they cant even retrain successfully the line drops right out.

But on a line thats not so bad that they need to retrain, you
shouldnt be seeing errors at the line level that get past the
EC between the modems, to be caught by the Zmodem error check.

JT> And yes I'm sure I have EC turned on, I've tried it
JT> turned off once, sheez it was bad. IMO, EC *improves* the
JT> situation, but does not always completely eliminate errors.

Yes, if the line is so grossly bad that the
modems retrain, you can THEN see Zmodem errors.

And the line must be that grossly bad if it drops out at all.

Its even possible that the flow control in the transmitting
modem has some deficiencys in the retrain situation.

RS> If line errors are getting past the
RS> modems EC you have a problem somewhere.

JT> I wish I knew where,

Most likely an obscene line if it drops out at all. It shouldnt,
just fall back speed wise to a speed that isnt too bad error wise.

JT> I have also noticed this with my older system that
JT> I used to use, a different pc, modem altogether.

Which points the finger at the line and/or the BBS modem.

JT> Come to think of it, it doesn't happen all that often
JT> nowadays, it pauses for a while and drops carrier,

Thats a retrain being attempted and failing.

JT> but it sometimes holds on with crc errors. I notice the
JT> pauses while using the menus as well, not just on downloads.

Yeah, you should get pauses with error
correction if the error rate is high enough.

JT> If I call late at night (er, morning), it tends to
JT> be better, but at peak hour (evening) it's a mess.

That could either mean that the line is lousy due to crosstalk
from other calls or its what Telstra calls an HR joint, high
resistance. Tends to be moister at might so conducts better.
@EOT:

---