This message is from the T13 list server.
> > However, I still don't see an explanation for why this error > reporting (using ICRC) was not in SATA 1.x or in ATA/ATAPI-7. JWW> Oversight and an original thought (there were a number of proposals at the time) that ALL commands would be come DMA type commands (even ID page... remember that -:) > I understand that SATA has CRC on all data packets (FIS) > transferred on the SATA interface. If using ICRC to report > SATA CRC errors is now needed why was it not needed 2 years > ago? JWW> Its NOT about needed it, its about improving it... No other standard does any "improvements" right ? > I'm still waiting for someone to explain how these SATA > CRC errors are reported by the millions of SATA devices that > have been shipped that do not support this new use of ICRC > for PIO transfer commands, JWW> You know this answer... they report it just the same as a PATA drive... no better, no WORSE, they don't > and for someone to explain what > risk to data integrity when using devices that do not > implement this new use of ICRC use during PIO transfer > commands. JWW> 99.99999% of all user data is shipped using DMA (you can't do video or audio playback without skips, nor meet WHQL without DMA support) so it means VERY little in regards to user data integrity. > Someone in SATAIO land must understand this > problem/question/issue and understand the serious question > this raises concerning the data integrity of the SATA > interface devices shipped during the last 2 years? JWW> CRC for PIO commands is a VERY VERY VERY VERY minor thing. The data integrity is just as much a function of the system (Host, cable, drive, power supply) for SATA as it is PATA. > > > It was NOT that SATA needed it, it was that SATA could improve over > > PATA. > > Yes, SATA can improve over PATA. But why did we have to wait > two years to get a documented method for reporting SATA CRC > errors? Surely someone in SATAIO land can answer this question? JWW> ONLY for PIO commands that are only used for a sector here or there (Idpage, a SMART log page there -:) > > > Re: Host compatibility > > Yes, you will need drivers that know about this new feature to take > > advantage of it. > > You are saying that SATA is not compatible with PATA and that > anyone using SATA devices via a SATA host that emulates PATA > is using devices that place their data at serious risk of > corruption. JWW> NO NO NO NO NO... its all about improvement over PATA > Of course you are not the first person to say > this. So why have not tell people what the risk is? What is > the error rate (many people can see that it is higher than > native PATA)? JWW> I have seen no data that a properly design SATA system has ANY higher error rate than a properly design PATA system. Go put a 1 meter 40 conductor cable on a PATA system and run UDMA-100 and let me know how many errors you get.... (Fry's sells a 10 connector PATA cable) > The fact that I have asked these questions so many times with > no answer tells me that one of two things is going on... > Either a) there really isn't anyone in SATAIO land that > understands the basic idea of data integrity (I can't really > believe this), or b) there is some reason SATAIO does not > want to reveal the problems of error reporting in SATA (and I > sure hope this isn't true). But SATAIO needs to answer these > questions so that everyone can understand the true nature of > SATA reliability. Just saying SATA is better than PATA > doesn't make it so. JWW> Its because you ask the question in the following way: Have you fixed the data integrity issues yet ? If someone answers your question one way, they "admit" to data integrity issues, and if they answer the other way, they "admit" to there use to be data integrity issues ? 2nd, you are barking up a tree that does not exist.... there is no massive SATA data integrity / reliability issue for properly designed systems. Jeff > > Hale > > -- > > ++ Hale Landis ++ [EMAIL PROTECTED] ++ > >
