hamilton@cell.mot.COM (Danial Hamilton) (03/01/90)
My environment: I'm running a 25 Mhz 386 with a Seagate ST277R-1 65MB 28ms RLL drive. I'm using a WA6-VR 1:1 controller with disk cacheing. My modem is a USR Courier HST dual standard. My problem: When transferring files at high rates (9600, 14400), I encounter frequent errors (like every other block) using ymodem or xmodem. A friend told me that the disk cacheing is to blame because interrupts are disabled while the cacheing is being executed and at high bit rates I'm probably missing characters. Can anyone confirm that this is true? If it is true, is there any way to temporarily disable the disk cacheing short of wiring an external switch to the jumper on the controller board?
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/03/90)
In article <1421@oak8.UUCP> hamilton@cell.mot.COM (Danial Hamilton) writes:
$My environment:
$I'm running a 25 Mhz 386 with a Seagate ST277R-1 65MB 28ms RLL drive.
$I'm using a WA6-VR 1:1 controller with disk cacheing. My modem is a
$USR Courier HST dual standard.
$My problem:
$When transferring files at high rates (9600, 14400), I encounter
$frequent errors (like every other block) using ymodem or xmodem.
$A friend told me that the disk cacheing is to blame because interrupts
$are disabled while the cacheing is being executed and at high bit rates
$I'm probably missing characters.
I would doubt that this is true ... your friend is correct that under
certain circumstances, disk caching can cause high-speed modem connections
to drop characters. However, the circumstance under which this happens is
the use of extended memory (that's 286/386 memory above 1M, _not_ EMS!) as
a disk cache. Use of conventional or expanded memory, or a caching disk
controller, should not cause this problem.
But that's a _should_ not, and you never know what happens in real life.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
I Think I'm Going Bald - Caress of Steel, Rushkens@hplsla.HP.COM (Ken Snyder) (03/03/90)
> From hamilton@cell.mot.COM Thu Mar 1 07:59:40 1990 > > When transferring files at high rates (9600, 14400), I encounter > frequent errors (like every other block) using ymodem or xmodem. > > A friend told me that the disk cacheing is to blame because interrupts > are disabled while the cacheing is being executed and at high bit rates > > Can anyone confirm that this is true? If it is true, is there any way Yes this is true. There are a couple of ways to get around it. I'm familiar with pckwik & pc-cache & both systems allow you to turn caching off and on from the command line. Another solution is that both allow you to specify the maximum block size to be transfered to the disk. This sets the maximum time the interrupts will be disabled. Pckwik, at least, has a discussion of this in their manual. The pc-cache manual discusses the disabling of interrupts but doesn't specifically relate it to communications programs. Hope this helps, Ken
ho@fergvax.unl.edu (Tiny Bubbles...) (03/06/90)
From article <5190079@hplsla.HP.COM>, by kens@hplsla.HP.COM (Ken Snyder): >> From hamilton@cell.mot.COM Thu Mar 1 07:59:40 1990 >> >> When transferring files at high rates (9600, 14400), I encounter >> frequent errors (like every other block) using ymodem or xmodem. >> >> A friend told me that the disk cacheing is to blame because interrupts >> are disabled while the cacheing is being executed and at high bit rates >> >> Can anyone confirm that this is true? If it is true, is there any way > > Yes this is true. There are a couple of ways to get around it. I'm Someone shove a sock in my mouth if I'm wrong, but Chuck Forsberg says in his ZCOMM documentation that this problem is caused not by the disk cache per se, but by using a cache to exTENded memory. It seems that using extended memory requires going to protected mode, and coming back requires a hard reset of the computer. It is during this hard reset that interrupts are lost. Supposedly, exPANded memory (true expanded memory -- not utilities that map extended to expanded, but actual LIM memory on a hardware card) does not have this problem. I have an XT, so obviously I don't know anything about extended memory's performance. I do occasionally run a disk cache (the one which comes with PC Tools) with no ill effects. --- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu USnail: 115 Nebraska Union Lincoln, NE 68588-0461
medici@elbereth.rutgers.edu (Mark Medici) (03/06/90)
In article <1421@oak8.UUCP> hamilton@cell.mot.COM (Danial Hamilton) writes: |When transferring files at high rates (9600, 14400), I encounter |frequent errors (like every other block) using ymodem or xmodem. | |A friend told me that the disk cacheing is to blame because interrupts |are disabled while the cacheing is being executed and at high bit rates |I'm probably missing characters. I believe that the "dropped character" problem your friend is talking about only pertains to _software_ disk caches operating in _extended_ (e.g., '286 or '386 memory >1MB) memory. I have not heard of this type of problem with caching disk controllers and, in fact, would tend to look elsewhere for the trouble.
umcarls9@ccu.umanitoba.ca (Charles Carlson) (03/10/90)
In article <2395@unocss..unl.edu> ho@fergvax.unl.edu writes: >From article <5190079@hplsla.HP.COM>, by kens@hplsla.HP.COM (Ken Snyder): >>> From hamilton@cell.mot.COM Thu Mar 1 07:59:40 1990 >>> >>> When transferring files at high rates (9600, 14400), I encounter >>> frequent errors (like every other block) using ymodem or xmodem. >>> >>> A friend told me that the disk cacheing is to blame because interrupts >>> are disabled while the cacheing is being executed and at high bit rates >>> >>> Can anyone confirm that this is true? If it is true, is there any way >> >> Yes this is true. There are a couple of ways to get around it. I'm > >Someone shove a sock in my mouth if I'm wrong, but Chuck Forsberg says in his >ZCOMM documentation that this problem is caused not by the disk cache per >se, but by using a cache to exTENded memory. > >It seems that using extended memory requires going to protected mode, and >coming back requires a hard reset of the computer. It is during this hard >reset that interrupts are lost. > In the DSZ documentation, CF also recommends changing your uart chip to a NS16550AN instead of an 8250 or 16450. The NS16550AN has a 16 deep receiving buffer<I assume that means 16 bytes> for machines faster than 4.77Mhz and receiving at speeds greater than 9600 bps. Charles