| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 270.1 | good question | LEVERS::ANIL | | Wed Jun 05 1991 22:24 | 9 |
| Translating bridges, such as the ones we make, have to modify
the packet and cannot maintain end-to-end CRC, as you say.
However, without going into it in much detail, our hardware
contains sufficient memory protection logic that packet
corruption is not ever likely to happen.
Yes, the 600 series will maintain end-to-end CRC's between Ethernets.
Anil
|
| 270.2 | | KONING::KONING | Eesti vabaks! | Thu Jun 06 1991 10:58 | 9 |
| More specifically, the checking (or rather, re-checking) of the incoming
CRC, and the generation of the outgoing CRC, are done at the same place
in the bridge (the same chip, if I remember correctly).
The result is that the probability of errors slipping by is about the same
as the inherent probability of errors slipping by CRC in the first place
(which is what the requirement is).
paul
|
| 270.3 | think probability while thinking packet corruption | TALLIS::REGE | | Thu Jun 06 1991 11:03 | 9 |
| Ref. 270.1
> However, without going into it in much detail, our hardware
> contains sufficient memory protection logic that packet
> corruption is not ever likely to happen.
"Packet corruption is not ever likely to happen" are very strong
words. It is always prudent to think probabilistically
when the issue is one of packet corruption.
|
| 270.4 | | KONING::KONING | Eesti vabaks! | Thu Jun 06 1991 16:28 | 3 |
| Re .3: correct -- my comment in .2 addresses this.
paul
|
| 270.5 | Thanks for the explanations | ARRODS::SWANSON | | Fri Jun 07 1991 06:28 | 3 |
| Thanks very much for the clear responses.
Dave
|
| 270.6 | Even better CRC protection | ORACLE::WATERS | I need an egg-laying woolmilkpig. | Wed Jun 19 1991 11:06 | 15 |
| >More specifically, the checking (or rather, re-checking) of the incoming
>CRC, and the generation of the outgoing CRC, are done at the same place
>in the bridge (the same chip, if I remember correctly).
A clearer statement:
In DEC's 10/100 bridge, at no time is a forwarded frame not protected
by CRC. Whereas another bridge might use byte parity to protect a
frame sitting in memory waiting to be transmitted, DEC's bridge uses
byte parity AND the original or new CRC to protect forwarded frames
in the memory.
As Paul said, this is accomplished by re-checking the original CRC
as the new CRC is being computed. I suspect that the entire data
path in our bridge, for forwarded frames, is protected by CRC--
possibly even throughout the single chip that recalculates the CRC.
|