Difference transfer rate when copying files: 20 MB/s using Dlink firmware and 10MB/s with ALT-F

[Vincent Leplumey]

Hi,

I have the following hardware:

 - 1 DNS 323 declared in JOBD

 - 1 router DIR 825

 - 1 gigabit Dlink switch

 - 1 desktop with a 1 giga network adapter

Desktop is connected to the router

Router is connected to the gigabit Dlink switch

DNS 323 is connected to the switch

When I copy a large file (MP4) of 3.5 giga from the NAS into the Desktop, the transfer rate is:

- around 10 MB per seconds when using ALT-F (reload method)

- around 20 MB per seconds when using DLink firmware

Is there a way to configure the ALT-F so I can get a better rate transfer?

Note: the information of the rate transfer comes from Win 7 window that appears when you run a copy and that you click on more details, line Speed: see attachment highlighted in yellow

Also when I mount a USB thumb the transfer rate is poor: around 5 Mb/s. Same question; is there a way to configure Alt-F to have a faster transfer rate?

Thank you

[Joao Cardoso]

This is a recurrent question, and I always answer that the latest software versions (not only samba) are generally bloated, if compared with previous versions.

Now I decided to see if I was really right, or if I was just an unfair looser ;-)

So, I downloaded samba-3.0.24, that accordingly to http://dns323.kood.org/ is the samba version that ships with the DNS-323, compiled it with the same tools and options that the stock Alt-F samba is compiled, and installed and started it on the DNS-323.

I then used it to read a 1.5GB file on a RAID-1/ext3 filesystem in the nas to a MS-Vista computer over a 1Gbps network, and it measured 22.5MB/s, using the same method that you used.

The same file, using the current samba-3.5.15 version, transferred at 14.5MB/s.

So, I was right, and I'm not a bad sportsman (I always loose with a smile in my face :-)

As machines where software developers work become more and more powerful, both in CPU and memory, they (developers) start to neglect small (for their machines) performances issues, and start adding more and more features. That has a significant impact on lower performance boxes, but, who cares? buy a new machine!

[edited: the above phrase intended to be sarcastic, at least the planet cares]

Joao

[Joao Cardoso]

---------- Forwarded message ----------
From: TJ <...@gmail.com>
Date: Thu, Nov 29, 2012 at 1:47 AM
Subject: Re: Difference transfer rate when copying files: 20 MB/s using Dlink firmware and 10MB/s with ALT-F
To:...@gmail.com

I don't mean to steal the thread, just a quick question:

 

Is it possible for SAMBA to become an installable package (reside off the flash ROM)? I can think of two benefits:

 

A. Would no longer hog space of the flash chip (I know this has been a source of frustration)

 

B. The version would be user changeable. Maybe I'm happy with a more limited, yet faster SAMBA on one box (mediaserver) but need a complex user/group setup on another (dataserver). Just an idea.

 

Perhaps an older, slim SAMBA version could run off flash, but defaults to a newer version, if installed on disc? Maybe this is impractical. In any event, thank you for the firmware Joao, look forward to the RC3!

 

On Wednesday, November 28, 2012 1:37:26 PM UTC-5, Joao Cardoso wrote:

This is a recurrent question, and I always answer that the latest software versions (not only samba) are generally bloated, if compared with previous versions.

Now I decided to see if I was really right, or if I was just an unfair looser ;-)

So, I downloaded samba-3.0.24, that accordingly to http://dns323.kood.org/ is the samba version that ships with the DNS-323, compiled it with the same tools and options that the stock Alt-F samba is compiled, and installed and started it on the DNS-323.

I then used it to read a 1.5GB file on a RAID-1/ext3 filesystem in the nas to a MS-Vista computer over a 1Gbps network, and it measured 22.5MB/s, using the same method that you used.

The same file, using the current samba-3.5.15 version, transferred at 14.5MB/s.

So, I was right, and I'm not a bad sportsman (I always loose with a smile in my face :-)

As machines where software developers work become more and more powerful, both in CPU and memory, they (developers) start to neglect small (for their machines) performances issues, and start adding more and more features. That has a significant impact on lower performance boxes, but, who cares? buy a new machine!

Joao

On Wednesday, November 28, 2012 2:14:00 AM UTC, Vincent Leplumey wrote:

[Joao Cardoso]

On Thursday, November 29, 2012 4:34:46 AM UTC, Joao Cardoso wrote:

---------- Forwarded message ----------
From: TJ <...@gmail.com>
Date: Thu, Nov 29, 2012 at 1:47 AM
Subject: Re: Difference transfer rate when copying files: 20 MB/s using Dlink firmware and 10MB/s with ALT-F
To: ...@gmail.com

I don't mean to steal the thread, just a quick question:

 

Is it possible for SAMBA to become an installable package (reside off the flash ROM)? I can think of two benefits:

 

A. Would no longer hog space of the flash chip (I know this has been a source of frustration)

 

B. The version would be user changeable. Maybe I'm happy with a more limited, yet faster SAMBA on one box (mediaserver) but need a complex user/group setup on another (dataserver). Just an idea.

 

Perhaps an older, slim SAMBA version could run off flash, but defaults to a newer version, if installed on disc? Maybe this is impractical. In any event, thank you for the firmware Joao, look forward to the RC3!

Interesting that you raised the question, because I had already thinking doing something similar.

Not specifically because of samba, but because of package upgrading.

You all know that it is relatively simple (in most cases) to update disk-instalable packages, but I know that making a release is much more difficult.

And what happens after Alt-F-1.0 is released? This will happen after RC3, and development will cease or decrease. What will happen with all packages available in the base firmware? The obvious solution is to release packages to update just them.

Of course, the previous versions  burned into the firmware will become available again  if the disk where packages are installed is removed. And probably disks will no longer spin-down anymore, as programs are now running from them.

That has not yet been done, but I think that I will start doing that soon, one package at a time and slowly.

However, the base firmware will be as is now, using the last (when possible, samba-3.6 just don't fit).

samba-extra and samba-modules are already available, why not a samba-fast or a samba-full package?

Thanks,

Joao 

[Stealth]

Of course, the previous versions  burned into the firmware will become available again  if the disk where packages are installed is removed. And probably disks will no longer spin-down anymore, as programs are now running from them.

Very great idea ! Unfortunately no spin-down is a significant restriction for an usual usage

 

[Dick O]

Very great idea ! Unfortunately no spin-down is a significant restriction for an usual usage

 

Maybe it's an option to install those packages on a usb flashdrive to avoid the lack of spin-down?

[Joao Cardoso (Alt-F)]

On Friday 07 December 2012 15:58:53 Dick O wrote:
> Op woensdag 5 december 2012 16:11:42 UTC+1 schreef Stealth het volgende:

> > Very great idea ! Unfortunately no spin-down is a significant

> > restrictionfor an usual usage

> Maybe it's an option to install those packages on a usb flashdrive to avoid
> the lack of spin-down?

All packages have to be installed in the same filesystem.
Of course it is possible to have several install locations, but that is not
going to be an Alt-F feature.

So, if anybody wants to avoid disk spindown problems with *any* *running*
package, it must specify as the install location a USB pen filesystem.

Beware that some packages services might do heavy writes to the USB, such as
updating databases, shortening the USB pen life.

It is possible, by using a few commands, to transfer a current Alt-F package
installation from one place to another.
A tentative, untested approach follows, please report back success or in-
success.

Start to stop all services, preferably after a reboot, to avoid possible
problems.
Use 'rcall status' to make sure that all services are stopped. Some services,
that use kernel modules that can't be unloaded, can't be fully "stopped"; so
these have to be boot disabled before the reboot.

---8<-------------
#!/bin/sh

new=/mnt/sdc1 # replace with new Alt-F root fs location
curr=$(readlink -f /Alt-F)

if ! mountpoint -q $new; then
echo "NO, $new has to be a filesystem mountpoint"
exit 1
fi

if test -d $new/Alt-F; then
echo "NO, $new/Alt-F already exists"
exit 1
fi

if ! aufs.sh -u; then
echo "NO, /Alt-F still in use"
exit 1
fi

if ! cp -a $curr $new; then
echo "NO, copy failed"
rm -rf $new/Alt-F
exit 1
fi

mv $curr/Alt-F $curr/Alt-F-orig
rm /Alt-F
ln -sf $new/Alt-F /Alt-F
aufs.sh -m

echo "YES, succeed"

--->8---------

But this is going out of topic now...