The Gateway to Computer Science Excellence
First time here? Checkout the FAQ!
x
+1 vote
127 views
Why CRC is added at the end of frame?
asked in Computer Networks by (315 points) | 127 views
+1
CRC used in error detection is an example of what are known as systematic block codes
Block means that it operates on block of bits at a time and systematic means that it appends check bits rather than rewrite all of it's data bits
The reason why systematic codes are better than other kinds of codes where we encode the check bits in data bits itself is something not very clear to me.I read some blogs saying it has to do with on the fly calculations of CRC or it may have something to do with its mathematics of different kinds of error it is able to detect , but I did not find them convincing
+3
@Rameesh, You've mentioned about the working of CRC,being one of the methods of detecting errors but please note the point where it says that why it is appended at the end of the frame.
0
exactly my question is why?
+2

placing the CRC at the end of a frame reduces packet latency and reduces hardware buffering requirements. On the transmit side, hardware can read and transmit bytes of the frame immediately. The transmitter calculates the CRC on the fly as data passes through, then simply appends the CRC the tail of the frame.

Consider the alternative where the CRC comes somewhere in the Ethernet header. Hardware must read and store the entire frame in order to calculate the CRC. This amounts to a large look-ahead operation and adds significantly to transmit latency and hardware cost. The situation also becomes more complex for the receiver as well.

Ref:https://stackoverflow.com/questions/13210355/why-is-the-frame-check-sequence-at-the-end-of-an-ethernet-frame-and-not-somewher

0
@Sukanya i see some problems with the above mentioned reasoning as -
Let us consider a scenario involving a typical layer 2 forwarding procedure where CRC predominantly does error detection .We have two major paradigms for forwarding at this layer - (i) store and forward (ii)cut through switching , store and forward is when the switches wait for full packet to arrive and cut through switching is when the decision is made quickly after the preamble and dest. MAC is read. So the transmit latency and buffering problem is irrelevant in store and forward architectures as anyways the whole packet is going to get stored . For cut through switching - ihe CRC is not even checked against and even erroneous packets get forwarded so cut through switching does not bring CRC into picture. If you look at the generator switch , it gets informaiton as a complete frame from network layer above ,in fact it gets a full packet which it converts to multiple frames - so clearly no such buffering and latency problems there also.
0

Thanks, Rameesh

I can't be reaching a perfect solution...

Have you any point?

+1
It is not "compulsory" to put CRC at the end of a frame. It depends on your implementation and implementation depends on where you are going to use it. So if you feel like your case requires CRC in the middle(or somewhere else), you can do it. But that implementation would be expected to work only within your own network as in the standard one CRC is always appended at the end. It is more like a standard rather than a compulsion. Standard doesn't always need to make sense but here, as mentioned by Sukanya, hardware buffering can be one of the many reasons we can think of putting CRC at the end to make it a standard.
0

In fact the placement has very much to do with what CRC is about: polynomial division. If you move the CRC remainder to the front of the payload bitstream, you will invalidate some of the CRC properties, such as burst error detection.

The key to understanding this is the fact, that a CRC is always operating on a stream of bits, not bytes, or a block of payload. Sometimes you can find fault CRC implementations, where bits are transmitted little-endian, but actually the CRC is calculated big-endian (in term of bit ordering within individual bytes).This argument seems a lil bit more significant still. :)

1 Answer

0 votes
there are two benefit  of CRC at the end of frame

1st at the  receiver side

at the transport layer of receiver side when the data passes through  the TL   ,TL calculate the CRC as the data passes through it and at the end of the frame TL layer calculate whole of the CRC bit and immediately matches it with the CRC bit which is actually attach to the frame if it found that both CRC (one which is calculated and second which actually attach to frame) are same then data is correct otherwise  something is wrong (may be data or CRC) .

and same process can happen at DLL

second at the sender  side

placing the CRC at the end of a frame reduces packet latency and reduces hardware buffering requirements. On the transmit side, hardware can read and transmit bytes of the frame immediately. The transmitter calculates the CRC on the fly as data passes through, then simply appends the CRC the tail of the frame
answered by (357 points)


Quick search syntax
tags tag:apple
author user:martin
title title:apple
content content:apple
exclude -tag:apple
force match +apple
views views:100
score score:10
answers answers:2
is accepted isaccepted:true
is closed isclosed:true

39,619 questions
46,721 answers
140,296 comments
58,013 users