Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!linus!linus!mwunix.mitre.org!jcmorris From: jcmorris@mwunix.mitre.org (Joe Morris) Newsgroups: comp.windows.ms Subject: Re: Windows handling multi-tasking with comm. pgms. Message-ID: Date: 28 Jun 91 14:10:12 GMT References: <1991Jun27.232646.9501@uwovax.uwo.ca> Sender: news@linus.mitre.org (News Service) Organization: The MITRE Corporation, Bedford MA Lines: 41 Nntp-Posting-Host: mwunix.mitre.org baer@uwovax.uwo.ca writes: >I am running a communications app. which comes in both a DOS and an OS/2 >version (Rexxterm). I just purchased a 9600 baud modem for my 16mHz >386sx. This modem has MNP 5 (and v.42) error correction; of these 2, >the modem at the "mainframe" end seems to provide MNP 5 but not v.42. >MNP 5 should provide a throughput of up to 19,200 baud. Under Windows 3, >when I run the serial port at 19,200 baud and connect at 9600 baud, >I lose characters, even with the communications app. running in the >foreground and no major app's running in the background (file system, >pgm. manager that's all). With the serial port set at 9600 baud, >I have no problem with the comm. program in the foreground. With any >serious multi-tasking in 386 enhanced mode, even this configuration >(9600 serial port speed) isn't low enough: there is a loss of characters >when I run the com. program in the background (priority=100) and >either Word Perfect or a stats program in the foreground (priority=100). >This despite the fact that the foreground program suffers some >degradation (typed characters take a while to appear on screen etc.). >Under DOS alone, there is no problem running the communications >program with the serial port set at 19,200 baud. There's a tech note from Microsoft (last updated 10 December 90) which addresses lost data running at 19.2 or higher using KERMIT. Its suggestions (which I haven't tried since I'm limited to 9600 bps) are: - mark "Lock Application Memory" in the PIF file - Set COMxBUFFER to a big value (1024 suggested as a start) - Set COMBoostTime to a higher value (10 msec suggested) - Set COMxProtocol to XOFF (and use XON/XOFF in REXXTerm) It also suggests that KERMIT users turn the timer off because delays between characters caused by Windows' buffering can make Kermit think it's got a dead circuit. Joe Morris