Troubleshooting file transfers

You know that feeling when you have spent the past hour hunting for your glasses, only to find them perched on top of your head ? I mean, a really serious situation (I am blind without my glasses) that has a perfectly stupid and simple answer ?

Well, you won't believe what I have seen people come up with when it comes to file transfers. While this article may seem funny, it is also dead serious. Read on...

"Nothing wrong on my side"

The above is probably the most common thing I get to hear when I try to figure out why some user's file transfers keep crashing when he calls into my BBS. People rarely (if ever) accept that something could be wrong at their end - they always blame it on the other side. This makes it all the more difficult to track the real problem. The old saying that goes "you need two hands to clap" also holds good in the field of data communication. OK, here goes...

"Every time I try to download a file from an online service such as a BBS or Compuserve, the transfer crashes within seconds."

The most common reason that I have come across that causes this is an incorrectly set download path. Communication packages like Procomm have a setting which dictates where downloaded files are to be stored. This is usually called the Default Download Path (DDP). Setting this to a non-existing directory will cause the transfer to abort the second the protocol tries to create the file. Check your settings. One of the easiest ways of testing for this problem is to wipe out the DDP setting, causing all downloaded files to land in the current directory. If this works, then you know what the fault was.

Also be aware of the way the shareware versions of Procomm (versions upto 2.4.3) want the DDP to look. For example, if you want to have all downloaded files to land in the directory C:\PROCOMM\DOWNLOAD, then you have to set the path to C:\PROCOMM\DOWNLOAD\. The final backslash is important, because Procomm simply appends the filename to this setting and tries to create that file, i.e. if you are downloading 1HARRY.ZIP, Procomm will append it to the DDP so that the full pathname is C:\PROCOMM\DOWNLOAD\1HARRY.ZIP. If you do not have the backslash at the end of the DDP, it will try to create C:\PROCOMM\DOWNLOAD1HARRY.ZIP, which naturally doesn't work, and KABOOOM.

Thirdly, check if there is space on your hard disk. Some protocols like Zmodem and Ymodem Batch send the filesize along with the filename. If the size of the incoming file would be too large for the amount of free space you have, the protocol will abort immediately.

"I try to download a file using Ymodem, but it always crashes. I am using Procomm 2.4.3."

This common problem is due to the insane nomenclature the old Procomm versions used for file protocols. Version 2.4.3 has a protocol called YMODEM (option 5). If you tell Compuserve to send you a file using YMODEM and select the YMODEM in Procomm's protocol menu, things crash. The reason is because option 5 in Procomm 2.4.3's protocol menu is, in fact, not Ymodem at all, but Xmodem-1K. The real Ymodem is option 6, which is called YMODEM BATCH. This anomaly was fixed in Procomm Plus.

"The transfer starts OK, but halfway through, the errors start building up and finally the transfer crashes."

The most common reason for this is COM port overruns - the incoming data is simply too fast for the machine. However insane that may sound - be aware that almost 90% of all PC's face this problem.

The solutions to this are to use a faster machine, a faster hard disk or a 16550AF UART chip. The best solution is to get all three, especially the last one. Communicating at speeds higher than 2400 bps is a strain that the old 8250B and 16450 UART chips cannot take. If you are going to be operating at 9600 bps and beyond, you NEED a 16550AF chip.

Check this out by using a slower protocol. For example, if you have been using Ymodem-G Batch (a fast, flowing protocol that sends data with no stops at all), switch to YMODEM BATCH instead and see what happens. Or even try XMODEM. If a switchdown solves the problem, then consider one (or all) of the above solutions.

"I can transfer files, but the protocol shows lots of errors that had to be corrected"

This can be due to two reasons - you are using a non-error correcting modem (in which case you asked for it), or you have faulty flow control. The first one can only be fixed by openig your chequebook and buying a good MNP or V.42 modem.

Faulty flow control is when your machine is unable to tell the modem to stop a sec while it does something (like write data to disk). In the days before 2400 bps modems, people used XON-XOFF for flow control. This means that when the machine wanted the data flow to stop for a while, it would send a XOFF (Ctrl-S) down the line. To restart it, it would send a XON (Ctrl-Q).

This sort of flow control has no place in highspeed communication. Instead, you have to use hardware flow control (RTS-CTS). This requires three things - your communication software must have RTS-CTS flow control enabled, the serial cable to the modem must have ALL 9 critical wires connected, and the modem must be setup to recognise hardware flow control. Check your modem and communication software's manuals for details.

"My file transfers are error-free, but incredibly slow"

You are probably using an extremely slow protocol, such as Xmodem or Kermit. Both these protocols send data in small packets, then stop and wait for an acknowledgement before sending the next packet. Because the packet has to travel to the other end of the connection, get validated there, then an acknowledgement is sent, which has to ravel back to the sender's side and get checked there, a small-packet protocol like Xmodem or Kermit may spend more time waiting for the acknowledgement than it takes to send a data packet.

Things are made worse by compression features of modems, which wait for a set number of bytes before compressing them and sending them on their way. The small packets of Xmodem or Kermit will not fill the modem's buffer, so the modem has to timeout before it send the data off, causing even more delay.

Try using a flowing protocol (such as Zmodem or Ymodem-G Batch), or a protocol with larger packet sizes (Xmodem-1K or Ymodem Batch).

"I start a Zmodem download which aborts immediately, but the remote end syas that the transfer was successful"

Zmodem is a crash-recovery capable protocol. When the transfer starts, the protocol checks if a file by that name already exists. if it does, and if the file size and CRC check match that of the incoming file, then it tells the sender to skip the file, which is NOT an error.

Check if you have a file in your DDP that has the same name as the incoming file. If so, rename it to something else before retrying the transfer.

"I have mixed results using Ymodem-G Batch - sometimes it works and sometimes it doesn't"

In general, try and avoid Ymodem-G Batch. While it is a very fast way of transferring files, it has a fatal flaw - it cannot recover from errors, but simply aborts if one takes place.

Try using Zmodem instead or, if Zmodem is not available, Ymodem Batch. Zmodem is as fast as Ymodem-G Batch, but is much more robust - it can easily deal with errors and can even restart a crashed transfer from the point of breakdown. Ymodem Batch is about 80% as fast as Ymodem-G Batch, but can recover from errors.

"I have downloaded about 50% of a file when I lost carrier. Since I wasn't using Zmodem, I will have to start all over again."

No, you don't have to. If both sides of the connection support Zmodem, you can restart a crashed file transfer from the point of crash by using Zmodem the next time you attempt to transfer the file. Zmodem does not care what protocol was used to transfer the first part of the file - if it can find the truncated part of the file, it will take off from the point where the previous transfer had crashed.

"I try to download a file from a mainframe, but Xmodem and Ymodem always crash"

Most mainframes and minis operate using 7 data bits and Even Parity as communication parameters. Xmodem and Ymodem need 8 bits, no parity, so they cannot be used on such connects. However, Kermit can transfer 8 bit data over 7 bit lines (newer version of Zmodem can, too). If you find yourself in such a situation, you will HAVE to use Kermit, inspite of its slow performance.

"My faxmodem can send faxes just fine, but fails during file transfers"

Many people believe that if a modem can do one thing correctly, it can do everything correctly. Wrong. As a matter of fact, sending a fax is such a trivial task in terms of strain on the modem that it is not a real test at all. Always test a modem for its datacomm performance before declaing it as functional. Testing is just for fax performance is useless.

"Inspite of using an error correcting modem and achieving a MNP connect, my file transfers crash or are very slow"

MNP (and V.42) work by sending packets of data to the remote modem with extra information attached that allows the remote modem to check the data packets integrity. If an error takes place enroute, the receiving modem will tell the sending modem to retransmit the data packet.

By default, MNP modems usually send 256 byte packets. But on extremely noisy lines, MNP-packet retransmits can be more frequent. Since it takes longer to resend large packets than smaller ones, try setting your modem's MNP packet size to 64 bytes (most modems use the AT\A3 setting for 256 byte packets and AT\A0 for 64 byte packets. Some modems use the AT&BS1 and AT&BS0 settings).

Also, some modems have a setting that allows the modem to "give up" if it cannot transmit correctly within 12 tries - try changing this setting.

"I use a V.42bis modem with 1:4 compression, but my file transfers are still slow"

This can be due to two reasons. The first is that the incoming data is already pre-compressed (such as a ZIP file), in which case the modem cannot compress the data further and hence you will see no benefit from the compression feature.

The other reason is that your software is set to work at the modem's rated speed (e.g. 2400 bps). For compression to produce benefits, your port speed must be at least twice the connect speed (e.g. 4800 or 9600 bps). Also make sure that neither your modem nor your communication software attempt to adjust the port speed based on the connect speed. This is called AutoBauding in most communication packages, and should be turned off. Your modem will probably use a setting such as AT\J0 or AT$BA0 - make sure that this is set.

Logout:

That's it for this month. I hope you are now able to resolve your file transfer problems. If not - keep reading this column. More tips are on the way. Remember, in the world of computers, nothing can really go wrong...go wrong...go wrong...go wrong...go wrong...go wrong...go wrong...

Darn. Something went wrong.