EpoX 9NPA+ Ultra OK to use with unRAID?

[vsonerud]

Hello!

 

I am thinking about building myself a new computer and use my old (current) one as a fileserver running unRAID.

 

I am therefore wondering if anyone has experience with using this specific motherboard for running unRAID.

 

The motherboard is:

 

Epox 9NPA+ Ultra

Specifications here: http://www.epox.com.tw/eng/products_content.php?ps=335

 

On the hardware compatibility list in the unRAID wiki, the EpoX EP-8NPA SLi motherboard is listed as a known working motherboard.

Specifications here: http://www.epox.com.tw/eng/products_content.php?ps=375

 

The main difference between my motherboard and that one is tha the 9NPA+ Ultra board uses the Nforce 4 Ultra chipset, whereas the Epox 8NPA SLI uses the NForce4 SLI chipset.

 

After reading this forum, one easily gets the impression that the Ethernet-chip support is a big issue. The Epox 9NPA+ Ultra and the Epox 8NPA SLI however both use the same chip:

VITESSE VSC8201RX Gigabit Ethernet

 

Anyone who knows if there are problems with this ethernet chip?

 

But since the Epox 8NPA SLI is listed on the 'Hardware compatibility' list in the unRAID wiki, shouldn't this be ok?

 

 

 

[RobJ]

I'll start with the positives:

  You should not have a problem with networking support, I believe it uses the forcedeth driver.

  And I like Epox, currently have an Epox MF570 and an AF590, and recommend them, even if the company is having major problems.  A great place for Epox boards, at bargain prices, is the EpoxStore:  https://www.epoxstore.com/Default.asp.

  And I like the nForce chipsets, so long as they are nForce 5 series or later.

 

I have very negative feelings about anything nForce 4 related (or earlier nForce series), although a few nForce4 boards work for some.  I had a Biostar nForce 4 Ultra board.  Rather than repeat myself, search nforce, or see these threads (mostly my opinions):

http://lime-technology.com/forum/index.php?topic=1741.msg12116#msg12116 - my experience with them

http://lime-technology.com/forum/index.php?topic=1061.msg7227#msg7227 - summary of my problems

http://lime-technology.com/forum/index.php?topic=1495.msg10080#msg10080 - data corruption issues, more later in thread

http://lime-technology.com/forum/index.php?topic=1488.msg10102#msg10102 - more of the same

http://lime-technology.com/forum/index.php?topic=441.msg2948#msg2948 - old thread, IDE problems

http://lime-technology.com/forum/index.php?topic=1693.msg11568#msg11568 - more on my MF570

 

[vsonerud]

Hello again!

 

6 months later I have still not converted my nforce4 ultra based system to unRAID, but finally having another new computer, makes it even more relevant now.

 

BUT I am very worried about any potential (silent) data corruption issues with nforce4 and unRAID.

 

I have read all nforce4 threads here on the forum, as well as Googled a LOT, but I am unable to find any definitive answer whether this issue has been sorted out/fixed in newer Linux kernels ?

 

Found a long thread here for instance, but it doesn't tell me if this has been fixed in the "newer" Linux kernels:

 

 

http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-12/msg00416.html

 

So, does anyone here know anything more regarding this issue?

 

 

 

 

[RobJ]

Following your link, and dozens of related links, sure brought back some bad memories!

 

It does look like some progress has been made.  There is a boot parameter iommu=soft that seems to be successful so far, in all tests, at avoiding all data corruption.  This parameter turns off the use of the hardware iommu.  What is interesting is that it is off by default for Intel boards, and is not used at all by Windows, so that seems to explain why the data corruption issues have not appeared for Windows users or Intel users, but so far seemed to involve AMD users with Linux and nForce chipsets.  There is more related work being done, but is not scheduled for inclusion in the Linux kernel until 2.6.28, which I don't believe is due until sometime next year.

 

To test, I would set up a simple 2 disk unRAID Basic system, a data disk and a parity disk, and make sure it is readable and writable from a desktop machine.  Then set up a repeatable test case, with a very large file (4 gigs or better) and a mechanism to test for corruption.  That could be as simple as using a zip or 7z or rar file or files, that you can run a test function on, to exercise its built in CRC checking function.  Or you can use the command fc to compare the written file with its local copy.  Then run your test cases, until you have a repeatable way to force compare errors, or CRC errors, etc.  Then add the iommu=soft parameter to the append line of the syslinux.cfg file on your flash drive, and test several more times.  Hopefully, you should not get any more data corruption errors.

[vsonerud]

RobJ: Thank you for taking the time to try and find answers to my problems.

 

Earlier today, before you replied, I was actually trying to test if my system is affected by any data corruption issues. But  I am not 100% sure if I have tested sufficiently thorough yet, or in a way which would most likely provoke data corruption.

 

What I did was:

 

* Copy some large files (16 GB and 9 GB) from my Windows XP machine to my new Windows Vista machine.

* Check that the files have the same md5 checksum on both machines: checked ok

* My Windows XP machine was then booted with a basic unRAID 4.3.final

* I was also utiilizing the new 'unmenu' awk scripts by Joe L. to easily mount all of my existing NTFS drives and also have them as SAMBA shares.

* On my Windows Vista machine I then executed a file comaprison using: fc.exe /b largefile \\TOWER\share\largefile

* The file comparision always executed well and no differences were found. I repeated the file comparison several times for both the 16 GB and 9 GB files.

* The 16 GB and 9 GB files on the unRAID machine were residing on a SATA drive connected to the onboard nForce4-ultra SATA-controller.

 

From discussion I have found while googling it seems that the data corruption happens with both SATA as well as PATA drives and is also not limited to the onboard SATA controller of the Nforce4 mainboards, but also for instance happens on PCI Promise TX2 cards. And the main "suspect" has been Memory Remapping, especially on systems with >= 4 GB of memory.

 

Ironically, my system has 4 GB of memory, but I have yet to be able to provoke data corruption with my testing so far.

 

In the BIOS of my Epox 9NPA+ Ultra mainboard there are also 2 options, which were added in a rather late BIOS update:

* hardware memory hole remapping

* software memory hole remapping

 

On my system, they were both set to enabled during the testing mentioned above. Which yet again adds to the strangeness of not seeing any data corruption when reading large amounts of data from the unRAID system (the fact that the data is accessed from a NTFS file system through the ntfs-3g driver shouldn't matter, since the data corruption issue is suspected to be a kernel issue, and should manifest itself anyhow, right ? )

 

Should I try and change the abovementioned BIOS settings and rerun my tests and see if that makes any change?

 

The next test then I guess would be to add 2 new drives to the system, and setup a proper unRAID array (1 data disk + 1 parity disk ) and rerun tests.

 

The data corruption does however seem to happen quite rarely for some.

Here for instance: http://www.nvnews.net/vbulletin/showthread.php?t=82909

 

a person reports that when transferring 30 GB of data 50 times and checking sha512sum after the complete transfer, there are only 1-3 files with differences with about 100 corrupted bytes.

 

So maybe I could just rerun my previous tests above, with more and larger files and repeat MANY times...

 

 

 

 

[RobJ]

I personally feel, and I believe others also, that the memory hole remapping is a 'red herring', that it is just one of a number of ways to affect memory or bus timings that can affect the frequency of the data corruption, in some cases making it undetectably low.  As far as I know, no one has found the slightest logical reason as to why a memory hole remap could make any difference.  I think the 'iommu=soft' solution is the first one with plausibility, and a completely effective record, in early testing at least.

 

I only had 1GB of memory, and never touched the memory hole settings, don't remember what they were.  In my writing to a parity-protected data disk, I would get about 1 bit wrong in about every 4 gigs, as far as I can remember (rather fuzzy now).  The high order part of the address of the corrupted byte would be random, the low order part would follow a pattern, and the bit change was always identical, something like always the 2nd bit of the 3rd byte of a 4 byte-aligned word would be turned on, never off and never any other bit.

 

Writing to an unRAID disk with parity on is different than other writes, because it causes a lot more I/O traffic on the bus.  For each block written to the data disk, 2 disks are read, calcs are done, then 2 disks are written.  That's 4 I/O's for each write.  I am sorry, but I cannot remember if my testing included writes to both parity-protected and unprotected disks.  I *think* that they were all with parity on.

[vsonerud]

Hello again!

 

Since my last post I have done quite some more testing:

 

* Transferred a 66 GB large file (a compressed Acronis True Image system image ) from my Windows XP machine to my Windows Vista machine

* Booted Windows XP machine with a basic unRAID 4.3 final

* Mounted NTFS drives on the unRAID machine using 3g-ntfs

* Shared drive through SAMBA using unMenu

* Executed binary file comparison on Vista machine with file on unRAID samba share.

* Repeated file comparison 20 times, in other words 20 * 66 GB = 1320 GB

* All file comparisons were successful

 

* Added 2 brand new 1 TB drives to the unRAID machine

* 1 drive (Samsung 1 TB) was added to the onboard nForce4 Ultra SATA controller

* 1 drive (Seagate 1 TB) was added to a SiL3132 PCI-Express x1 SATA controller card

* The Samsung drive was assigned the first slot in the unRAID array

* The Seagate drive was assigned as parity drive

* Intitial formatting executed ok

* Initial parity sync was started

* While parity syncing I started copying a 66 GB file from my Windows Vista machine to the /mnt/disk1 share on the unRAID machine.

* This file transfer seemed to transfer at approx. 16.5 MB/sec (with initial parity syncing in progress at the same time)

* This file transfer took place during the night, and when I woke up the file transfer and parity sync had finished without problems.

* I then started a binary file comparison on the 66 GB file between my Windows Vista machine and the same file on the /mnt/disk1 share

* The comparison was supposed to loop 10 times (while I was at work )

* I then initiated file copying of the same 66 GB file 2 more times (simultanously) to the unRAID /mnt/disk1 share (using another name for those 2 copying sessions of course )

* I noticed that the file transfer speed as reported by Vista then was approx 1.5 MB/sec for each of the 2 copy sessions.

* When returning from work approx 10 hours later, the 2 file transfers had not finished

* only the first binary file comparison had finished. The second was in progress.

* I cancelled one of the file transfers as well as the file comparisons.

* The one remaining file transfer then speeded up considerably for a while, then it suddenly slowed down to a crawl.

* I then took a look at the syslog and noticed a lot of the following lines:

* Tower kernel: eth0: too many iterations (6) in nv_nic_irq.

* The first occurence of these lines was right around the time where I initiated the simultaneous file transfers.

* This syslog is attached below and is called: syslog-2008-11-10.txt

 

 

* I then rebooted the unRAID machine.

* Added a user share to try file transferring through this instead.

* Did some more file transfers of various files with strange results:

 

* File transfers from my Windows Vista machine to my unRAID machine usually starts off quite fast and then decreases until the average speed is between 20-30 MB/sec

* Then after some time - sometimes a very short period of time - other times after maybe 20% transfer, the speed very suddenly drops dramatically to around 6 MB/sec and quite often it almost stops completely

* This happens in both Windows Vista explorer as well as in Windows Total Commander.

* Using Total Commander I have also experienced several times that the file copying never really starts and in the end throws an error telling me that the disk is full.

* Checking the syslog during these problematic transfers there is absolutely nothing new logged (and no signs of the 'eth0: too many iterations (6) in nv_nic_irq' error from previously)

* I tried transferring through the /mnt/disk1 share as well as through my user share without any siginificant difference

* Reading from the unRAID shares always happen with speeds around 65-70 MB/sec.

* I then finally initiated a parity sync which is in progress as I type this, with a sync speed starting at around 100 MB/sec

* I have attached another syslog starting from the reboot mentioned above and lasting through many problematic file transfers up until the parity sync was started.

* The name of this syslog is:  syslog-2008-11-10-#2.txt

 

 

UPDATE:

* The parity sync completed without errors with a rate=82839K/sec

* I power-"rebooted" my 3Com 8-port Gigabit-switch, and voila, suddenly file transfers (writing) seemed to have stabilized around 10 MB/sec, but then suddenly after 37% transfer of a 9 GB file, the transfer just suddenly stopped, and after a while Windows Total Commander told me that 'Disk is full'.

 

 

 

 

 

 

 

 

 

 

 

[RobJ]

I don't see anything particularly adverse in either of the syslogs.  The 'eth0: too many iterations (6) in nv_nic_irq' messages are certainly unusual, but appear to be harmless.  They appear to me to be the network driver complaining of overwork, and I wouldn't be surprised if an ifconfig at the console reported dropped packets, and perhaps in the router logs too.  That first test of the unRAID server was treating a poor desktop board as if it were a server board, with multiple simultaneous bidirectional I/O streams.  I did some searching, and found that identical error once in one of my recent syslogs, multiple times in a year old syslog of mine, and once in another user's syslog, all using the forcedeth network driver and nVidia onboard gigabit chipset.  I think it is just an indication of the network driver being briefly swamped.

 

You mentioned some file comparison tests, but did not mention any results involving the unRAID server, so I will assume there were no compare errors?

 

I noticed that your DHCP server is configured to require lease renewal once per hour.  This is NOT an issue, but it does contribute to clutter in the syslog.  A more common value is once per week, or perhaps once or twice per day.  However, I don't know how strict your security requirements are.

 

A minor issue, the Seagate terabyte drive is not at full speed, is linking at 1.5 Gbps, which usually means that it still has its SATA150 jumper installed.  See http://lime-technology.com/wiki/index.php?title=Improving_unRAID_Performance#Remove_SATA150_Jumper.

 

The stop and start nature of writing to a parity-protected drive is well-known, and you can find numerous threads questioning it.  It's partly because each write causes 2 reads and then 2 writes, 4 disk I/O's for each single network I/O, so disk I/O becomes a bottleneck.  Beyond that, the reasons get a lot more complex.

 

I use Total Commander extensively, and have never seen the issue you had, so I can't think of any reason for your experience.  I do know that traditionally a 'Disk full' error is the catch-all error for just about any disk write errors.  Originally, that was the reason for almost all write errors, and even with the advent of networking and network issues, it is easy for the lazy or careless programmer to consider any failure to write, a Disk full error, since that is still the most likely.  That can certainly affect your troubleshooting, make it harder to identify the true issue.  Once you know that though, it is easy to check and eliminate, but it is still not helpful.  In general, it is either a true DISK FULL issue, or a failure to receive a response of successful write, within a given time period.

[vsonerud]

>You mentioned some file comparison tests, but did not mention any results involving the unRAID server, so I will assume there were no compare errors?

 

No compare errors so far when comparing files transferred to the unRAID array. But I haven't gotten around to run the comparisons very many times just yet.

 

About the Seagate 1 TB drive and SATA-150/300 issue:

 

I was very well aware of this fact, but there is NO jumper set on the drive at the moment. A jumper was included with the hard-drive to insert if I wanted to force the drive to SATA 1.5 Gb/sec compatibility mode.

 

So, this is really a big mystery.

 

 

[RobJ]

I was very well aware of this fact, but there is NO jumper set on the drive at the moment. A jumper was included with the hard-drive to insert if I wanted to force the drive to SATA 1.5 Gb/sec compatibility mode.

 

So, this is really a big mystery.

 

You might try replacing the cable to it.

[vsonerud]

 

You might try replacing the cable to it.

 

Sure, I could try this and I will, although it's a brand new cable similar to the ones used on the other drives having no problems.

 

In addition, if one looks closely at the syslog I attached, 2 drives out of the total 7 drives are seen as SATA-150 only by unRAID.

 

These 2 drives are both Seagate drives. One of them is the brand new 1 TB Seagate assigned as parity drive, connected as the only drive to a Sil3132 PCI-Express x1 controller card.

(I also have another similiar Sil3132 controller card installed, where there are 2 Samsung 750 GB drives connected, which are recognized as SATA-300, so the controller card should be ok).

 

The other Seagate drive which is recognized as SATA-150 only by unRAID also does NOT have a jumper set (it is the Windows XP system boot drive). This drive is connected to the onboard nForce4 Ultra SATA controller.

 

 

And before anyone starts yelling PSU-issues, the PSU in my system is a Corsair HX620, which should have no problems at all running 7 drives. ( I have also carefully chosen not to connect all of the 7 drives to the same 12 V rail - according to a specification from a Corsair person posting  in a webforum a picture showing how the 3 different 12V rails are physically spread across the connectors on this PSU ).

 

I have also been doing some more file transfers and so far I have seen the following:

 

* When transferring ( writing) to the unRAID array through the /mnt/disk1 share at least the transfer finishes (using Vista explorer or Total Commander) even though it can slow down quite a bit from time to time

* When transferring really large files (I have been using a 66 GB file for most of the file transfers ) through the user share I have set-up, I have yet to be able to complete a 66 GB file transfer. Total Commander errs out saying 'Disk full', but I guess that is just bad exception handling. The windows Vista Explorer throws an error saying that there was a network problem writing to the share. The windows event log shows a 'delayed write failure'.

* In windows Vista I was able to retry the transfer when failing and continue where the transfer left off. Right before the transfer failed the network transfer speed had dropped to a few kbit/sec and stayed like that for a while before finally throwing an error. When retrying the transfer picked up a decent speed again, before failing some time later.

* I also observed during the transfer (using the Vista performance monitor ) that the transfer several times dropped to a very low speed (a few KB/sec) but then managed to increase speed again after some time without failing. This could happen several times  until it finally did not manage to pick up speed again and failed.

 

* I also tried transferring a large file (26 GB) from another Windows XP machine in my local network to the unRAID user-share using Windows Total Commander, but that also failed similarly as on the Windows Vista machine. So at least, the problem does not seem to be Windows Vista related.

 

 

[RobJ]

The other Seagate drive which is recognized as SATA-150 only by unRAID also does NOT have a jumper set (it is the Windows XP system boot drive). This drive is connected to the onboard nForce4 Ultra SATA controller.

 

That other Seagate is a ST3250623NS, which is a true SATA-150 drive, so the link speed of 1.5 is correct for it, but not for the ST31000340AS on the SiI3132 card.

 

One other way of varying your testing (you are quite thorough!), is to use the Total Commander speed throttling.  Because the machine I still use for most of my work is an ancient Dell 866MHz (can't afford better currently), and the spiky transfer behavior badly affects my use of the machine, I generally use the queued copying feature and turn on the throttling, often down to 8000KB/sec, for an even transfer that my unRAID has no trouble keeping up with, and does not affect my foreground use.  Your machines seem faster, so you should not have to slow it down that much, but that gives you a tool that *may* help in determining what is causing the write timeouts, and what speeds you can support without issue.

 

The fact that rebooting your switch affected the transfer speeds is very interesting, although hard to understand.  You might check an ifconfig at the unRAID console, repeatedly, to monitor it.

[Joe L.]

The fact that rebooting your switch affected the transfer speeds is very interesting, although hard to understand.  You might check an ifconfig at the unRAID console, repeatedly, to monitor it.

I am also impressed with the testing.

Since you are running Vista in some of your tests, do you have it "patched" to SP1?  (networking on it was really bad originally)

 

Are you using "home made" cables? or CAT5 instead of CAT5e or CAT6?  They could cause errors on the LAN.

Lastly, the reboot of the router/switch, and its subsequent improvement seems to indicate it might be affecting more than just performance.  I'd swap it out with a different switch, or even with a direct cable (for tests)

 

I find it fascinating to follow along with your tests...  The use of unraid/unmenu/ntfs-3g on your existing windows machine, booting solely on the USB flash drive to do your transfer tests is super. At least it completely eliminates Vista from being a source of network nightmares while you test.

 

Joe L.

[vsonerud]

Hello again Robj and thank you for your suggestions.

 

Regarding reset of my switch I am not so sure anymore about any significant increase in speed.

 

I have done more testing. First of all I did not load the ntfs-3g module which was previously manually loaded when executing the previous file transfers.

(because ntfs-3g as well as the unRAID filesystem driver uses FUSE I was thinking that to be 100% sure to avoid any side effect from ntfs-3g that it would be safest to not load it )

 

But it had no effect neither speedwise nor stability-wise on the transfers through the user-share. Large file transfers through the user-share do not succeed.

 

Since this still is a test-system, I decided to try the "bleeding edge" 4.4 beta2.

 

Booting the 4.4 beta2 takes a bit longer because of some new strange SATA-related errors. They show up in the syslog like this:

 

Nov 11 12:02:06 Tower kernel: ata4: link is slow to respond, please be patient (ready=0)

Nov 11 12:02:06 Tower kernel: ata4: COMRESET failed (errno=-16)

Nov 11 12:02:06 Tower kernel: ata4: link is slow to respond, please be patient (ready=0)

Nov 11 12:02:06 Tower kernel: ata4: COMRESET failed (errno=-16)

Nov 11 12:02:06 Tower kernel: ata4: link is slow to respond, please be patient (ready=0)

Nov 11 12:02:06 Tower kernel: ata4: COMRESET failed (errno=-16)

Nov 11 12:02:06 Tower kernel: ata4: limiting SATA link speed to 1.5 Gbps

Nov 11 12:02:06 Tower kernel: ata4: COMRESET failed (errno=-16)

Nov 11 12:02:06 Tower kernel: ata4: reset failed, giving up

 

And these error messages keep apperaring endlessly every minute or so even after the unRAID system is completely booted, and one of the drives are missing

(that is, the drive missing is one of my NTFS drives - a 500 GB Western Digital RE2 with TLER disabled )

 

BUT: Now I am able to successfully transfer a 66 GB file from my Windows Vista machine to the user-share on the unRAID machine for the very first time.

Previously this has only been working directly through the /mnt/disk1 share. The average trransfer speed was ~9 MB/sec

 

I also monitored closely the network throughput, and even though the speed varied _a lot_ there were considerably fewer periods with VERY low transfer speed.

The transfer speed was though often very "bursty" - with high short peaks - sometimes in the 100-300 Mbit/sec range.

 

After the file transfer was successfully finished I tried copying the file back from unRAID user-share, and much to my dismay and surprise the transfer (read) speed was only approx 6.5 MB/sec. After some time I cancelled the transfer and retried a file transfer directly from the /mnt/disk1 share, but with no significant speed increase. And because I now was using unRAID 4.4 beta2 I did not bother to do the "read speed performance tweak", because it is sort of already done in unRAID 4.4

 

I then downgraded my unRAID system back to unRAID 4.3 final and booted up again, and retried file reading from the unRAID disk/user-shares, but still with approx. only 6-7 MB/sec transfer speed. I could swear I have seen MUCH higher read transfer speeds from the /mnt/disk1 share previously. But that may have been with files only some hundred Megabytes large - maybe upto 700 MB in size, so I guess maybe there could be caching/buffering mechanisms in place explaining the previous MUCH higher transfer speeds...?

 

Executing: ethtool eth0  

correctly shows for instance:        

Speed: 1000Mb/s

Duplex: Full

 

I then powered down the unRAID system and booted Windows XP on the machine, and then transferred files from the XP machine to the Vista machine (where I have been doing most of my testing) with transfer speeds around 60 MB/sec.

(my 3com OfficeConnect 8 port gigabit switch is supposed to be good - and I am using almost brand new Cat6 cables.)

 

 

Attached is my syslog shortly after having booted the unRAID system using the 4.4beta2 release.

 

My Windows Vista system has SP1 installed (along with all other Vista updates from Microsoft ). And besides, as I mentioned previously I also conducted a test using another Windows XP machine with the exact same transfer (write) problems.

 

 

 

[RobJ]

And these error messages keep apperaring endlessly every minute or so even after the unRAID system is completely booted, and one of the drives are missing

(that is, the drive missing is one of my NTFS drives - a 500 GB Western Digital RE2 with TLER disabled )

 

It seems to know there is a drive there, that's trying to respond, but is not successful in obtaining full communications.  I would check for a loose connector, perhaps it has slid slightly off.  And try again after a cold boot, total power disconnect, not even standby power (makes a difference sometimes).

 

It is possible that the COMRESET's and hard reset timeouts are synchronous, not allowing the other drive activity while waiting.  That would of course drastically reduce your transfer speeds, ruining your testing.  For testing, you might disconnect that drive if there is no loose connector problem.

 

Is the ifconfig report clean for eth0 ?  No dropped packets or other packet errors?

[Joe L.]

If you google "kernel: ata4: link is slow to respond, please be patient (ready=0)" you will see lots of threads regarding this.  It might be an artifact of a new driver in the new kernel...

 

Hopefully it will be fixed in the next release.  While it might be related to a bad cable, or bad connection, it might not.

 

Joe L.

[Joe L.]

Best discussion I found of the problem is here: http://kerneltrap.org/mailarchive/linux-kernel/2008/5/9/1776964/thread

 

Joe L.

[RobJ]

Interesting...  and disturbing...

 

That set of threads ends in early May, with basically a reversion(!), not a solution.  Perhaps there has been progress elsewhere, but it has been pretty quiet in kernel land lately.

[vsonerud]

Update:

 

After rebooting my unRAid system into unRAID 4.3Final I initially get approx. 20-25 MB/sec in read-transfer speed from the user-share. When I do the 'performance tweak' the read transfer speed increases to approx 60 MB/sec (average for a 7 GB transferred file for instance )

 

I then tried something new:

 

I made a shelll script on the unRAID machine which performs the following:

 

* record the time-stamp before starting

* copy a ~6.55 GB file from a NTFS-drive mounted using ntfs-3g  to my /mnt/user/Media   user-share

* record the time-stamp when finished

This bypasses any networking problems/issues between the unRAID machine and my Vista machine, because all data transfers happen on the unRAID machine.

 

The average write speed of the transfer was 5.6 MB/sec

Then I read this file back from the user-share using my Windows Vista machine, and the read transfer speed was approx. 60 MB/sec

 

And to answer a previous question:

After having experienced file write transfer problems from my Windows Vista machine to the user-share on the unRAID machine, ifconfig  always reports 0 packets dropped and 0 error packets.

 

 

[vsonerud]

Still performing tests, the file transfer problems are starting to really make me frustrated.

 

Using unRAID 4.3Final I still have serious problems with LARGE file transfers from Windows Vista/Windows XP machines to unRAID user-shares. They always terminate prematurely.

This holds true both through Windows explorer as well as using Total Commander. I also tested 'Robocopy' (Robust Copy) which is now part of Vista SP1 using the recovery mode, which retries when experiencing network problems. Transferring a 66 GB file never succeeded even with recovery mode.

 

Reading files from the unRAID user-share using Windows explorer on Windows Vista/XP works fine, with an average transfer speed of 20-25 MB/sec with default settings, and with approx 40 MB/sec with the "performance tweak"  (blockdev --setra 2048 /dev/md1 ).

 

BUT, the most interesting finding is a new test I perfomed:

 

On the unRAID machine, I mounted a Windows share from my Vista machine using 'smbmount'.

 

I then transferred the same 66 GB file as before, from the Vista machine to the unRAID user-share using a simple 'cp' on the unRAID machine.

Result: No problems, and with an average transfer speed at about 10-14 MB/sec.

Monitoring the bandwidth troughput on the Vista machine, the network transfer was now really smooth, only varying between 100-120 Mbit/sec. No bursts or spikes anymore.

 

The only really positive result so far is that I do not seem to suffer from data corruption issues with my nForce4 ultra motherboard. Earlier today I  executed a binary file comparison 15 times on a 66 GB file between the Vista machine where it originated from with the copy on the unRAID user-share where it was copied to. No differences at all.

 

After doing a lot of data transfers, both successfully, and with problems as described above I have checked 'ifconfig' on the unRAID machine: 0 erroneous or failed packets

 

I am going to test again with unRAID 4.4beta2, where I previously was successful with copying LARGE files from Vista/XP machines to unRAID shares, to see if that is a consistent result when repeated many times. But then again unRAID 4.4beta2 is not an option to use right now for my system when going "live", because of the new problems mentioned earlier in this thread. I just wished the next beta could be released soon to see if that problem has been fixed in newer Linux kernels.