David Cook
Well-known member
I've written a little application to transfer files from one Mac to another over a serial cable (peer to peer). I'm using the XModem protocol for the file transfer, and BinHex 4 for the encoding of the file contents. These choices were made for compatibility, not performance.
As I'm getting close to releasing it, I've been testing under various conditions to determine the robustness and limits. I figured some people would find these results intellectually stimulating.
1. Can you write an application in CodeWarrior 11 (1996) and have it run on a Mac 512K with System 1.0 (1984)?
Yes. But, it took some work and customization. I'll provide details about this in another thread. I mention it because the serial results that follow include the 512K/System 1 combo.
2. What is the fastest baud rate the older Macs can use?
Surprise! Even the oldest Macintosh can run XModem 1K without errors at 57,600 baud.
However, the Macintosh 512K's slow CPU and floppy drive limit total throughput. In other words, the serial port delivers quickly and then waits for the CPU to verify the packet and write it to the floppy. So, a lot of quiet time between packets.
On the other end of the spectrum, a Macintosh IIci with an emulated HD saturates the serial port. That is, even a PowerMac G3 provides no additional bandwidth @ 57600 beyond the IIci.
The tipping point seems to be a Macintosh LC. The 68020@16MHz has just enough extra time to nearly max out. A floppy drive, however, cuts into throughput.
3. When does baud rate matter to an original Macintosh?
Any speed beyond 19200 provides no additional throughput on a Macintosh 512K using my application. It runs fine, just not effectively faster. At 4800 baud and below the CPU and floppy drive are no longer limiting factors.
4. Any caveats?
The XModem protocol has a known inefficiency. The sender sends a packet. The receiver checks the checksum or CRC. If everything looks good, the receiver sends an acknowledgement. The time the sender spends waiting for a response could have been made more productive by sending the next packet. But, XModem only supports one packet at a time. The wait time has a larger impact on faster baud rates. In the chart below, 300 baud is 95% efficient because the idle time doesn't equate to very many bytes at such a slow baud rate.
In addition, my application encodes the data fork, resource fork, and file information in BinHex 4 format. The overhead further reduces the actual number of file contents delivered per second (orange line above). The serial port is in fact as busy as the blue line, it just decodes to fewer bytes when stored on the disk.
Lastly, my application switches from 1024-byte packets down to 128-byte packets at 2400 baud. This shows regular progress to the user, at the expense of some efficiency.
Again, I made a design choice on file format and transfer protocol based on compatibility, not efficiency. Without the introduction of a compression algorithm, even the perfect protocol and file format could only provide twice the performance at 57,600, and +30% at 300 baud. Ironically, a good compression algorithm might result in worse throughput on 68000@8MHz Macs, as they don't have many extra cycles to even keep up with the raw serial port.
5. Hey! What about the LC III with the backwards capacitor that everybody argues about?
I've held onto an LC III without recapping the motherboard or power supply for just this occasion. When it starts up, the speaker makes a horrible squealing noise. In fact, it just keeps making awful sci-fi noises as long as it is powered on. There is no way this can transfer a file at the maximum baud rate without errors.
Oh drat. It works just fine. My whole world of recapping is a lie.
6. What did I learn?
Before this exercise, I figured the original Mac wouldn't actually handle 57,600 baud.
Secondly, I highly doubted I could get an application running in System 1.0. Yet, it has all of the fundamental system calls. This further increased my respect for the original dev team.
Lastly, I expected a lot of retries (naks) on the unrecapped LC III.
- David
As I'm getting close to releasing it, I've been testing under various conditions to determine the robustness and limits. I figured some people would find these results intellectually stimulating.
1. Can you write an application in CodeWarrior 11 (1996) and have it run on a Mac 512K with System 1.0 (1984)?
Yes. But, it took some work and customization. I'll provide details about this in another thread. I mention it because the serial results that follow include the 512K/System 1 combo.
2. What is the fastest baud rate the older Macs can use?
Surprise! Even the oldest Macintosh can run XModem 1K without errors at 57,600 baud.
However, the Macintosh 512K's slow CPU and floppy drive limit total throughput. In other words, the serial port delivers quickly and then waits for the CPU to verify the packet and write it to the floppy. So, a lot of quiet time between packets.
On the other end of the spectrum, a Macintosh IIci with an emulated HD saturates the serial port. That is, even a PowerMac G3 provides no additional bandwidth @ 57600 beyond the IIci.
The tipping point seems to be a Macintosh LC. The 68020@16MHz has just enough extra time to nearly max out. A floppy drive, however, cuts into throughput.
3. When does baud rate matter to an original Macintosh?
Any speed beyond 19200 provides no additional throughput on a Macintosh 512K using my application. It runs fine, just not effectively faster. At 4800 baud and below the CPU and floppy drive are no longer limiting factors.
4. Any caveats?
The XModem protocol has a known inefficiency. The sender sends a packet. The receiver checks the checksum or CRC. If everything looks good, the receiver sends an acknowledgement. The time the sender spends waiting for a response could have been made more productive by sending the next packet. But, XModem only supports one packet at a time. The wait time has a larger impact on faster baud rates. In the chart below, 300 baud is 95% efficient because the idle time doesn't equate to very many bytes at such a slow baud rate.
In addition, my application encodes the data fork, resource fork, and file information in BinHex 4 format. The overhead further reduces the actual number of file contents delivered per second (orange line above). The serial port is in fact as busy as the blue line, it just decodes to fewer bytes when stored on the disk.
Lastly, my application switches from 1024-byte packets down to 128-byte packets at 2400 baud. This shows regular progress to the user, at the expense of some efficiency.
Again, I made a design choice on file format and transfer protocol based on compatibility, not efficiency. Without the introduction of a compression algorithm, even the perfect protocol and file format could only provide twice the performance at 57,600, and +30% at 300 baud. Ironically, a good compression algorithm might result in worse throughput on 68000@8MHz Macs, as they don't have many extra cycles to even keep up with the raw serial port.
5. Hey! What about the LC III with the backwards capacitor that everybody argues about?
I've held onto an LC III without recapping the motherboard or power supply for just this occasion. When it starts up, the speaker makes a horrible squealing noise. In fact, it just keeps making awful sci-fi noises as long as it is powered on. There is no way this can transfer a file at the maximum baud rate without errors.
Oh drat. It works just fine. My whole world of recapping is a lie.
6. What did I learn?
Before this exercise, I figured the original Mac wouldn't actually handle 57,600 baud.
Secondly, I highly doubted I could get an application running in System 1.0. Yet, it has all of the fundamental system calls. This further increased my respect for the original dev team.
Lastly, I expected a lot of retries (naks) on the unrecapped LC III.
- David
