Slow Transfers / Parity Checks? I have a theory

[DoeBoye]

Are you seeing any performance change during parity checks or transfers? I'm guessing, based on what we've seen so far, that with your cpu running at 1600 or 2500mhz, there's no difference, as you're minimum frequency is already enough to easily keep up...

Sorry, the parity check was just done (64 Mbyte/sec average)

I switched between the 2 speeds while transfering to my cache drive. But that did not seem to make a difference.

However, i have a hitachi 1 TB 7200 RPM disk, and i suspect the 72 Mbyte/sec speed i see while copying is about the maximum it can do. (this is stable speed with Blu ray files of 10-20 GB)

 

I have a 2 port adapted raid card coming to me, i will try that with 2 of these 1 TB drives in raid-0 to see if i get more speed.

 

72 MB/s is certainly nothing to sneeze at . Please report back with results using the other controller, but as your cpu only throttles down to 1600mhz, I doubt we'll see a difference in performance. It's already more then powerful enough to handle the transfer!

[Influencer]

My initial parity check speed was ~50MB/s. I switched to telnet and set the scaling to performance, double checked in unmenu that it was pegged at 2800MHz constantly, and then checked my parity speed, for the past few minutes it has sat consistently at ~99MB/s, and as I just checked tipped over to 101 MB/s, which is the fastest I've seen on this build.

 

Forgot to post back with the results. Let the parity check finish running overnight and my average speed was 75MBps so even set to performance I got the same average. Still not complaining.

[pras1011]

I upgraded from a AMD 245 x2 core to a AMD 635 x4 core and the parity check speed went from 75MB/s to 40MB/s. And also write speed has dropped! It was set to on demand.

 

I then used sudo sh -c "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" and then started a parity check. It started at 31MB/s!

 

I then did sudo sh -c "echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor"  and now its back to 42MB/s

New_Text_Document_2.txt

[DoeBoye]

I upgraded from a AMD 245 x2 core to a AMD 635 x4 core and the parity check speed went from 75MB/s to 40MB/s. And also write speed has dropped! It was set to on demand.

 

I then used sudo sh -c "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" and then started a parity check. It started at 31MB/s!

 

I then did sudo sh -c "echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor"  and now its back to 42MB/s

 

Did you try setting the other 2 cores (cpu1 and cpu2) to performance as well?

[pras1011]

Do i have to use all four codes?

[DoeBoye]

Do i have to use all four codes?

 

yup . each line instructs each cpu to run using the performance governor. Currently, you are running the first and last on performance, and the other 2 using ondemand

 

ie:

sudo sh -c "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor"
sudo sh -c "echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor" 
sudo sh -c "echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor" 
sudo sh -c "echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor" 

 

NOTE: You can copy all 4 lines and paste them in simultaneously. You don't need to do them one at a time

[pras1011]

Ok i set the cpu1 and cpu2 to performance and parity speed is still 42MB/s.

[DoeBoye]

Ok i set the cpu1 and cpu2 to performance and parity speed is still 42MB/s.

 

Has anything else changed? I doubt the processor change is the difference. Here's my reasoning:

 

1. The 245 X2 runs at 2.9GHZ and the 635 X4 runs at the same. Cache, bus speed and chip-generation are all the same so from what I can tell from a 30 second Google, you basically have just doubled the available cores in your server.

 

2. UnRaid is pretty undemanding, and it looks like anything over 800mhz, speed-wise, and transfers/parity don't appear to be affected (I don't know what the exact minimum speed is, as the next jump for my proc is 1400mhz).

 

In your situation, I'm guessing the new chip throttles down to 800mhz, but as soon as you switched the governor to performance for 2 of the cores, your chip was already more then powerful enough to max out speeds, so setting the other 2 cores didn't help.

[pras1011]

Nothing else has changed apart from the cpu. I am going to revert to RC5 and see what happens.

[pras1011]

I have tried RC5 and Test2 and they both had the slow parity speed. They both ran at 42MB/s. I did not change the governor. I will have to swap back to the 245 cpu.

[DoeBoye]

I have tried RC5 and Test2 and they both had the slow parity speed. They both ran at 42MB/s. I did not change the governor. I will have to swap back to the 245 cpu.

 

Weird! Please post back when you do the switch. I'm very curious to see if it was just a fluke, or does the old 2 core really somehow perform better then the new 4 core.

 

If transfer speed does go up, I'm stumped. Logically, at full speed, there should be no change...

[pras1011]

Is this a problem with AMD or are Intels affected?

[DoeBoye]

Is this a problem with AMD or are Intels affected?

AMD or Intel wouldn't make a difference. I'm pretty sure something else is going on that is not processor-related (Drives are more full then when last tested etc etc)...

 

 

 

[pras1011]

I went from the 245 to the 635 less than an hour ago and I changed nothing else. Unless the cpu is damaged but I doubt it.

 

I have attached my 245 suslog.

245.txt

[pras1011]

This is my 635 syslog

635.txt

[DoeBoye]

I went from the 245 to the 635 less than an hour ago and I changed nothing else. Unless the cpu is damaged but I doubt it.

 

Perhaps someone with some expertise in syslogs can jump in? I'm not very adept at deciphering them .

 

Another thing to consider is that parity check speeds seem to fluctuate quite a bit. Have you run the parity check to completion using both cpus? Are the numbers you provided the final average  result of the check (as logged in the log file)?

 

Damaged: I doubt it as well.

 

I should say that everything I've seen in my own system, as well as what others have posted is that any speeds over 800mhz, and cpu no longer becomes a factor.

[pras1011]

Unfortunately I have too much data therefore it would take a day or more to complete a parity check. It's very odd that all software tested runs at 42MB/s max.

[JonathanM]

Unfortunately I have too much data therefore it would take a day or more to complete a parity check.

Parity check has nothing to do with how much data you do or do not have. The number of drives, controllers they are on, size of the drives (not occupied space) all effect parity check times. Completely blank drives would take just as long to check.

[bcbgboy13]

Re: 245 and 635 - different motherboard BIOSes - different settings, and the 4-core CPU stalls... Check your settings.

[pras1011]

I updated the bios to see if that would increase the speed but it didn't. The ONLY settings I changed were the governor which gave the stall error.

[dgaschk]

Unfortunately I have too much data therefore it would take a day or more to complete a parity check.

Parity check has nothing to do with how much data you do or do not have. The number of drives, controllers they are on, size of the drives (not occupied space) all effect parity check times. Completely blank drives would take just as long to check.

 

This is true.

 

Parity check speed reports are meaningless unless they are run until completion. Many have reported wide differences during the start of a parity check only to find that actual completion time has not changed.

[pras1011]

I left the parity check over night and it got through about 32% and the speed was still at 42MB/s and therefore I cancelled it. Write speed is erratic and worse with the 635 cpu.

[RobJ]

I left the parity check over night and it got through about 32% and the speed was still at 42MB/s and therefore I cancelled it. Write speed is erratic and worse with the 635 cpu.

 

Your 245 syslog was very short, showed only one very brief parity check (less than 2 minutes), with no CPU stalls.  Your 635 syslog showed several parity checks, and 2 CPU stalls on the fourth CPU.  There were no other important changes (other than 2 more CPU's).

 

It could be useful to see the 635 syslog after you ran it all night and still slow, to see if there were constant CPU stalls. They could certainly have impacted performance.  It may also be useful to see another 245 syslog, with the new BIOS, and run all night, to see if there are any CPU stalls.

[pras1011]

I think the CPU stalls were due to me changing the governor on CPU 0 and 3 only. I will run parity check with the 635 and on completion I will upload the 635 syslog. I will do the same for the 245.

[pras1011]

Oh boy! Parity stop mid way because disk9 redballed. I am now rebuilding disk9 with the AMD 245 and RC5 and the rebuild speed is currently at 120MB/s!!! Very strange.