|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"julian_satran@il.ibm.com wrote: > Yes - and I think that the effects can be observed even with random errors > because of the weakness of the checksum. Julian, This paper shows that the TCP checksum is weaker in case of non uniform data. But we are interested by the overall performance Link layer CRC + TCP checksum. And if i look at the conclusion of this paper "VII. Observations and recommendations" there is: page 540 upper left "The ATM CRC will fail to detect a splice approximately at a rate of 1 in 2^32. Therefore the chance of the TCP checksum being called upon to detect a splice is much less than 1 in 10e-8 * 2e-32 or less than one chance in 10e17" Hence i get an overall escape rate of 1 in 10e17 or in other words 0.000000000000001% How do you get this number of 0.0002% ? Regards, Pierre > > > Julo > > Pierre Labat <pierre_labat@hp.com> on 04/04/2001 23:13:38 > > Please respond to Pierre Labat <pierre_labat@hp.com> > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI ERT: data SACK/replay buffer/"semi-transport" > > julian_satran@il.ibm.com wrote: > > > SNACK is here for two reasons - Status retry (which is cheap) and Data > > retry as a side benefit. > > CRC errors are not that rare (although we don't have real data the > > simulation with file systems seem to indicate that numbers could be as > high > > a 0.0002%). > > Julo, > > Could you explain how you get this number. > Does it come from > J. Stone et. al "Performance of Checksums and CRC's > over > Real Data" > IEEE/ACM Transactions on Networking, Vol. 6, No. 5, > October 1998 > > http://dev.acm.org/pubs/articles/journals/ton/1998-6-5/p529-stone/p529-stone.pdf > > ??? > I don't see how you got this number. > What i saw was: > Less than 1 escape in 10e17 segments when taking into > account the link layer AAL5 CRC. (see page 540 left > column > on top). > > Regards, > > Pierre > > > A restart of link - is expensive (slow start) and even if they > > are far lower for many applications a slow start is a painfull event. > > > > Removing them from the spec is not a path we should take lightly. > > > > Julo
Home Last updated: Tue Sep 04 01:05:10 2001 6315 messages in chronological order |