dor@jaialai.cis.ufl.edu (A Knight in White Satin) (01/01/91)
I've got this troubling problem when Im downloading files while in Windows. Setup -- '386, in Enhanced Mode Running PCPLUS in a DOS shell, which is shelled out to DSZ to ZMODEM a file down. [Problem also rs when using ProComm's built-in XMODEM routine] The process has been shrunk to an icon [but also happens when it is running in a window] If disk access occurs (i.e. I open a Windows-app) the entire computer will come to a screeching halt and sit. And sit. The modem will eventually stop sending characters, waiting for an acknowledgement from my PC. More sitting. Suddenly, the computer will acknowledge the download and continue. The download resumes, and Windows gets going again. I have the settings for the process at 500 (foreground) and 500 (background) but since this is the only DOS proc I'm running, this shouldn't matter, should it? Other background tasks that are active: ScreenPeace 1.2, Curse, Clock, and an EYES program. (Calling itself Ralph, I don't recall what the program itself is called.) Any help would be appreciated. I get annoyed when this 33 MHz machine suddenly decides it can no longer walk AND chew gum, but needs to stop and think it over a while... Doug Oosting -- D.R. Oosting, Univ. of Florida | "Make way for DUCK KONG, all you dor@beach.cis.ufl.edu | expendable extras!!" fnord@eris.disc.ilm.bav | - Plucky Duck Cypress School, Cuong Nhu Karate /// Barony of An Crosaire, Trimaris
ergo@netcom.UUCP (Isaac Rabinovitch) (01/01/91)
In <26117@uflorida.cis.ufl.EDU> dor@jaialai.cis.ufl.edu (A Knight in White Satin) writes: >I've got this troubling problem when Im downloading files while in >Windows. ..... >If disk access occurs (i.e. I open a Windows-app) the entire computer will >come to a screeching halt and sit. And sit. The modem will eventually >stop sending characters, waiting for an acknowledgement from my PC. More >sitting. Suddenly, the computer will acknowledge the download and continue. >The download resumes, and Windows gets going again. >I have the settings for the process at 500 (foreground) and 500 (background) >but since this is the only DOS proc I'm running, this shouldn't matter, >should it? No, I think you should *lower* the priority. As I understand it (I'm probably garbling something here, so tolerance please), your comm. program is spending most its time waiting for i/o on the disk or the serial port. Waiting is not a complicated chore, so it doesn't require a lot of CPU time. But the program thinks it has the machine all to itself, and will avidly consume all the CPU time you give it, since that's what it means to wait! I had a similar problem with Buerg's LJBOOK program, which dragged down my system whenever I ran it. So I set a PIF with a background priority of 1. (Since most of my other programs run with the default priority, this means that LJBOOK gets one 50th of the CPU time of any other background program. LJBOOK works as fast as ever (all it's doing is writing a lot of data to the parallel port), and the rest of my system now works almost normally. -- ergo@netcom.uucp Isaac Rabinovitch netcom!ergo@apple.com Silicon Valley, CA {apple,amdahl,claris}!netcom!ergo THIS STATEMENT IS VERIFIABLY, IRREFUTABLY TRUE!
burgoyne@eng.umd.edu (John R. Burgoyne) (01/01/91)
Actually, the problem is that whenever a program other than the comm. program needs to do disk I/O, the cooperative multitasking ends. Under DOS, no matter how you try, there is no way I've found to have a secondary program do disk I/O while a comm program is doing a file transfer, without having the comm program hiccup or terminate the file transfer. A big RAMDRIVE might help, since the I/O is so fast the comm program may not notice, but I haven't tried this. I use XTALK for windows and Procomm. I usually just curtail windows activities which would need to do file I/O while a file transfer is in progress. WINDOWS DEVELOPERS PLEASE NOTE Do not write programs in such a way that they do file I/O as a passive action without intervention from the user, or the ability for the user to turn the passive file I/O off since you may screw up the user's file transfers. OS/2 and UNIX don't have this problem due to the preemptive nature of their multitasking. Robert