Merging with Block check character

Against :

FCS is a term that is used in Data link layer protocols in particular, while BCC is used in another world. - DéRahier 12:38, 1 October 2007 (UTC)[reply]

Strongly Against as per DéRahier. FCS appears at the end of Ethernet frames at layer 2, but BCC appears periodically within IBM bisync communications with a mainframe at layer 5. If the bisync com were contained in Ethernet frames across a LAN or MAN or WAN, then there would be a BCS at layer 5 within the payload of the Ethernet frame and then an FCS at layer 2 in the trailer of the Ethernet frame. The FCS in the Ethernet trailer is 4 bytes and uses the polynomial x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1. The BCC in the IBM terminal HDLC stream is 16 bits and uses the polynomial X^16+X^15+X^2+1. Ethernet frames are not an HDLC stream nor vice versa. I must admit that I am annoyed with people who do nontechnical "copy editing" such as merging articles that shouldn't be merged and deleting articles that shouldn't be deleted without doing the necessary homework. Simple Google searches on "Ethernet FCS polynomial" and "IBM BCC polynomial" pulled up this information quite easily in the first few search results. I am afraid that I see little commonality at all between FCS and BCC other than they are a bunch of ones and zeros. Perhaps we should merge all teledatacom and computer articles into one article called Ones and zeros. Please do some of the obvious Google searches to see if topics are synonymous *before* suggesting that their articles be merged. —optikos 11:31, 4 October 2007 (UTC)[reply]

I agree. I have found too much recent merging and simplification of wikipedia articles, which eliminates useful information. I gave up helping. I came here searching for relevance for fcs errors (when you find them) I know you tend to see them with a duplex mismatch, but forgot which side shows the fcs errors.--128.196.164.121 (talk) 19:58, 26 November 2007 (UTC)[reply]

For They're both the same thing with different names, and should be described (and understood) together. Protocols get encapsulated within others all the time; there's no limit on the number of checksums you can have in a single packet if you count all the different layers of encapsulation.

The complaint above seems somewhat ridiculous to me. Ethernet and HDLC checksums not just both bits, they're both fixed-length CRC trailers protecting variable-length data frames. (Even a simple longitudinal XOR is actually a CRC with a polynomial of x⁸+1.) The only difference is the polynomials used and the terminology used to describe them. This is not "nontechnical copy editing", it's good pedagogy recognizing multiple instances of the same basic principle and explaining them together. I expect harmonic oscillator to explain both the mechanical and electrical forms, and I expect one unified article to explain checksum trailers. 71.41.210.146 (talk) 13:35, 12 January 2008 (UTC)[reply]

Well, I consider your desire to conflate a BCC character in a transmission-block string at layer 5 with a FCS bitfield in an 802.3 frame at layer 2 to be ridiculous too. To find the location of a BCC at the end of the transmission-block string, we parse that transmission-block string by searching for EOB, EOT, ETX, or ETB characters as mentioned in the transmission block article and in Federal Standard 1037C. There is absolutely no searching for EOB, EOT, ETX or ETB characters in an 802.3 Ethernet frame. We don't go looking for EOB, EOT, ETX, or ETB characters to find FCS. Why? Because an 802.3 Ethernet frame is not a transmission block because it is not a string of graphemes. Layer 5 might have graphemes, but layer 2 absolutely certainly does not. This is an incredibly fundamental difference between layers 2 and 5. Instead, Layer 2 has frames (not transmission blocks) where the frame has some sort of header, and some sort of a priori determination of length, and optionally (present in 802.3's case) a frame trailer, where the FCS is located. So in layer 5 we see a string of graphemes that are parsed to find the end of transmission block via a posteriori means. In layer 2 we see a frame whose length is known a priori from the length field in the 802.3 frame header and is not organized into a string of graphemes. Therefore, perhaps you can see that I consider your desire to conflate entirely separate and different concepts as itself ridiculous. Therefore, trying to play a trump card that claims that my position is ridiculous and yours is not is probably not a fruitful line of reasoning, because we both consider each other's premise deserving of ridicule and exposure of the facts. For me, I think that the numerous facts are on my side of the discussion that separate BCC from FCS quite distinctly. Let us count the ways in which they are different:

1) FCS is 32-bit, but BCC is 16-bit.
2) FCS is calculated by the polynomial x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1, but BCC is calculated by the polynomial X^16+X^15+X^2+1.
3) FCS appears within an 802.3 Ethernet frame, but BCC appears within a transmission-block string.
4) FCS's position is determined a priori by the 802.3 frame-header's length field, but BCC's position is determined a posteriori by parsing graphemes, looking for EOB, EOT, ETX, or ETB graphemes from a character-set.
5) FCS appears in layer 2 in the OSI protocol-stack reference model, but BCC appears in layer 5.
6) FCS is internationally standardized by IEEE, but BCC and HDLC are IBM proprietarianism.
7) FCS is an aspect defined by its layer-2 technology (802.3) to determine the validity of that layer-2 technology's frame (as opposed to being corrupted), but BCC is a layer-5 add-on that supplements a layer-2 technology (HDLC) to rectify an insufficient amount of validation in that layer-2 technology.
8) FCS is known to layer-2 802.3 Ethernet, but BCC is unknown to its corresponding layer-2 technology: HDLC.
9) FCS is always calculated at line rate by the framer silicon or NPs that are responsible for layer-2, but BCC either is calculated by layer-5 software at general-purpose-software speed or imposes an arcane layer-2-to-layer-5 jump to be performed by the HDLC framer silicon or NPs.
10) FCS is a subclass of 32-bit CRCs, but BCC is a subclass of 16-bit CRCs. 16-bit CRC and 32-bit CRC are a subclass of CRC in general. FCS and BCC are second-cousins, not siblings and not even first cousins.
Wow! off the top of my head I have listed 10 ways that they are quite different and undeserving of article conflation. I once again reiterate: I do not see how "they are both the same thing with different names" as you claim. That is a quite adept David-Copperfield-like "different name" that can 1) double the number of bits from 16 to 32, 2) swap out HDLC for 802.3 layer-2 technology, 3) swap out IBM proprietarianism for an IEEE international standard, 4) swap out locating via a posterioi string parsing with locating via a priori arithmetic, 5) swap out a layer-5 & layer-2 symbiosis for an entirely layer-2 self-contained solution, 6) swap out silicon and NPs at layer 2 for general-purpose software at layer 5, and so forth. That is quite a "name difference" that can accomplish all of that for "the same thing"! That is a very hard-working "name difference". Too hard-working, perhaps. But then again, if FCS and BCC are "the same thing", why would a "name difference" need to accomplish all of this drastic swap-out in the first place?! If they were the same thing to begin with, none of that swap out would be necessary for the so-called "name difference" to accomplish as one of its duties.

Harmonic oscillator is a good superordinate term (i.e., name of a superclass) that contains electrical harmonic oscillator and mechanical harmonic oscillator are subordinate terms (i.e., names of subclasses). An FCS is not a BCC, in the same way that a mechanical harmonic oscillator is not an electrical harmonic oscillator. A BCC is not an FCS, in the same way that an electrical harmonic oscillator is not a mechnical harmonic oscillator. What superordinate term (i.e., what superclass) do you propose to house any alleged commonality between BCC and FCS? Are you proposing merging both BCC and FCS into the CRC article? If so, that is not what is proposed. I stand firmly against merging a subclass into another subclass. I am willing to entertain merging all subclasses into a superclass as sections within the superclass article. Should we merge the articles for the subclasses sport-utility vehicle and pick-up truck? They are both subclasses of the superclass passenger vehicle. So, should we merge sport-utility vehicle into pick-up truck or should we merge pick-up truck into sport-utility vehicle? Or should we merge both sport-utility vehicle andpick-up truck into passenger vehicle, much as automobile already has been? —optikos (talk) 19:05, 13 January 2008 (UTC)[reply]