On Mon, Mar 21, 2016 at 5:09 PM, Nem W Schlecht wrote: > On Mon, Mar 21, 2016 at 3:49 PM, Erik Soderquist >> I expect if you did a capture of the traffic, you'd find the traffic >> itself has inconsistent data... > > If the traffic was bad, I'd suspect the byte count to be off as well, > but if the byte count is consistent (which it is here), then the > checksums should all be the same.
One random bit flipped in a stream of over 6.6M bits (not counting overhead) would not change the byte count unless that bit happened to be in the file description data rather than the file data (statistically unlikely), but would affect the cksum results. To date, I've never seen the byte count off when I had network problems corrupting files on SMB or NFS (outside of complete connection loss), but I've certainly had corrupt reads and writes of the actual file data. In the presented sampling, 6 out of 11 cksum results are consistent, indicating that the average failure rate is slightly better than 1 in 10M bits. > Have you tried a different hashing program, like md5sum or shasum, to > see if you still get inconsistent results? I would also be interested in these results, as it would focus or rule out cksum as a potential culprit. (Obviously from my previous post, I have my suspicions already, but confirmation is still the best approach). I would also be interested in if you can do the same cksum/md5sum/shasum on the server side and use some kind of semaphore to trigger the check and get the results. -- Erik -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
