Testing the ZOTAC GF6100-E-E - (NOT recommended by the wiki)


Recommended Posts

Well, bcbgboy13 called it.  I was a bit too rash in my purchase of this motherboard (couldn't pass up the deal), and I didn't do my homework before making the purchase.  The ZOTAC GF6100-E-E uses the NVIDIA nForce 430 MCP for a northbridge.  As is clearly stated on the Hardware Compatibility page, any mobo based on the nForce 4 series is not recommended for unRAID.  nForce 4 or below is listed again in the motherboard SATA controllers section as being not recommended.

 

So I fully understand that I may be S.O.L.  If I can't get this mobo working with a minimum of effort, I'll return it.  However, I figure it is worth at least a few hours of tinkering before I do.

 

Part 1:

 

Upon the board's first boot it immediately booted into the unRAID flash drive, without needing any changes to the BIOS.  That was certainly surprising.  It also boots REALLY fast.  There's only about a second delay before the unRAID boot screen comes up!  The networking worked as well.  I typed in ifconfig at the console and got the ip address no problem.  So far so good.  Now I'll try hooking up a hard drive and see what happens...

 

Here's my main question:

 

The wiki states the problems with the nForce4 and below chipsets as being "data corruption issues, IDE detection issues, and incompatibilities with certain hard drives. This can result in failures to boot, corrupted files, corrupted network transfers, inability to use certain drives, etc."

 

So if I'm able to get a server up and running with this board, am I still looking at the possibility of data corruption etc. down the line?  Basically, could I build a server that appears to be working today but develops problems months down the line?

 

Part 2:

 

OK, I may have run into my first error.  I added a drive (1.5 TB Seagate 7200 rpm) to play around with.  I only have the one spare drive at the moment, so I added it as data disk1.  Formatting the drive worked as expected, but the system console reported an error:

 

REISERFS error (device md1): vs-5150 search_by_key: invalid format found in block 99747550. Fsck?

REISERFS error (device md1): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [1 2 0x0 sd]

 

These errors make it sound like there's something wrong with the drive, but it could be the mobo SATA controller as well.

 

I'll now try starting some transfers and see what happens.  Remember there's no parity drive installed at this point.  Obviously I'm not going to trust this board with any data for the time being.

 

syslog attached

syslog-ZOTAC_GF6100-E-E.txt

Link to comment

I would suggest returning it.

 

But not before you try doing some copies with Teracopy (if you do not mind).

Enable the verify functionality.

It would be good to see if Teracopy detects corruption or not.

Also try md5sum on your windows before, then over the network do an md5sum on the same file.

You can prove or disprove if these tools are able to detect a corruption with this chipset.

Link to comment

Transfer a full DVD or something larger then ram size.

As for windows md5sum tools, I do not have a recommendation there.

I suppose anything that you are comfortable with would work and md5sum should be the same no matter what.

Maybe someone else reading this thread can post a recommendation for Windows.

Link to comment

Transfer a full DVD or something larger then ram size.

As for windows md5sum tools, I do not have a recommendation there.

I suppose anything that you are comfortable with would work and md5sum should be the same no matter what.

Maybe someone else reading this thread can post a recommendation for Windows.

 

md5summer is good -- it will create and verify, drilling down through directories.

I used it to verify a backup of 300GB of files: http://www.md5summer.org/

Link to comment

I couldn't get either MD5 program to work on a directory, so instead I grabbed the biggest single movie file I have (8.74 GB) and copied it over.  CRC checks out OK via Terracopy, and MD5 checks out via Chaos MD5.

 

So far it would seem that these tests indicate that this motherboard works perfectly well with unRAID.  Or maybe I just proved that these tools aren't enough to detect the problems?  Again, should I expect to see problems right now, or down the road?

 

If this board will work as an unRAID server I would like to keep it.  If it won't, however, it is fairly useless in any other capacity (no DVI or HDMI so it won't work as an HTPC, for example).

Link to comment

In prior tests, this problem showed up right away.

 

There is a program called md5deep which can traverse down a directory.

http://md5deep.sourceforge.net/#download

It's a console program., but it may help.

 

When you do the test,

 

1. md5 a file

2  copy it to the unraid server.

3  md5 the same file from the nforce machine over the network

4. compare the two sums on the machine.

5. for extra checking do the md5 sum on the unraid machine

6. compare md5sums.

 

Maybe the updated linux kernel resolved issues with the nforce chipsets or something else was changed.

Link to comment

I couldn't get either MD5 program to work on a directory, so instead I grabbed the biggest single movie file I have (8.74 GB) and copied it over.  CRC checks out OK via Terracopy, and MD5 checks out via Chaos MD5.

 

So far it would seem that these tests indicate that this motherboard works perfectly well with unRAID.  Or maybe I just proved that these tools aren't enough to detect the problems?  Again, should I expect to see problems right now, or down the road?

 

If this board will work as an unRAID server I would like to keep it.  If it won't, however, it is fairly useless in any other capacity (no DVI or HDMI so it won't work as an HTPC, for example).

Perform the same test while in the middle of a parity check.  (Just to give the MB a bit more activity)  It could be that your MB is one that does not exhibit the random bit errors.

 

Your initial tests do sound encouraging.

Link to comment

1. md5 a file

2  copy it to the unraid server.

3  md5 the same file from the nforce machine over the network

4. compare the two sums on the machine.

 

These are the steps I already completed using Chaos MD5.  I haven't computed the MD5s with the actual unRAID machine, so I'll try that later if I have a chance.

 

Also, I forgot to mention earlier, I'm using a single 1 GB RAM stick in this server, so the movie file I moved was plenty big enough to fill up the RAM cache.

 

At the current time I don't have a parity drive installed in this test server, just the single disk1.  Unfortunately I don't have another spare drive to play around with at the moment.  I suppose I could take the drive out of my spare laptop, since it isn't doing anything important right now anyway.  Perhaps that's why I haven't detected any problems yet, since there's only 1 drive in the server (which is an unrealistic setup).  I'll report back later.

Link to comment

If you md5sum the same fiile on the test unRAID server and it's good, that should be enough.

 

From what I remember, it was the transfer of data to/from network and disk subsystem that causes issues.

it came up right away.

 

If I were trusting my data to this machine, I would move huge amounts of data just to be sure.

Initially these tests provide positive results.

Link to comment

I'm cautiously optimistic.  Here's the latest:

 

I scrounged up two more drives so that I could have a real parity protected array to play with.  I made the 7200 rpm 1.5 TB Seagate the parity drive, used a 7200 rpm 640 GB WD Blue data drive 1, and a 5400 rpm 320 GB Hitachi (laptop drive) data drive 2 (a bit under 1 TB of usable space).  I did a parity sync, then a parity check.  Both completed without errors in reasonable amounts of time.  I then created a user share to span both disks (using default settings) and started a transfer of 648 GBs worth of TV shows ('A' through 'E' of my collection).  This was a drag-n-drop TerraCopy transfer from my good unRAID server to this test server via a Windows 7 desktop.  Speeds were perfectly acceptable, somewhere in the 30-39 mb/s range.  I set TerraCopy to verify CRC after the transfer completed.  I then left for work.

 

When I returned the transfer was complete, or so I thought.  I expected to come home to a TerraCopy window telling me that all the CRCs were a match.  However, Terracopy was closed, so I don't know if the CRCs matched or not.  I checked the size of the transferred files and only 499 GBs of the 648 GBs were actually transferred.  Since I wasn't here to watch it, I have no idea what happened.  Both disks still reported plenty of free space, so I don't think it was that.  The server's syslog gives no clues either.

 

The main complication with this test setup is that I consider the 640 GB drive to be marginal.  I've been using it as a torrent drive in my desktop for quite some time, and it failed a bit over a month ago.  Windows just stopped reading it one day, and wouldn't boot as long as it was plugged in.  I wan't able to run SMART reports on it either.  I figured it was just gone and set it aside.  Then the other day I figured I would try it in my unRAID server (my good one, not this test one) just for fun.  It worked (or at least it was recognized).  I ran preclear on it and it passed, but I then restarted the server and forgot to save the SMART output.  So while it appears to be working now, I still don't trust it very much.  So at this point I'm still inclined to attribute the botched transfer to this drive rather than the motherboard.  However, unRAID didn't report a write failure or anything, so...je ne sais pas.

 

So now I'll try Joe L.'s suggestion of starting a transfer while a parity check is going.

 

Assuming I don't run into any grievous errors during my next few tests, I think what I'll do is start putting this to use as a light weight media server and maybe a 5.0 beta box.  I'll store some non-critical media on it and let my HTPC stream from it, uTorrent seed from it, etc.  Give my main server a break for a bit.  If it lasts through a few weeks of normal usage like that, then I think I'll trust it.

 

Edit: Looks like I had the 'close window when complete' option checked in Terracopy, so that explains that.  Still doesn't explain why 149 GBs weren't transferred, though.

 

Link to comment
  • 3 months later...

Raj

I picked up the GF6110-e-e this week, thinking it would be a good board to use in an effort to shrink down the size of my server.

 

Couple of questions, if you don't mind:

1.  What BIOS version is your GF6100-e-e?  You did not need to update the BIOS, correct?

2.  I can get unRAID to boot, but the flash drive is clearly not running at USB 2.0 speeds.  I have the BIOS selected to enable 2.0, but doesn't seem to be helping (takes over 1 minute to boot).  I can boot the same flash in my 740G machine and it boots in a fraction of the time. (unRAID 4.5.6)

3.  Copy speed from a Samsung EcoGreen drive is 29-31MB/sec - probably OK?

4.  I started a parity check, just with the 1TB EcoGreen and a 1TB 7200RPM drive and it was around 55MB/sec.  Seems a bit slow.

5.  I'm wondering if I don't have an older BIOS or I'm missing a setting somewhere that will get USB 2.0 operational.  And is there an AHCI setting somewhere?

 

I'm not at home currently, or else I'd grab a syslog. 

 

Any thoughts?

 

Thanks

AGW

Link to comment

1. I don't remember what version of BIOS I'm on, but I didn't update it.  I'll check the version number when I get home, if I remember.

2. I've also noticed that while the board itself boots very quickly, USB devices are fairly slow to boot.  So maybe that's just par for the course with this board, not sure.  Booting in just over a minute seems quick enough to me.

3. Yep, totally normal speeds.

4. Seems a bit slow, but the motherboard shouldn't affect it.  I'm guessing that your 1 TB EcoGreen is just a bit slow.  My parity checks are generally around 66 mb/s at the start, if memory serves.

5. I do believe there was an AHCI setting somewhere, but I don't remember where off-hand.  Again, I'll check and get back to you.

 

I'm fairly busy this week, so if I forget, just shoot me a PM.

Link to comment

I verified that I was running the current BIOS.  So, I took a look through the syslog that you posted and compared it to what I was getting and I could see that something was off with how mine was set up.  So, I reset the BIOS to the optimized defaults and the board seems to be much better behaved now.  Still a bit slow on the boot in my opinion - as if it's not booting at 2.0 speeds (not that important really). 

Parity check with just the two 1TB drives is now running over 100MB/sec at start - essentially double what I was getting previously. 

 

AGW

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.