12

On the back of this question which talks about 5 and 6 bit communications, I remember back in the BBS days that it was common to set your terminal to 8N1, (a.k.a. 8 bits, no parity, 1 stop bit) to communicate with most BBSes. It was a bit of a curiosity why there was also 7E1 ('E'ven parity) amongst other configurations since I don't recall ever going to a board that required anything other than 8N1.

Considering that parity is sometime (always?) used for error correction, was the purpose of having a 7E1 connection a way of doing simple error detection in your transmission? If so, did anything ever use it at least in the PC modem communications world or is it just a relic of (say) tn3270 communications or something like that?

I can imagine that 8N1 was popular since the home micros of the 70s and 80s had 8 bit bytes and thus was necessary for transferring files without the help of something like Kermit which I believe accounted for bit and character code differences (e.g. IBM System 360's EBCIDC to ASCII). But if it was just a text service, a parity bit could be useful? (Come to think of it, was 8E1 possible?)

  • 1
    You may also be interested in the whole shebang. – Leo B. Feb 15 '17 at 19:48
  • Packages like Kermit had nothing to do with modems per se. They sat at a higher level and would transmit, with handshake, over any transmission medium – Chenmunka Feb 16 '17 at 8:32
  • I always had assumed that 7Ex was a way to encode ASCII that would allow senders/receivers without hardware parity checking to do the parity checking in software (which would be difficult with 8Ex, because that would produce 9-bit symbols). And of course it's used for error detection, not error correction; error correction would need to be done by the application. Transmission errors were much more frequent on older hardware, even though transmission speeds were slower. – dirkt Feb 16 '17 at 10:42
  • I seem to dimly remember that CompuServe used 7E1 for some reason. Does anyone have any of their old ads, which would be a source for this if I am correct. (I never used it except once at a computer museum.) – Keith Douglas Feb 24 '17 at 16:50
8

By the time I got my first analog modem, around 1980, my experience was the same as yours. Even and odd parity on 7-bit data was available, but almost all the BBSs featured 8N1. (The modems even still supported 5- and 6-bit data streams.) Apparently noise on phone lines by that time was so low that parity detection was considered superfluous for a large number of users. The BBSs would allow you to use a parity protocol if you wanted, though.

Note that parity in itself cannot correct errors. It is used for error detection. Software protocols were developed to flag a detected error and signal the sending computer to resend the bad packet. As Leo B.'s link shows, there were more complex, actual error-correcting, protocols as well. For these, data would seldom need to be resent, because the packets already had enough information to find and correct a certain number of bad bits.

The main problem with 7-bit data is that it is inefficient in handling binary information, or anything other than ASCII and other 7-bit character encodings. You could send binary data, but it would greatly increase the amount of data to transfer. The simplest protocols encoded each 8-bit byte into two printable ASCII characters, doubling the data size. Smarter protocols could encode more efficiently and send, say 4 ASCII characters representing 3 binary bytes. The one saving grace is that the data was almost always compressed. So even with the extra bytes caused by 7-bit data, the transferred number of bytes might even be smaller than the original file size.

One useful feature I wished they had added to the modems and BBSs of the day was support for the protocol used by a telecommunications device for the deaf (TDD). It is apparently a 5-bit protocol, but as far as I know, no non-specifically deaf-related BBSs used it. I think, though, even they favored common packages such as Kermit and Modem7. Being deaf didn't limit folks from using a full computer keyboard, and, hey, mixed upper and lower case is kind of nice. I think the only reason you would want access to the old, deaf-only protocol is to communicate with someone who just had the TDD equipment, and no networked computer. That probably was not a big enough market for modem manufacturers, but it would have been nice to have available for anyone who did need it.

| improve this answer | |
  • 1
    TDD support would have made it possible to use the TDD equipment found on some public telephones to phone into a computer system. – supercat Feb 15 '17 at 23:26
  • As for parity, I'm somewhat curious what it really accomplishes beyond maybe allowing a dumb terminal to output a "glitch" character when it would otherwise have output a seemingly-valid-but-wrong one. Data errors are so often combined with framing errors that forward error correction is often of limited use within a packet. Better would be to guard each little packet with an 8-bit CRC, and each group of packets with a 32-bit CRC (if the 8-bit CRCs match but the 32-bit one fails, either negotiate the 32-bit CRCs of all the packets or else retransmit the entire group). – supercat Feb 15 '17 at 23:32
  • @supercat I don't know the history, but the major protocols improved greatly over time. The very name "Modem7" (one of the most popular BBS packages) tells a story of major enhancement. What I do know is that whatever the modems and supporting software were doing, they were really solid. The only fails I can remember is if there were a major line glitch -- little brother picks up phone in other room and starts dialing, that sort of thing. Downloads improved to the point that they could continue from a complete disconnect or power loss. – RichF Feb 15 '17 at 23:42
  • It is not that the noise was so low, it's the MNP. At 2400 baud or more, working without MNP was virtually impossible, and as soon as you have MNP, you don't need any additional error detection above it. – Leo B. Feb 16 '17 at 2:32
  • @LeoB. Thank you for the info. I started at 300 baud. But I upgraded gradually as better modems were offered. I probably had 1200, 2400, 9600, 19.2k, and 56k over the years. ... And now I think 6 Mbps is slow. 🤓 – RichF Feb 16 '17 at 2:44
5

Parity is a "one-bit checksum over a single character". It can be used to detect single-bit errors in a serial asynchronous link (As the checksum is only one bit, two or more bits/char failed transmission can go undetected).

Parity "even" adds a bit so that the sum of all data bits in the byte frame is even, while "odd" parity does the same so that the sum turns out to be odd.

Parity is generated and verified normally by the UARTs in both the modem and the computer, and (at least in newer modems starting from ~1990) not transmitted over the modem link (which is typically syncronous and has no room for parity, but rather uses a much more complicated overlaid frame structure over the data to check for transmission errors and even do retransmissions over the phone line).

Parity on "dumb" (or older) UARTs normally sacrifices one of the eight data bits in the byte frame for parity - effectively shortening the byte to 7 bits, and limiting the range of transferrable bytes to 0-127, which is still enough to transmit the full range of ASCII characters. For binary transfers, some sort of Escape mechanism needs to be employed to be able to transfer the full range of 0..255. More modern UARTS newer than 1980 could (and can) transmit 8+P bits per frame and thus normally transfer a full byte in one character frame.

Parity is useful when you have very long lines between the RS-232 comms participants, as was the case in ancient building-wide (or even larger) RS-232 communications between terminals and the mainframe (or terminal server) where the long cables were prone to induced electrical disturbances. As mostly text was transferred, the missing data bit didn't really hurt. On a short piece of RS-232 cable between a computer and a modem, it's pretty unlikely to be needed.

8P[1-2] was used for binary transfers with non-terminal installations where the capability to transfer complete bytes was a must. The parity bit obviously produces a 12.5% overhead on transmission, wich is quite a bit - So transmissions using parity have less free bandwidth than such without. Note the start and stop bit also create some overhead. On an 8E1 connection (1 start bit, 8 data bits, one parity bit and one or two stop bits), you normally have up to 50% overhead bits to transfer, which is not really effective. So: parity makes a line slower, but more safe.

| improve this answer | |
  • What do you mean by 8P[1-2]? E = even, O = odd, N = no parity, P = ? – dirkt Feb 16 '17 at 15:42
  • 1
    I think here p is a stand-in for either E or O, it's the selected parity option. A better notation might be 8[NEO][1-2] – Peter Camilleri Feb 16 '17 at 16:00
  • Yep. Wasn't that difficult, apparently ;) – tofro Feb 16 '17 at 17:11
3

The main benefit of parity is that it was detected within the modem. It did not require processing power within the computer itself. Although, usually the modem would generate a "Parity Fail" interrupt if it occurred.

Depending upon the protocol, the receiving modem would reply to the sending modem with a parity fail e.g. NAK instead of ACK and the message would be resent. In some modems, if using 5-wire connections instead of 3-wire then this could also be done by flashing the CTS line.

I could show you any number of modem systems still in use that use 7-bit data, even parity, with 2 stop bits (7E2). Indeed, such systems are still being installed in quite large numbers because of their security.

| improve this answer | |
  • Chenmunka, I am confused. Does not "7E1" mean 7-bit data, even parity, 1 stop bit? If so, what would 7E1 with 2 stop bits mean? Also, how does parity help improve security (as opposed to reliability)? (This sounds sort of negative. I don't mean it to be. I'm just curious.) – RichF Feb 16 '17 at 10:40
  • @RichF: Whoops, well spotted - 7E2! Direct modem links - as opposed to LAN - are considered more secure as the only way to inject fake commands is to physically intercept the cable. Something that is easily detected. – Chenmunka Feb 16 '17 at 10:52
  • Ah, makes sense. More secure, both because of not being on the network and because the parity data streams are sensitive to any sort of violation. Cool. Is twisted-pair style wiring quiet enough to avoid passive invasion, or do such systems use fancier techniques to minimize data leakage along the wiring? – RichF Feb 16 '17 at 11:59
  • @RichF: Don't forget that LAN systems use some form of Longitudinal Parity Checking too. The forms vary but the principle is the same. – Chenmunka Feb 16 '17 at 12:22
  • 1
    Some terminals (the venerable ASR-33) had internal parity generation and detection; it wasn't the modem (in the dumb-modem 110/300 baud days) that knew to check parity. – Whit3rd Feb 20 '17 at 10:26
3

I worked with serial-based systems in the 80's and don't ever remember parity being useful for anything; it was simply something to get right when you set devices up. The effect of receiving bad parity was device-specific: some devices would simply ignore the character; some would show a character even though received incorrectly; at least one type of dumb terminal I remember printing a funny character (perhaps a tilde ~ ) in place of the incorrectly received character.

The original idea of parity checking was obviously to detect gross errors where 1 of the 8 bits in the character had got flipped in transit (perhaps in noise on a long cable). Obviously, it's of limited use, as a run of bad bits could easily render the parity overall as being correct.

If the 'end-application' is an interactive terminal or printer, you can obviously spot that the characters are corrupt, as a stream of rubbish comes out on the paper or screen. For file-transfer applications, or some kind of serial-based protocol (like the IBRO protocol they used to use in card-swipe terminals), you wouldn't depend on parity, but rather there would be some kind of better checksum. I remember sending frames that consisted of STX + data + ETX + plus a one-byte checksum that was calculated from the data bytes. If the checksum calculation didn't work out the same at the receiver, you would send a NAK, and the sender would send the frame over again. Some similar kind of logic exists in Kermit, IIRC.

You mention tn3270, but this is really on a different timeline to the one you suggest. IBM networks used synchronous links carrying SNA protocol encapsulated in SDLC frames at the low level this data was sent serially but with special start/stop patterns that couldn't appear in the data, and with a 16-bit cyclic redundancy check (CRC) to make sure the data was good at the receiver. The terminal protocol was 3270 (using EBCDIC coding, as you mention), and this was a whole parallel world to ASCII-based PCs with their asynch serial communications. This proprietary world of SNA communications lasted through the 90's until TCP/IP and the Internet ultimately displaced it. The tn3270 that you describe is a way of encapsulating 3270 data into TCP/IP (telnet) packets, as a way to integrate the last few distributed IBM mainframe users into the new world of TCP networks.

CRCs of varying lengths are used in modern communications, as it allows you to detect more than one error in frame, and is a good indication of the frame being overall somehow corrupted. Going further, there are forward error correction systems in use now that allow you to correct a small number of bits in error, as well as detect a frame that is corrupted beyond repair.

More detail about how serial communications works can be found in the data sheets for UART chips. PC designs used chips like the 8250 and 16550, but their modern descendents (like the Maxim MAX3109) have all the same ideas built-in.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.