Hey folks,

Did any of you notice a low transfer speed when using the Fill-up allocation method for a new unit?

 

I've been the proud owner and user of an Unraid setup for a while now. Recently, I got a new license, setup a second machine and started experimenting with it. Fun stuff! 
 

Anyways, back to my story. After configuring this system with two disks and a parity drive to backup my footage, I started transferring and I get like 1TB/day (around 20MB/s) and I don't see where the bottleneck might be. It's using only about 150Mbps out of a gigabit  connection, about 40% CPU and 16% of RAM. I'm using 8TB Ironwolf drives, however, they are limited to SATA 2 (3Gbps) by the old Xeon CPU. The initial parity check reported an average speed of 176 MB/s.

Edited July 4, 20233 yr by Bo_

7 hours ago, Bo_ said:

Did any of you notice a low transfer speed when using the Fill-up allocation method for a new unit?

That is the worst allocation setting in terms of performance, because parity writes will overlap.

7 hours ago, JorgeB said:

That is the worst allocation setting in terms of performance, because parity writes will overlap.

Yeah, it makes sense that it would be a tad bit slower, but 20 MB/s ? Uh... that's... unusable. 
I guess I'll have to give this arrangement up. I was hoping I was missing some secret "make it fast" checkmark or something along those lines 

Funny thing, though! I switched to highwater with little noticeable difference, so a better question would be "why so slow?"

Edited July 4, 20233 yr by Bo_

19 minutes ago, Bo_ said:

I switched to highwater with little noticeable difference, so a better question would be "why so slow?"

Did you enable turbo write?

Allocation method won't change a thing to speed when only one transfer is going. Excluding data being at the end of a disk when it could be at the beginning of another of course.

56 minutes ago, JorgeB said:

Did you enable turbo write?

Wow! Thanks! So it was a quick checkmark I was missing, indeed.
Here's  "the spike" I got when I switched from auto to reconstruct write (I'm assuming that's what you mean by Turbo Write).
Thanks a million!

15 minutes ago, Kilrah said:

Allocation method won't change a thing to speed when only one transfer is going. Excluding data being at the end of a disk when it could be at the beginning of another of course.

Yeah, I noticed. It would have been weird to be such a significant change, however, writing on two disks at a time rather than one by one could have made a difference. It was the only thing that was "unusual", however, the issue was the fact that I forgot to set the write method to reconstruct. Apparently, in this scenario, Auto just means "Obsoleted".

7 minutes ago, Bo_ said:

Apparently, in this scenario, Auto just means "Obsoleted".

There's actually a note in the help text that Auto is the same as read-modify-write, an auto-switching was never really implemented.

 

8 minutes ago, Bo_ said:

writing on two disks at a time rather than one by one could have made a difference.

A single transfer always sends one file after the other, so while the disk a given file gets written to would change it'd still be one at a time. And if you did 2 transfers you'd be limited by the parity drive having to seek back and forth between 2 places, so it'd actually be worse than a single transfer.

28 minutes ago, Kilrah said:

There's actually a note in the help text that Auto is the same as read-modify-write, an auto-switching was never really implemented.

 

A single transfer always sends one file after the other, so while the disk a given file gets written to would change it'd still be one at a time. And if you did 2 transfers you'd be limited by the parity drive having to seek back and forth between 2 places, so it'd actually be worse than a single transfer.

Indeed, there is this note and calling it Obsoleted is not fair either, since there are valid reasons for choosing one way or the other. I was just trying to emphasize my oversight. 
Yeah, the odd thing in my case was that I wasn't hitting any read, write, transmission or calculations hardware limitation, still I was stuck at a low but constant speed.
I'm initiating the file transfers from a Windows machine sending files one at a time using Total Commander queuing options. Now, I'm getting around 500 something Mbps while filling up the first drive in the array. It's still half way there from the other machine that manages to saturate my 1GB LAN, but it's significantly faster than the previous 150 Mbps I was enduring.

Funny enough, though, enabling Turbo mode on my other NAS produced no noticeable change, as that one is capable of saturating the 1GBps network either way. My best bet as to why that is is the difference in CPU (load), as the drives and the NICs are identical in both systems. 

Edited July 4, 20233 yr by Bo_

Unless it's really ancient hardware CPU basically shouldn't matter. Drives can though especially if they're SMR.

45 minutes ago, Kilrah said:

Unless it's really ancient hardware CPU basically shouldn't matter. Drives can though especially if they're SMR.

Would you call 15 years old CPU an ancient device? :)) I would... Furthermore, it's not a normal CPU, it's a hack. The Xeon originally was LGA 771 and I did a conversion to LGA 775. The motherboard is shady at best in a good day, but it was a system I could spare and didn't imagine the CPU would be a bottleneck.

I used to use this system for very long renders in Cinema4D - it used to run for weeks and months at a time and I even managed to play some VR games at some point.

The drives are almost identical on both systems. I'm using 8TB IronWolf drives but some of them are the Pro variant.

1 hour ago, Bo_ said:

Would you call 15 years old CPU an ancient device?

LOL, yep.