The CPU is usually much faster than any peripheral device. In fact, it would not be strictly necessary for the CPU to immediately return to the top of the loop after getting a byte if it "knew" that the device was so slow as to cause a significant time lapse between bytes. In this case, the CPU would not have to set the data accepted bit to 1, and in fact no data accepted bit would even be needed! The CPU could turn off the data ready bit when it snarfed up the data byte, and then go off and do some other work for a while. Eventually, it would return to CHECKCTL just about the time it expected the next byte to appear from the tape drive.

Is it realistic that the CPU is so much faster than the peripheral that it can risk doing other work while waiting for the peripheral? Often, yes. Let's take a look at some numbers.

Older mainframe tape drives used to run at 75 ips (inches per second). The data was recorded at a density of 1600 bpi (bytes per inch). Due to blocking, data was never recorded in a solid, continuous stream on these tapes because flaws and imperfections would make it dangerous to count on the tape being perfect over a long stretch. So these interblock gaps on the actual tape would give the CPU a short breather; these gaps are dead space on the tape, places where no real data exists.

Pretending that the tape is continuous, that there are no interblock gaps, 75×1600 means 120,000 bytes per second coming out of the tape drive. This sounds like a lot, but taking its reciprocal, this rate is 0.0000083 seconds/byte, or 8.3 microseconds per byte, or 8300 nsec per byte. If the computer is performing one million instructions per second, which is quite a slow rate nowadays, it takes one microsecond per instruction. Thus the tape drive is more than 8 times slower than the CPU and a lot of the CPU's time would be spent vainly checking the data ready bit and finding it to be 0.

Another alternative, one that is extremely difficult due to the electronics, is to evenly match the I/O device with the processor. The computer could input a byte from the data port, store it into memory and then execute a fixed number of NOP instructions before going back and getting the next byte. Why this doesn't work too well is because it is hard to synchronize the tape drive with the CPU -- get them started at exactly the same time. And there might be some sort of unevenness in the speed of the tape drive, perhaps due to unevenness in the speed of the tape motor. Since most CPUs are vastly faster than 8 times the speed of a peripheral, it makes more sense to use control signals like those we introduced above.