So this isn't exactly specific to 4.4, but I think this is where the question fits best.. (Boy, as a moderator on other forums I hate it when people say that as I usually end up having to move the thread - so I apologise in advance if that's the case here!)

 

I've just finished building an unRAID server (hardware spec below for the curious) and I'm about to start transferring some ~700Gb of data from my old Linux box (just a big LVM array).  Before I started I thought I'd do some test transfers and make sure files remained intact after copying (given how long everything will take to copy over a 100Mb wired LAN).

 

In all tests I'm transferring files to unRAID via FTP (preferred since it's many times faster than smbclient for some reason), and transferring files from unRAID with smbclient.  All transfers are done from & to my old Linux box (Ubuntu, file integrity here is no problem - I check every transfer to the box and it's always come up clean)

 

 

For my first test, I transferred an 18Gb .mkv file to the unRAID with ftp, and back again via smbclient - here's the md5 sum's of the files ('dozer' is the Linux box, 'oracle' the unRAID box) -

 

Before copying (on the source):

aaronjb@dozer:/mnt/data/HD_Movies$ md5sum Iron\ Man\ \(2008\).BluRay.1080p.DTS.VC1.mkv
dbfc9a9aa686f06d81d87a51e0aeb08c  Iron Man (2008).BluRay.1080p.DTS.VC1.mkv

 

After copying via FTP (on the destination):

root@oracle:/mnt/user/HD_Movies# md5sum Iron\ Man\ \(2008\).BluRay.1080p.DTS.VC1.mkv 
3b7b4d1b4dade557ab0d92bf7d60d6ce  Iron Man (2008).BluRay.1080p.DTS.VC1.mkv

 

After copying back via smbclient (on the source again, different file location):

aaronjb@dozer:/mnt/data$ md5sum Iron\ Man\ \(2008\).BluRay.1080p.DTS.VC1.mkv
290fbb60a83da07572a34a3295502ffc  Iron Man (2008).BluRay.1080p.DTS.VC1.mkv

 

As you can see, no two md5sums are the same - this does not bode well for file integrity, surely...

 

 

I checked the logs on each machine after the transfers, there are no errors relating to the NICs, no increasing error counts reported via smart or anything else to indicate a transport or storage problem.. so what gives?

 

 

Limited tests with smaller files (text and binary) all seem to work fine, but with large binary files.. something strange is afoot..

I cannot remember any others with similar issues that did not turn out to be hardware related.

 

First thing to double-check is to run a memory-check, preferably through several complete cycles... if it is mis-behaving, nothing else will be consistent.

 

Most elusive were the early nforce2,3 & nforce4 chipset related errors.  The only fix in those cases was to replace the motherboard.  see here for details: http://lime-technology.com/wiki/index.php?title=Hardware_Compatibility#Hardware_Known_to_NOT_Work

 

Most people with similar problems detected them when they performed a parity check after they had loaded data.  Each parity check in turn seemed to identify different parity errors.

 

You did not attach a description of your hardware. (obviously, you intended to do so) 

 

Although you probably know to do so, are you sure you had the ftp client in  "binary" mode?  That would make a HUGE difference in any checksum.

 

Joe L.

 

 

Yep, you're right - it looks like it's probably hardware related; I just tried another transfer via NFS this time to complete the set of transfer mechanisms, and yet again the md5sum fails.. A partial parity check shows:

 

Check will start a Parity-Check.

(Last checked on 4/20/2009 12:47:02 AM, finding 5 errors.)

 

Unfortunately it's all new hardware, so faults could lie anywhere, and will probably be expensive to find   This is the point I start wishing I'd just bought an off-the-shelf NAS :-/

 

Anyway, the hardware is:

Icy Dock MB-455SPF 3 x 5.25" Bays

ASUS V-60 Quiet Intel LGA775 CPU Cooler

850W NorthQ Black Magic Flex Modula

Intel Core 2 Quad Q8200, Yorkfield

4GB (2x2GB) Corsair TwinX DDR2 XMS2

Gigabyte GA-P31-ES3G

Lian-Li PCA17A Aluminium Silver Mid

1TB Hitachi Deskstar 7K1000.B, 3.5"

 

Actually it's not the NorthQ PSU anymore - that was DOA, it's an X-Power 700W unit now - the rest of the hardware was chosen either because it's used in the pre-configured systems, or because there were reports of it working on the forums already (or at least a very close cousin, in the case of the motherboard).

 

My USB stick is also an unbranded 128Mb unit as that was the only one I could find around the house that would boot (I think you can add Maxell UBS sticks to the list of known-bad hardware...).

 

I'll leave memtest86 running overnight & through tomorrow while I'm at work, and come back to this tomorrow evening.

 

Thanks for the help,

Aaron

 

[edit: edited because my command of the English language completely leaves me at 1am! ]

I have no clue as to your native language, but your English is near perfect. You need not make any apologies about it.

 

Your XMS2 memory strips need non-standard timings and/or voltage depending on the exact specific speed you purchased.

I see three at least different versions described on the Corsair web-site, each with their own voltage and timing settings.  I know most motherboards have an "auto" setting, but they often get it wrong.  The voltage and BIOS settings in the MB BIOS would be first on my list to double-check.

 

See here: http://www.corsair.com/products/xms2/default.aspx

 

Joe L.

I have no clue as to your native language, but your English is near perfect. You need not make any apologies about it.

 

Actually my native language is English But at 1am the quality of it does seem to decline, rather! (Of course, now I'm slightly disappointed that it's only 'near' perfect and not perfect  )

 

Your XMS2 memory strips need non-standard timings and/or voltage depending on the exact specific speed you purchased.

I see three at least different versions described on the Corsair web-site, each with their own voltage and timing settings.  I know most motherboards have an "auto" setting, but they often get it wrong.   The voltage and BIOS settings in the MB BIOS would be first on my list to double-check.

 

It was all so much easier when I started building PCs (back in the days of the 286), I swear I did notice that there is a known issue with some BIOS revs which causes the voltage to be incorrectly detected, and I double checked mine was unaffected by that, but I forgot to check the rest of the timings so that's definitely worth doing - especially as memtest86 bumped into some 15,000 errors overnight!

 

Here's hoping it's a timing thing, and not the second piece of equipment to be DOA from that supplier..

 

I'll check the timings and soforth tonight when I'm back home from work, thanks for the pointers

 

Aaron

I have no clue as to your native language, but your English is near perfect. You need not make any apologies about it.

 

Actually my native language is English But at 1am the quality of it does seem to decline, rather! (Of course, now I'm slightly disappointed that it's only 'near' perfect and not perfect  )

Oops... I mis-interpreted what you had originally typed.  I interpreted it to indicate you were multi-lingual and that English was not your native language.   I  guess I need to work on my command of English when responding

<embarrassed>removing foot from mouth now</embarrassed>

 

memtest86 bumped into some 15,000 errors overnight!

 

Here's hoping it's a timing thing, and not the second piece of equipment to be DOA from that supplier..

 

I'll check the timings and so forth tonight when I'm back home from work, thanks for the pointers

 

Aaron

I think you are on the right track... you cannot ignore 15,000 memory errors...   As I said, there were at least three different speed versions of the memory you listed, each with different timings and voltage...   It might be one bad strip.  Try with one and then the other to isolate if the BIOS setting looks good.

 

Oh yes, after you fix the memory issue the first parity check might still find and correct parity errors (this time the calculated value is correct, the old data stored previously on the parity disk incorrect)   A subsequent parity check should have no errors.

 

Joe L.

Oops... I mis-interpreted what you had originally typed.  I interpreted it to indicate you were multi-lingual and that English was not your native language.   I  guess I need to work on my command of English when responding

<embarrassed>removing foot from mouth now</embarrassed>

 

Don't worry - no offence was taken, it's not like you can see my birth certificate through the Internet

 

]I think you are on the right track... you cannot ignore 15,000 memory errors...   As I said, there were at least three different speed versions of the memory you listed, each with different timings and voltage...   It might be one bad strip.  Try with one and then the other to isolate if the BIOS setting looks good.

 

Indeed, the units I have are these CAS 5-5-5-15, and I think that memtest86 was reporting them as 5-5-5-18, so perhaps the BIOS auto detection has gone a little awry. I'll double check that when I get home and rectify any incorrect settings, then run another memtest.  Assuming it all comes up clean I'll do another parity check and test transfer

 

Thanks for all the help so far,

Aaron

Indeed, the units I have are these CAS 5-5-5-15, and I think that memtest86 was reporting them as 5-5-5-18, so perhaps the BIOS auto detection has gone a little awry. I'll double check that when I get home and rectify any incorrect settings, then run another memtest.  Assuming it all comes up clean I'll do another parity check and test transfer

 

Thanks for all the help so far,

Aaron

According to this http://www.corsair.com/products/go.aspx?pn=TWIN2X4096-8500C5

your voltage should be set to 2.1 volts... 

 

The slower speed 5-5-5-18 memory only needs 1.9 volts in its specs.  Perhaps it both the voltage and timing are contributing to the errors.

 

Joe L.

After running memtest again when I got home, I noticed that when using SPD to set the RAM speeds, they were detected as CAS 5-5-5-18, 2.1v and for some reason were running at 1110MHz (3.33x333MHz) which is faster than their rated speed of 1066MHz.

 

Manually setting them to CAS 5-5-5-15 (per their datasheet), leaving the voltage at 2.1v and reducing the frequency multiplier to 3x gives me RAM that's running at 1000MHz (3x333MHz) and seems to pass a memtest test so far, which is good.

 

It's interesting that when manually setting the multiplier in the BIOS there isn't actually an option that gives me 1066MHz - the multiplier jumps straight from 3x to 3.33x, and by default the BIOS picks the faster option.. ah, if only I understood RAM settings - it's been 10 years since I was really paying attention to PC techologies properly, back when that was my job

 

Anyway - thanks for all the help! I suspect it'll be OK now the RAM is working properly, so after memtest completes at least one pass I'll boot unRAID back up and run some more transfer tests.

 

Aaron

One final update - now that the RAM is behaving correctly, transfers to & from work just perfectly.

 

Thanks for all the help!

 

Aaron