Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Slow speeds

Featured Replies

I have had unraid server for a while now and had no problems with playback using regular dvd's but now playing HD I get some erratic stuttering.

 

I timed a 2gb file from the server to my vista machine and I got 11.23 MB/sec, that seems to me a little on the slow side.

 

The Vista pc had service pack 1 installed and it is a 32 ver

the router is a lynksys

I have a netgear gigabyte switch

and the server has an intel ethernet card

all are hardwired

 

Here is the ipconfig on the vista pc:

 

C:\Users\Jim>ipconfig

 

Windows IP Configuration

 

 

Ethernet adapter Local Area Connection 2:

 

   Connection-specific DNS Suffix  . : hsd01.il.hsd1.il.comcast.net

   Link-local IPv6 Address . . . . . : fe80::2d8c:a538:ca3a:685%12

   IPv4 Address. . . . . . . . . . . : 192.168.1.200

   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   Default Gateway . . . . . . . . . : 192.168.1.1

 

Tunnel adapter Local Area Connection* 6:

 

   Connection-specific DNS Suffix  . :

   IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e50:48:19f9:e7f3:2b20

   Link-local IPv6 Address . . . . . : fe80::48:19f9:e7f3:2b20%9

   Default Gateway . . . . . . . . . : ::

 

Tunnel adapter Local Area Connection* 7:

 

   Media State . . . . . . . . . . . : Media disconnected

   Connection-specific DNS Suffix  . : hsd01.il.hsd1.il.comcast.net

 

 

 

This is from unraid server:

 

root@Tower:~# ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:0E:0C:07:65:0A

          inet addr:192.168.1.142  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:772426 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1525857 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:50417661 (48.0 MiB)  TX bytes:2255236920 (2.1 GiB)

 

root@Tower:~# net lookup djsl-office

192.168.1.200

 

I have included the syslog

 

thanks in advance

 

Jim

 

 

I can tell some things from the syslog, but please outline the unraid's hw:

* mobo

* cpu

* amount of memory

* which intel NIC

* sata vs. pata

* how old the drives are

* ....

 

Also, have you tried going direct from the unraid to the PC, bypassing the switch?

 

11MB/sec is plenty to support HD, but it is low.

 

 

Bill

Your syslog looks fine, but it appears you just rebooted.  Would you mind doing that 2GB transfer again, and capturing the syslog after the transfer.  It may be useful to see if there are disk errors, or other problems appearing, during the transfer.  I agree, that 11MB/s seems too low.

 

Also, check out this speed tip:  http://lime-technology.com/wiki/index.php?title=Improving_unRAID_Performance#Increase_Read-Ahead_Buffer.  You might read the rest of the page too.

  • Author

I timed my htpc where I actually watch movies from which is also a vista 32 with service pack 1 and my speed went up to  22 m/second much better than my other pc that was 11.  I suspect the wiring is the problem on my slower pc because there is a long run with some very old cable.

 

Is 22 mb/sec a good transfer speed or should I shoot for faster?

 

My setup is a 

P5B-VM DO

Intel Celeron 420 Conroe-L 1.6GHz LGA 775

3g memory

the drives a mix of pata and sata and a mix of older and newer.

 

Rob I am using the read ahead buffer.  here is my go file:

 

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &

echo nameserver 192.168.1.1 >/etc/resolv.conf

echo 192.168.1.142 tower >> /etc/hosts

cp /boot/smtp_check_unraid.sh /etc/cron.hourly/

fromdos < /boot/custom/bin/spincontrol > /usr/sbin/spincontrol

chmod u+x /usr/sbin/spincontrol

/usr/sbin/spincontrol -I

fromdos < /boot/custom/bin/powerdown > /sbin/powerdown

chmod u+x /sbin/powerdown

sleep 30

blockdev --setra 2048 $i

 

The setra line needs to be expanded.

 

Here are my suggestions.

 

replace the current

 

blockdev --setra 2048 $i

 

with this snippet. ($i is undefined in your script so it's not really working.)

 

# set DEV to the highest MD device in your system. 
DEV=/dev/md2

while [[ ${LOOP:=10} -gt 1 && ! -b ${DEV} ]]
do
        (( LOOP=LOOP-1 ))
        echo "Waiting for ${DEV} to come online ($LOOP)"
        sleep 1
done

for disk in /dev/md*
do  blockdev --setra 2048 $disk
done

 

 

OR...

 

I actually have a whole shell you could just call

I call it  S01-blockdev

 

Put it in /boot/custom/etc/rc.d/S01-blockdev

#!/bin/bash

if [ ${DEBUG:=0} -gt 1 ]
   then set -x -v
fi

# Set to highest md device in your system. 

DEV=/dev/md2

while [[ ${LOOP:=10} -gt 1 && ! -b ${DEV} ]]
do
        (( LOOP=LOOP-1 ))
        echo "Waiting for ${DEV} to come online ($LOOP)"
        sleep 1
done

if [ ! -b ${DEV} ]
   then echo "Devices are not online, Array must be offline!"
        exit 129
fi

sleep 1

echo "Devices Online"
for disk in /dev/md*
do  blockdev --setra 2048 $disk
done

 

if you use my script instead of updating your go script with the snippet then

call it with the following line in your go script.

 

fromdos < /boot/custom/etc/rc.d/S01-blockdev | sh

 

I timed my htpc where I actually watch movies from which is also a vista 32 with service pack 1 and my speed went up to  22 m/second much better than my other pc that was 11.  I suspect the wiring is the problem on my slower pc because there is a long run with some very old cable.

 

Is 22 mb/sec a good transfer speed or should I shoot for faster?

 

My setup is a 

P5B-VM DO

Intel Celeron 420 Conroe-L 1.6GHz LGA 775

3g memory

the drives a mix of pata and sata and a mix of older and newer.

 

Rob I am using the read ahead buffer.  here is my go file:

 

#!/bin/bash

# Start the Management Utility

/usr/local/sbin/emhttp &

echo nameserver 192.168.1.1 >/etc/resolv.conf

echo 192.168.1.142 tower >> /etc/hosts

cp /boot/smtp_check_unraid.sh /etc/cron.hourly/

fromdos < /boot/custom/bin/spincontrol > /usr/sbin/spincontrol

chmod u+x /usr/sbin/spincontrol

/usr/sbin/spincontrol -I

fromdos < /boot/custom/bin/powerdown > /sbin/powerdown

chmod u+x /sbin/powerdown

sleep 30

blockdev --setra 2048 $i

 

That last line should be

blockdev --setra 2048 /dev/md1

 

I'm afraid somehow you copied part of the original tip into your "go" script.  As it is now, referencing "$i", it has no effect at all.

 

Originally I had written a "for loop" that itterated through all the /dev/md devices, assigning each device name to $i, and then executing the blockdev command on each in turn.  At one point, somebody discovered that all the "md" devices shared the same buffer size setting, so setting the size on one affected them all.

 

All that in mind, you only need one blockdev command, but it must name one of the "md" devices.  If you fix that last line in your go script (and then reboot), you will see even better performance than you do now.

 

If you want, you can correct the line now in the "go" sctipt. and at the command prompt using telnet type:

blockdev --setra 2048 /dev/md1

 

It will set the read-ahead buffer size now, and the corrected go script will do it in the future.

 

I see WeeboTech responded too.  His script will work too, but is more typing.  And he added a smarter loop to wait for the "md" devices to be online, but forgot to tell you, if you use it, you can remove your 30 second sleep that is there to allow time for the "md" devices to come on-line.  ;) The final loop through all the devices does no harm, but was found to be unnecessary. (or cutting/pasting)

 

Joe L.

ut forgot to tell you, if you use it, you can remove your 30 second sleep that is there to allow time for the "md" devices to come on-line.  ;)

 

I noticed it, but had not had a chance to respond.. work took precendnce.. then I forgot to modify :(

 

 

The final loop through all the devices does no harm, but was found to be unnecessary. (or cutting/pasting)

 

Ok so what you are saying is you only need to run the blockdev --setra 2048 /dev/md? on one device and the others will have the same change applied?

 

The first loop waits for the last device to come on line.

The second loop, does a blockdev --setra 2048 on every /dev/md* device found.

 

I suppose I could have combined it all into one loop. but for now this is how I have it set up.

 

Re: Less typing???

cur and past into a telnet screen  ;D

 

 

The first loop waits for the last device to come on line.

Yes, can't hurt, might even be better if the array comes up stopped.  (md devices not loaded)

 

The second loop, does a blockdev --setra 2048 on every /dev/md* device found.
Yes.

Ok so what you are saying is you only need to run the blockdev --setra 2048 /dev/md? on one device and the others will have the same change applied?

Yes, exactly.  If you set /dev/md1 and then getra on /dev/md4 it will have the exact same value you set.  apparently, they share the same buffer, or at the least, the same variable that sets the buffer size)

Re: Less typing???

cur and past into a telnet screen  ;D

Got me there...  ;)

 

The whole thing is better in a separate script as you have it, as the "md" devices are probably reset when you stop the array. (never checked... but if the "md" device module is unloaded, odds are any setting of the read-ahead buffer size is back to its original value when re-loaded)  If in a separate script, it can easily be re-invoked when the array is re-started.

 

Joe L.

  • Author

How do you know which one is the highest device in the system?

 

# Set to highest md device in your system.

 

DEV=/dev/md2

When your system is up,

Login as root

type df

 

notice the highest /dev/md number in the list.

On mine it is currently /dev/md3

 

root@Atlas:~# df -vH
Filesystem             Size   Used  Avail Use% Mounted on
/dev/sdb1              518M   126M   392M  25% /boot
tmpfs                  1.1M      0   1.1M   0% /mnt
/dev/sda2              4.1G   303M   3.8G   8% /mnt/ram
tmpfs                  1.1M      0   1.1M   0% /Atlas
/dev/md2               1.1T   502G   499G  51% /mnt/disk2
/dev/md1               1.1T   128G   873G  13% /mnt/disk1
shfs                   3.1T   630G   2.4T  21% /mnt/user
/dev/md3               1.1T    34M   1.1T   1% /mnt/disk3

  • Author

thanks for your help guys, I am up to 36 mb/sec now on a 2GB file.

 

The pc that has the old wire is still stuck at 11 mb/sec.  The wire is from when the house was buit in the 70's.  It is twisted pairs but not good enough I guess.

 

Jim

Your cable isn't likely from the 70s, but it may still be old crappy cable.

 

 

Bill

thanks for your help guys, I am up to 36 mb/sec now on a 2GB file.

 

The pc that has the old wire is still stuck at 11 mb/sec.  The wire is from when the house was buit in the 70's.  It is twisted pairs but not good enough I guess.

 

Jim

If you think back, in the 70's, a 1 meg LAN was common, with a 10 mb LAN the newest (if it even existed at that point in time).    Any wire installed back then would not even be close to being suitable for 100Mb LAN connections, let alone 1000 Mb LAN speed.

 

According to this paper: http://www.ethernetalliance.org/technology/white_papers/A_Bit_of_History.pdf  10Mb LAN did not exist till 1982.  Mid 1970's was 3 Mb/s.

10 Mb/s was common through 1990. 100 Mb/s did not occur until 1995, and 1000 Mb/s did not get developed until 1989/1990.

 

What you have to that old PC might be wire designed for telephone use.  :( 

 

You are lucky you are getting 11 mb/sec...

 

Joe L.

  • Author

Yes the wire was from the 70's the whole house had it all over the place..

 

I agree with Joe it was probably telephone wire.  I forgot how many pairs of twisted pairs it has but more than four.  I have a long run with regular cat5 cable to the attic and from there is a short drop down  to the pc with the existing wire.  I have been meaning to dig in there and replacing it one of these days.

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.