More on CPU specs of the ReadyNAS Pro

dsm1212 wrote:
Are your four drives in dual redundancy? Mine are so it's really a three drive config. Maybe a drive cache size difference?

Single redundancy for me. The "-T" test reads from the portion of your main RAM that Linux uses as a disk buffer; it just tests how fast Linux's disk-cache algorithm running on your CPU can read data from your RAM. The drive isn't even accessed during the timed portion of the test, so nothing about the drive's performance -- including the size of the drive's onboard cache -- should affect the result of the "-T" cached-read test.

Mmh i tried it with a Q6600 (4Core) in After the BIOS Update the ReadyNAS 6 worked perfekt. So i went an took my ReadyNAS PRO with the Q6600 i get this (Even After the BIOS Update).


Sat Mar 2 18:58:21 CET 2013 System is up.
Sat Mar 2 18:14:26 CET 2013 System is up.
Sat Mar 2 18:01:01 CET 2013 VBAT power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:01:01 CET 2013 3VDUAL power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:01:01 CET 2013 VCC1_05 power is out of normal range [expected: 1.04 current: -0.00].
Sat Mar 2 18:01:00 CET 2013 VCC1_5 power is out of normal range [expected: 1.50 current: -0.00].
Sat Mar 2 18:01:00 CET 2013 VCC1_25 power is out of normal range [expected: 1.25 current: -0.00].
Sat Mar 2 18:01:00 CET 2013 VCC3 power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:01:00 CET 2013 AVCC power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:01:00 CET 2013 DDB18 power is out of normal range [expected: 1.80 current: -0.00].
Sat Mar 2 18:00:40 CET 2013 Gerät fährt herunter
Sat Mar 2 18:00:40 CET 2013 Bitte schließen Sie diese Browsersitzung und melden Sie sich nach dem Neustart mit RAIDar wieder an. Das System fährt jetzt herunter...
Sat Mar 2 18:00:33 CET 2013 Fan 1 has failed (SYS -1 rpm).
Sat Mar 2 18:00:33 CET 2013 VBAT power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 3VDUAL power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 VCC1_05 power is out of normal range [expected: 1.04 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 VCC1_5 power is out of normal range [expected: 1.50 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 VCC1_25 power is out of normal range [expected: 1.25 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 VCC3 power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 AVCC power is out of normal range [expected: 3.30 current: -0.00].
Sat Mar 2 18:00:33 CET 2013 DDB18 power is out of normal range [expected: 1.80 current: -0.00].

Now i put back in my E6600 and it Works with no error Messages but Lot slower (put still faster as the Org. CPU). Is there a change to get it to work with the Q6600? What are These error Messages mean? How i cut fix that?

Thx 4 your help

Weird. I though those were read off the board, they are power voltages. Maybe the chipset doesn't work well with that CPU, causing some issues.

If the system appears to work otherwise when you see those errors, I can provide a boot script work around, to have the system not log those errors.

On boot up, RAIDiator firmware looks at the system type, and builds a layout for monitor_enclosure (health check program, adjusts fans, sends alerts). Easiest way to deal with your logs is to modify that layout (saved in ramdisk) and restart moitor_enclosure. I haven't tested this out, but it should hopefully work, maybe needing a few tweaks:

# cat /etc/rc2.d/S02readynas_enclosure
 #!/bin/bash
 sed '/^vol/d' /ramfs/enclosure.cfg > /tmp/enc.$$$
 mv /tmp/enc.$$$ /ramfs/enclosure.cfg
 killall monitor_enclosure
 sleep 1
 /frontview/bin/monitor_enclosure

This removes the voltage lines from the layout, then restarts the service. So it won't know to read the voltages, causing logs/email alerts. If you look at /ramfs/enclosure.cfg, you can also see references for the temp/fan sensors.

I had to do a similar boot script for my retro-fitted Repertoire. I replaced the Sparc board with x86 (Ultra4 board). Since the Repertoire chassis has no fans, the system would complain that the fan has failed. The script I used there would tell the system there was no fans to monitor (over the default Ultra4 layout), so no more alerts would occur.

fastfwd wrote:

Single redundancy for me. The "-T" test reads from the portion of your main RAM that Linux uses as a disk buffer; it just tests how fast Linux's disk-cache algorithm running on your CPU can read data from your RAM. The drive isn't even accessed during the timed portion of the test, so nothing about the drive's performance -- including the size of the drive's onboard cache -- should affect the result of the "-T" cached-read test.

Well 4 drives should do a little better than 3 and one of my drives is a cool model (an odd 5900rpm I believe), but it seems hard to believe that is all of the difference. Could you post the output of hdparm -i /dev/sda? I'd like to see if there is anything special your drive can do. Maybe the fact that I have 3 different drive models triggers some poor md behavior due to cache size mismatches or something.

One thing odd I noticed is that when I run the test of /dev/c/c my USB drives all wake up. I've got 4 of them attached to a USB hub. Maybe I should try disconnecting them all?

steve

chirpa wrote:

There may be even newer BIOS now, but I don't work there anymore to know that. You can try running this add-on (install in FrontView, don't need USB boot anymore), which will update to the latest I had at the time: http://www.readynas.com/download/addons ... .5-x86.bin That v0.5 add-on provides these BIOS versions: Ultra2/ReadyNAS-ProUltra2 (1102/v1.8) Ultra4/ReadyNAS-NVX-V2 (0823/v1.1) Ultra6/FLAME6-2 (0610/v1.1) Pro(6)/FLAME6-MB (0726/v2.0)

Sorry if that is a old Question, but How i can see that the Firmware is Installed?

Thx

Check bios_ver.log in the System Logs download.

dsm1212 wrote:

fastfwd wrote: The "-T" test reads from the portion of your main RAM that Linux uses as a disk buffer; it just tests how fast Linux's disk-cache algorithm running on your CPU can read data from your RAM. The drive isn't even accessed during the timed portion of the test, so nothing about the drive's performance -- including the size of the drive's onboard cache -- should affect the result of the "-T" cached-read test. Well 4 drives should do a little better than 3 and one of my drives is a cool model (an odd 5900rpm I believe), but it seems hard to believe that is all of the difference.

Right, your drive performance is none of the difference in the -T cached-read test, since that test only measures the speed at which data travels between the NAS's RAM and the NAS's CPU.

Well, it seems like hdparm is not very accurate. I ran a more simple test and I get similar IO rates to the drive, but the reads from the linux cache are much higher than what hdparm reports. I'm still suspicious as what the heck hdparm does with my USB drives.

This is what I did:

# First create a 1GB file:
dd if=/dev/zero of=gigfile bs=1M count=1000

# Flush the file to disk
sync

# purge the cache
echo 3 | sudo tee /proc/sys/vm/drop_caches

# see the cache is mostly empty
free -m

# time the physical read case
time cat gigfile > /dev/null

# see that the big file is now in cache
free -m

# time the cache read
time cat gigfile > /dev/null

If I divide 1000 / by the elapsed time I get a physical read number similar to hdparm. For me about 300MB/sec. I think the difference there is probably the drives I'm using. But for the cached read I get over 4000MB/s so I don't understand why hdparm reports only 1900MB/s.

By the way fastfwd, what os rev are you running? I'm running 4.2.21.

thanks,
steve