NASLite Network Attached Storage

www.serverelements.com
Task-specific simplicity with low hardware requirements.
It is currently Tue May 20, 2025 7:06 pm

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Wed Nov 18, 2009 1:20 am 
Offline

Joined: Sun Mar 04, 2007 10:40 pm
Posts: 37
I've got 7 drives in my NASLite box - 4 IDE and 3 SATA. The read/write speeds on my IDE drives are absolutely horrible compared to the SATA. Now I know SATA should be faster, but presumably not as much faster as what I'm getting.

Doing copy/paste tests on roughly 5 GB files to/from a Windows machine via gigE, my transfer speeds on the IDE drives sit right around 1.5 - 2 MB/sec, at least according to the windows copy dialog. I know that's probably not the best way to test it, but as a rough measure, I assume it'll do. After a full 10 minutes of copying a 5 GB file to one of the IDE drives, about 1.2 GB has completed. Copying the same file from the same computer across the same network to the same NASLite box, but to one of the SATA drives, the entire file completes in under 3 minutes.

Compared to the 1-2 MB/sec speeds transferring to/from the IDE drives, I'm getting anywhere from 30-60 MB/sec transferring to/from the SATA drives.

I'm also getting behavior that I assume is the "RAM buffer" behavior, but only on the IDE drives, where it'll transfer about 200 MB in a hurry, then slow to a crawl for a few minutes, then transfer another couple hundred MB.

So my questions are:

1. Why would my IDE speeds be so slow compared to the SATA speeds? I can't imaging that IDE read/write speeds are actually 30x slower than SATA speeds.

2. Why is the buffering only an issue on the IDE drives, and not the SATA drives?

3. Also with the buffering, why don't I ever see buffering when transferring to/from IDE drives on Windows or Apple machines? What is it about transferring to/from NASLite that requires it to go through the buffer flushing speed up/slow down process when transferring via other OSes always seems to happen at a nice, smooth pace?

Thanks for any help!


Top
 Profile  
 
PostPosted: Wed Nov 18, 2009 9:29 am 
Offline

Joined: Sun Apr 02, 2006 9:05 pm
Posts: 1688
Location: Up State NY in the USA!!!!
Post a detailed list of the hardware right down to the makers of the hardware.

Post the log file from your NAS box, it will tell allot about the issues you are having.

Mike


Top
 Profile  
 
PostPosted: Wed Nov 18, 2009 9:50 am 
Offline

Joined: Sun Mar 04, 2007 10:40 pm
Posts: 37
I'll be able to check on all the hardware when I get back later this afternoon. For now, I can post the syslog details from the web admin page, but all it consists of is the following lines, over and over again, hundreds if not thousands of times...

Quote:
System Message Log:

* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt!
* Nov 17 19:26:02 user.warn kernel: eth0: Too much work at interrupt


Top
 Profile  
 
PostPosted: Thu Nov 19, 2009 9:26 am 
Offline

Joined: Sun Apr 02, 2006 9:05 pm
Posts: 1688
Location: Up State NY in the USA!!!!
Your issue looks to be related to an IRQ conflict between the ATA controller and the NIC. There are a number of fixes for this, some as easy as simply moving the NIC to a different PCI slot or forcing the ATA controller on the mother board to use a different IRQ. Then again your only fix may be to go to a different motherboard all together.

More info!

Mike


Top
 Profile  
 
PostPosted: Thu Nov 19, 2009 11:52 am 
Offline

Joined: Sun Mar 04, 2007 10:40 pm
Posts: 37
Okay, here's what I got on the hardware side. In the meantime, hopefully I'll have a chance later today to play with some of the possibilities you mentioned.

MB: MSI K8NGM2-FID

CPU: AMD Athlon 3500+

NIC: TRENDnet TEG-PCITXR
- I can't really remember why I'm using this, since the mobo has gigE, but I feel like I may have had problems with it when I initially did the NL build with this hardware a year or so ago.
- There are two pci slots on the board, so I can also try moving the nic to the other one, if the onboard gigE doesn't help

RAM: 1gb (2x512) Patriot

NL: v2.4.36

DRIVES: Using both IDE slots (with 4 total drives, the max available onboard) and 3 of the 4 onboard SATA ports

One other thing I noticed that may not mean anything, in my System Settings page, it shows 99% of system memory (RAM) in use, even when there's nothing active happening to/from the machine (other than checking the System Settings page itself.) Again, this may not mean a thing, but I noticed it so I thought I'd mention it.

Thanks!


Top
 Profile  
 
PostPosted: Thu Nov 19, 2009 4:37 pm 
Offline

Joined: Sun Apr 02, 2006 9:05 pm
Posts: 1688
Location: Up State NY in the USA!!!!
Get the latest version of the OS, it is based on the 2.6.xx kernel and supports a much larger array of hardware for starters. The performance is also a fair bit better as well. It is more than worth the little cost of upgrade.

Second, after loading the new OS try the old NIC on board, my guess is that it will work much better under the new kernel.

From what I have heard you are having IRQ issues for sure and getting rid of the extra NIC may help here.

The memory is not an issue, NL allocates any extra RAM to caching writes to speed up transfers of files. This is normal and proper.

Mike


Top
 Profile  
 
PostPosted: Fri Nov 20, 2009 9:58 am 
Offline

Joined: Sun Mar 04, 2007 10:40 pm
Posts: 37
I'm going to be playing with this today, and if I can't get it working through a few IRQ changes, or the onboard NIC, I'll do the upgrade also. In the meantime, I did a restart of the box to try to get a cleaner syslog, in case it shows anything more specific...


Attachments:
log.rtf.zip [6.2 KiB]
Downloaded 957 times
Top
 Profile  
 
PostPosted: Fri Nov 20, 2009 9:01 pm 
Offline

Joined: Sun Mar 04, 2007 10:40 pm
Posts: 37
Okay, I've updated the software to the latest version, reseated all the cables and jumpers, and retested everything. Partial success:

Two of the 4 IDE drives (disk-0 and disk-3) now transfer at very acceptable speeds: 30-40MB/s.
The other two (disk-1 and disk-2) still poke along at 1-2MB/s.

All four drives are connected to the two ATA channels directly on the motherboard. The two slow drives are each on separate cables - one of them is the master on one channel, the other is the slave on the other channel, so no consistency there.

Attached is my latest syslog. There are obviously some drive errors popping up toward the bottom on two of the drives. I'm not sure what the errors are saying really. The curious thing though, is that the two drives reporting the errors (hda and hdd) are the two that are transferring faster, if I'm reading the logs properly. I'm assuming hda is disk-0 and hdd is disk-3. I'm not 100% sure if that's the way it works, but at least for disk-3 I'm pretty confident because it's a smaller size than the other 3, and hdd is showing the smaller size.

So I've got two drives giving errors, and two drives getting good speed now, but the two drives giving errors appear to be the ones with the good speed.

Oh, and I've removed the NIC card completely and am using the onboard NIC.

Can you see anything from the log that might help figure out why the other two drives are still going so slow?

Thanks!

EDIT: One other thing I noticed looking through the log. If I'm reading the naming right and the two slow drives are hdb and hdc, I'm noticing that both of those drives show the message "DMA disabled", whereas all the errors on the other two drive mention DMA in them, but nowhere do they say anything about DMA being disabled. Could this have anything to do with it you think?


Attachments:
syslog.zip [10.21 KiB]
Downloaded 956 times
Top
 Profile  
 
PostPosted: Sat Nov 21, 2009 9:55 am 
Offline
Site Admin

Joined: Tue Jul 13, 2004 4:11 pm
Posts: 1771
Location: Server Elements
popechild wrote:
EDIT: One other thing I noticed looking through the log. If I'm reading the naming right and the two slow drives are hdb and hdc, I'm noticing that both of those drives show the message "DMA disabled", whereas all the errors on the other two drive mention DMA in them, but nowhere do they say anything about DMA being disabled. Could this have anything to do with it you think?


That's exactly what is causing the problem. What I'd do is reset the BIOS to it's defaults, then make sure the drives are jumpered properly. You may want to try CS instead of MS/SL. Lastly, make sure you have the proper cables 40 vs 80. Although 40 should work, for what you are doing, 80 is better suited. Also, make sure you use the shortest cables you have. UDMA and long cables are a bad mix.

Anyway, some things to try. The problem is definitely hardware related - most likely configuration.

Ah, and make sure PnP OS and ACPI are enabled in the BIOS after you reset to defaults. Do a cold reboot after that.

Hope that helps.


Top
 Profile  
 
PostPosted: Sat Nov 21, 2009 12:15 pm 
Offline

Joined: Sun Mar 04, 2007 10:40 pm
Posts: 37
Tony wrote:
popechild wrote:
EDIT: One other thing I noticed looking through the log. If I'm reading the naming right and the two slow drives are hdb and hdc, I'm noticing that both of those drives show the message "DMA disabled", whereas all the errors on the other two drive mention DMA in them, but nowhere do they say anything about DMA being disabled. Could this have anything to do with it you think?


That's exactly what is causing the problem. What I'd do is reset the BIOS to it's defaults, then make sure the drives are jumpered properly. You may want to try CS instead of MS/SL. Lastly, make sure you have the proper cables 40 vs 80. Although 40 should work, for what you are doing, 80 is better suited. Also, make sure you use the shortest cables you have. UDMA and long cables are a bad mix.

Anyway, some things to try. The problem is definitely hardware related - most likely configuration.

Ah, and make sure PnP OS and ACPI are enabled in the BIOS after you reset to defaults. Do a cold reboot after that.

Hope that helps.

Success! The 80 cables are actually what ended up doing it - Now all four of the IDE drives are purring along at anywhere between 40-80MB/s! Had no idea the cables could make that much difference, especially since 1 of the 2 drives on each cable was doing great on the 40 cable already, but I'm just happy it's all looking good now. And the cable swap also took care of the other DMA related errors I was getting on the other two drives, fwiw...

Thanks for all the help!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group