Since it was possible that the initial C character would be lost or corrupted, it could not be assumed that the receiver did not support XMODEM-CRC if the first attempt to trigger the transfer failed. The receiver thus tried to start the transfer three times with C, waiting three seconds between each attempt. This meant that if the user selected XMODEM-CRC while attempting to talk to any XMODEM, as it was intended, there was a potential 10 second delay before the transfer started. To avoid the delay, the sender and receiver would generally list XMODEM-CRC separately from XMODEM, allowing the user to select "basic" XMODEM if the sender didn't explicitly list it. To the average user, XMODEM-CRC was essentially a "second protocol", and treated as such. This was not true of FidoNet mailers, however, where CRC was defined as the standard for all TeLink transfers. Higher throughput Since the XMODEM protocol required the sender to stop and wait for an <ACK> or <NAK> message from the receiver, it tended to be quite slow. In the era of 300 bit/s modems, the entire 132-byte packet required just over 3.5 seconds to send (132 bytes * (8 bits per byte + 1 start bit + 1 stop bit) / 300 bits per second). Assuming it takes 0.2 seconds for the receiver's <ACK> to make it back to the sender and the next packet to start hitting the receiver (0.1 seconds in both directions), the overall time for one packet would be 3.7 seconds, just over 92% throughput. The time for the <ACK>/<NAK> process was a fixed function of the underlying communications network, not of the performance of the modems. As modem speeds increased, the fixed delay grew in proportion to time needed to send the packet. For instance, at 2400 bit/s the packets took only 0.44 seconds to send, so if the <ACK>/<NAK> still took 0.2 seconds to make it back to the user's machine, the throughput has fallen to under 60%. At 9600 bit/s it is under 30% – more time is spent waiting for the reply than is needed to send the packet. A number of new versions of XMODEM were introduced in order to address these problems. Like earlier extensions, these versions tended to be backward-compatible with the original XMODEM, and like those extensions, this led to further fracturing of the XMODEM landscape in the user's terminal emulator. In