On 9 Jul 2004, at 21:55, Alex Mitchell wrote:

A very large automotive supplier (our client) uses HHP Dolphin 7200 scanners to scan their automotive crates. The scans are batched in the scanners. When they are ready to upload the data to our server, they dock the scanner in the cradle. The cradle is connected to a 56K US Robotics modem. We wrote the scanner application using 16bit C compiler (because the scanners are DOS based). We're using a Y-Modem protocol to upload the data files. The scanner dials into a modem pool to upload the data. When a connection is established, LRZ is used to receive the data files from the scanner. With smaller files (7K and smaller), this works fine. I've tried uploading a 12K file. After uploading 8K, the scanner returns an NAK error. This error keeps repeating until the scanner gives up and the upload fails. I've tried a 24K file, it fails after 16K. I've tried a 56K file and it fails at 16K. NAK error each time. I've tried the above scenario on FreeBSD 4.7 and FreeBSD 5.2.1 about 30 times for each file size, with the exact same result each time.

I had a very similar problem about 10 years ago. Macs trying to send mail just hung when they had more than x lines of text.

It turned out in the end that the then MacOs TCP/IP stack was ignoring the stated MTU, and just tried to send the whole thing in one huge packet. On dial-up, this overflowed the kernel IO buffer size, and hung the process.

In the end I looked at the serial port handling code in the kernel, and the buffer size was sensible for a 1990-era machine with 64MB of ram, being about 1K each. Since we had plenty of RAM on the boxes, I sacrificed a bit by upping the buffer size define to something big (I think 64K), rebuilt the kernel and the problem went away.

I wonder if something similar is happening to you?
Andy Holyer, Technical stuff
Hedgehog Broadband, 11 Marlborough Place Brighton BN1 1UB
08451 260895 x 241

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
  • LRZSZ Alex Mitchell
    • Andy Holyer

Reply via email to