> RS> I keep forgetting to deliberately try to cause some errors to see if
 > RS> FroDo does actually report any at my end at the ZedZap protocol level.
 > RS> Not that easy to actually force some CRC errors tho so havent yet.

 > NP> I get CRC errors occasionally when calling Paul.

 > Presumably you mean you see those on the ZedZap status screen thats
 > up during the actual transfer of the file. I have only seen any thing
 > there on an occasion or two when Paul had his system stuffed up, forget
 > what the fine detail was, some problem with flow control from memory.

That's what I am talking about.  CRC error at 25198
                                 CRC error at 47910....etc


 > I'd forgotten about those until now, so yes, I do know that they do
 > show.

They chances of their appearance depends on Who I am calling.
From Teddy (same exchange) 4 crc errors in 90k
From Brisbane             no crc errors in 2.8 MEG

It appears to be WHO I call


 > RS> I think you might well find that there is a significant
 > RS> correlation between those running Win and those getting CRC
 > RS> errors. Its a bit twitchy with interrupt latency and DOS comms apps.

 > NP> Running DOS comms under Win does not increase
 > NP> the frequency of CRC errors at this end.

 > Are you saying you get them even with plain old single tasking DOS ?

YEP !!!

 > NP> Also Running DOS comms under DOS does not reduce their frequency.

 > Thats likely fixable if you are just doing it with plain DOS and
 > not Desqview. There has always been a bit of an oddity with fossils,
 > some systems just work better with X00 and some with BNU. It appears

Using BNU locked at either 19200 or 38400 makes no difference.


 > I've forgotten what you are doing modem wise.

USR sportshoe 14400 aka BV

 > You shouldnt normally
 > expect to see any of that stuff, coz the line errors are fixed
 > between the modems if you are getting proper LAPM or MNP4 sessions.

LAPM V42bis

 > If you are on the edge of an interrupt latency problem, you can
 > get the illusion that the type of call is important, but its just
 > because the time between bytes changes with the speed of the modem
 > at the other end of the call and the LAPM block size etc stuff achieved.

Block size goes up  1024 2048 4096 8192
Then CRC error at xxxxx
Block size the drops 512 for a wile and then slowly climbs up again.
Next error repeat performance.

Sometimes I sit here telling the bloody thing to stick to 4096 and it'll be
OK, but then it jumps to 8192  bingo CRC error


 > Be worth trying reducing your comm port speed too, if its quite a
 > bit higher than it needs to be, particularly with a lower horsepower
 > system, you can get an interrupt latency problem and CRC errors.

Set it to both 19200 and 38400, No difference.


 > NP> Down here, it appears to be more of a line
 > NP> problem than an operating system problem

 > It shouldnt be if you achieving LAPM or MNP4 sessions. That error
 > correction should be complete transparent between the modems and you
 > shouldnt see any CRC errors at the file transfer protocol level at all.

They show, and the worst one at the moment is Teddy  six houses away

Got 2.8k of Jaberwocky last night and narry a glitch.


 > Corse I am assuming you have the 16550 already too.

Doesn't the sportshoe internal have it own? or a virtual one oe sumfin?

Anyway ... All 4 com ports have 16550's

Kind regards
Niels Petersen

--- FMail/386 0.98