Date: Thu, 24 Mar 94 08:45:06 EST From: iedh1@agt.gmeds.com ( Daniel J. Hofferth (317)230-4791/Allison Engine Company) To: macgifts@sumex-aim.stanford.edu Subject: [*] High Speed Modem Musings (v1.1) High Speed Modem Musings (version 1.1) Hi all, I've now spent a number of months with a new V.32bis (14.4K) FAX/modem that gave me a variety of little fits until I finally got everything running just right. Upgrading from a 2400 baud modem, I found I was mentally unprepared for the many complications introduced by the much higher speeds. The new modems are NOT always plug-n-play replacements for older models. While quietly researching solutions, I noticed quite a few postings in different lists/digests (such as this one) from people who are suffering from problems similar to those I puzzled over. In the hope of helping someone else, I posted the problems I had and solutions that worked for me. Since that first posting in mid-January of '94, I've received a surprising amount of feedback from others who shared my plight, those who still had questions, and many offering alternative solutions. This posting comprises the original file with all of that feedback folded in. Thanks to you all! Think these are FAQ's? Maybe so, but I couldn't find answers in any one place. Interesting thing is, these seem like perfectly natural problems waiting for unsuspecting "slow" modem users who are about to move up. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Before I begin, I had a number of people asking if there was any penalty in performance for using a modem originally sold for a PC on a Mac. As far as I know, aside from packaging, bundled software, and supplied cable, there is NO difference between a modem sold for a PC and one sold for a Mac. All problems posted below are related to high-speed (HS) communications, and they occurred while using both CTB and non-CTB applications (Apple's Communications Tool Box): 1) Trouble establishing a connection. I had my modem attached to the wall jack via a long (50 feet) ribbon style phone cable... the kind where the wires run parallel to each- other in a semi-clear casing . To make matters worse, it ran in long straight lengths (around an intermediate room), and then into a tangle of power cords for the computer. It was a great antenna, but a lousy HS modem extension. It worked just fine for the 2400 baud modem, mind you. Went to Radio Shack and picked up "twisted pair" phone cable (cheap). Then rerouted it away from the power cords. Bingo - connections made. I understand there is also a "high-twist" wire available for data- grade communications. What I bought worked fine for me... my house uses the standard twist in the walls... I didn't see any sense in going to data grade for just this one length. They also sell line filters to weed out noise - didn't need that either. 2) I could now connect at HS with error correction and flow control, and work the user-interface without apparent trouble, but file transfers kept causing my modem to hang-up abruptly. The Mac's serial port issues the hardware-handshaking (HH) signal on a pin that HH-cables also carry to DTR on the modem. My modem was set to hang-up on loss of DTR (AT &D2), when it should have been told to ignore DTR (AT &D0). No more unexpected hang-ups. For the older modem, this was not an issue - it used Xon/Xoff handshaking. I've seen postings indicating that some Macs are fast enough to keep up with the incoming data flow, no matter how fast it comes in. For these, the messages say, "hang-up on DTR loss" is O.K. since the Mac will never need to use it for flow control. I'm not lucky enough to own such a speed daemon, but this sure sounds like dangerous advice to me.... What happens when the user pulls down a menu, in mid-file-transfer, and lingers there a while deciding what menu item to select? What happens when you're downloading in the background and you launch a BIG program from the finder? Can _nothing_ distract a "fast Mac" long enough to force a drop in DTR? I wonder. There _are_ other ways to hang-up the modem, why tempt fate? 3) No more hang-ups, but high speed uploads and downloads were full of packet-errors. Effective throughput was only about 700-800 cps. I knew that I had a HH-cable, software that had HH support enabled, and a modem-to-modem connection that was error correcting and flow controlled. But I was still getting sporadic packet errors on file transfers. Clearly HH wasn't working. I got out my multi-meter and tested the cable supplied by the modem manufacturer. It WAS a HH-cable, but not wired as suggested by Apple... I'm no EE, but it seemed worth swapping out to me. At my local computer store I bought another HH-cable (after being assured that I could return it if it didn't work), brought it home and tested it with the meter. This one was almost identical to Apple's version except that pin-7 (GPi) on the Mac side wasn't connected. As I gather from other readings, GPi is a special purpose pin that isn't used by simple home connectors like me. I tried the new cable, and file transfers were MUCH cleaner, but still not perfect. Here is the HH cable recommended by Apple: Mac Modem DIN-8 DB-25 1 HSKo ------+-- RTS 4 `-- DTR 20 2 HSKi --------- CTS 5 3 TxD- --------- TxD 2 4 GND --+------ GND 7 8 RxD+ --' 5 RxD- --------- RxD 3 6 TxD+ (nc) 7 GPi --------- DCD 8 Shield --------- Shield (Again, remember that the GPi-DCD connection is NOT considered essential for normal home connections. BBS host software only?) 4) File transfers still suffered from packet errors if I switched to another application, or simply held the mouse button down on a menu. Otherwise, they were going O.K. What now?! Apple claims the priorities for a variety of system related tasks can cause the Mac to miss incoming information. They suggest the following guidelines for improving the CPU's attention to the serial port: - Limit your Mac-to-modem connection to 19.2KB. While the new modems can theoretically achieve throughput of up to 56KB, this is almost NEVER really achieved. Text file transfers can reach 3500 cps (or so), but most file transfering that we do is of already compressed files. Throughput for these is much closer to the modem-to-modem implied speed of 1440 cps. Thus, 19.2KB is fast enough for general use. 38.4KB may be safe if you Mac is fast enough (mine isn't). - Don't use 24-bit mode, stick to 32-bit addressing. 24-bit addressing mode apparently peppers the CPU with extra interrupts that clouds its ability to watch over the serial port flow control... possibly resulting in missed characters. - Don't use virtual memory. Same reasoning as above. The overhead required to manage the virtual memory impairs the systems ability to keep up with the flood of serial port data. - Turn off AppleShare. Again, same reasoning as above. AppleShare achieves a higher baud rate through its serial port by commanding a higher priority level. I was already at 19.2KB between my Mac and modem (having already learned that 38.4KB greatly increased my problems), but I was still in 24-bit mode with virtual memory on. I've been pretty religious about collecting only 32-bit clean software, and I've got enough real RAM to turn VM off without problems, so following these guidelines was painless for me. And they worked. I now have rock-solid high speed connections on a slow Mac, and file transfers that are robust enough to let me switch between applications without packet errors. What speeds can be expected? File transfer speeds, on a full speed (14.4K) connection, HH, with hardware compression, etc. are about 1600 cps when downloading ALREADY COMPRESSED files. I emphasize the "already compressed" part because speeds can vary wildly depending on the type of file being transfered (some compress better than others). Very rough numbers range from 3500 cps for plain ASCII text files to a low of 1440 cps or so, for files that won't compress any more at all. Most everything I download is "already compressed" .sit, .cpt, .sea, etc... On these file types, modem compression does very little good, and 1500-1600 cps (give or take...) is considered "normal". Now, these speeds can drop off a little, or even a lot, if you are downloading in the background while you are busy in other applica- tions--this is perfectly normal. What should _not_ be happening is repeated packet-errors. Your Mac divvies up its CPU time to all active applications, while monitoring the serial port for proper data-flow handling. So long as it isn't distracted too much by higher priority interrupts, it'll detect when the serial port buffer is full (because your comm program hasn't been given a chance to empty it lately) and it'll issue the hardware handshaking signal to tell the modem to pause. When the buffer has room again, data transfer is allowed to continue. If all is done properly, your comm program will never see a lost or incorrect byte (thus, no packet errors), but it will certainly feel the overall slow-down due to the shared CPU time with other applications, and 1600 cps is enough of a data-flood for this CPU sharing to be felt. Faster Macs should do better here. I've done all of that, anything else to watch out for? I got a number of comments back about various INIT's being CPU hogs that can cause trouble. I'm not convinced this would cause data loss as often as it would cause a slow down in effective transfer speed, but clearly the possibility for both problems exists. If you're still having trouble, try temporarily rebooting with all non-essential INITs disabled to see if that helps. This isn't immediately obvious to many, but it makes perfect sense: If process loading on your machine can slow down a file transfer (CPU hogging INITs, background downloading with foreground application activity, etc.) then it certainly follows that process loading on the _host_ you are connected to can also affect that speed. If you've been getting 1600 cps from a given host for months, made no changes to your system or transfer procedure, and see an abrupt and significant drop in speed... before you tear your hair out, send a _polite_ note to the sysop and ask if he/she is aware of any activity on their end that might account for the change. Be sure to mention the date(s) and time(s) of the transfer(s) in question. If you _have_ made any changes, check them out first--sysops work hard enough. I've heard from some who are _sure_ they have a proper HH cable and that their software has been told to use HH, and they still get a lot of packet errors while downloading. Two thoughts here: The host MAY have it wrong, or your modem may not be initialized properly. Flat out, host problems are unlikely. Most BBS's and commercial services wouldn't last long if they weren't set up right. Exhaust possibilities on your end first before complaining. If you are getting clean file transfers from assorted hosts, but one host repeatedly forces packet resends, THEN it's time to consider contacting that sysop. Modem initialization problems are much more likely. For example... Have you told your modem to return the proper response to indicate it has a HH connection? I.E. instead of "CONNECT 14400", you should see "CONNECT 14400/ARQ" when a "reliable" connection is made (or "CONNECT 14400/REL" on some modems). And you may have to tell your comm-program what to look for so it knows that such a connection has been made ("/ARQ" or "/REL"). On my modem, and probably on most, "AT S95=3" enabled this trick. A final thought on debugging: I got some feedback from folks who tried each of the tips above, one at a time. In the computer world this is often a blindly accepted debugging procedure, but it doesn't always make sense. If you've got your computer-to-modem speed set too high, and you've not got a proper HH cable, fixing either one won't work--you need to fix both at the same time. Here's my suggestion... if you've got perplexing connection troubles, change everything between the wall-jack and your finger tips that even smells suspicious. Then, if all works well, start restoring anything you'd like to restore... one at a time. By the way, to those of you who wonder about file transfers that abort when you try to launch a big application, or impose some other long pause... To me this doesn't necessarily imply a handshaking error, perhaps the computer you were connected to decided it had waited long enough and simply timed-out? Short pauses should certainly be handled without errors, but the longer you go - the more likely it is that the host gave up. No? (Don't discount the DTR discussion above, item 2) I read one interesting comment from a modem manufacturer... They noted that Apple's serial port buffer is painfully small, making the timing on handshaking a critical and touchy issue. They noted that as modem speeds have increased, fortunately so have Mac speeds - thus somewhat compensating. Apparently, we slow Mac owners seem to be in the yellow zone in the war between CPU horsepower and modem data flow. It doesn't take much to tip the battle one way or the other. Sorry for the length of this, but I hope it helps someone else. Dan Hofferth iedh1@agt.gmeds.com