DSM-G600, DNS-3xx and NSA-220 Hack Forum

jens wrote:

wow you are getting that much????

The unit should definately get 100mbps speeds (80-90mbps) but it DOESNT...

That probably depends how you measure it. I would be very surprised if you managed to pump out more than 30Mb/s from IDE drive (RAID arrays and real SCSI drives might be another matter).

On my box, I get

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   110 MB in  2.03 seconds =  54.19 MB/sec
 Timing buffered disk reads:   54 MB in  3.03 seconds =  17.82 MB/sec

What does that mean?

I can get 54 Mb of transfer if I'm happy allthough that I'm transferring just data which is already in drive cache (which is 2Mb if I'm not mistaken, it's one of older Maxtor 250Gb models).

However, since most of the time it isn't (and it's not in memory cache either because RAM on device is limited) we are limited to drive speed of 17 Mb/s.

However, ext3 (or ext2, whatever you are running on device) isn't fastest file-system in the world. So you will not get 17 Mb/s when reading even locally:

First, let's create local 1Gb file for testing:

# ddrescue /dev/zero /tmp/foo -s 1G  
rescued:     1000 MB,  errsize:       0 B,  current rate:   13172 kB/s
   ipos:   999948 kB,   errors:       0,    average rate:   13857 kB/s
   opos:   999948 kB

This shows average rate of 13 Mb/s which is close to therotical maximum of disk platter speeds of 17 Mb/s (think about filesystem overhead and seeking). Extent-based filesystem like ext4 (and xfs, if I'm not mistaken) might help here.

Then we read back the file:

# ddrescue /tmp/foo /dev/null        
rescued:     1000 MB,  errsize:       0 B,  current rate:   28835 kB/s
   ipos:   999948 kB,   errors:       0,    average rate:   27837 kB/s
   opos:   999948 kB

We get nice transfer rate of 27 Mb/s (disk cache, and kernel read-ahead buffers are helping here). Disk read speeds also depend on physical location on disk platter, and we don't know anything about that (I can digg-out a link to benchmark for that if anybody is interested).

This is local speed, without any network or samba overhead. Overhead, hmm... let's see...

This is output from my laptop, connected directly to DSM (with 1000 Mbps Full Duplex, Flow Control: RX).

dd_rescue: (info): ipos:    976512.0k, opos:    976512.0k, xferd:    976512.0k
                   errs:      0, errxfer:         0.0k, succxfer:    976512.0k
             +curr.rate:     4174kB/s, avg.rate:     4142kB/s, avg.load:  4.6%

Quite bad, actually... If we test just netcat connection (closest to Network speed) we get:

dd_rescue: (info): ipos:    976512.0k, opos:    976512.0k, xferd:    976512.0k
                   errs:      0, errxfer:         0.0k, succxfer:    976512.0k
             +curr.rate:     1132kB/s, avg.rate:     6511kB/s, avg.load:  3.5%

Which is better than 4 Mb/s, but 6 Mb/s still isn't gigabit networking.

Reading /dev/zero over network pipe gives better results (there are no disk accesses):

dd_rescue: (info): ipos:   1048576.0k, opos:   1048576.0k, xferd:   1048576.0k
                   errs:      0, errxfer:         0.0k, succxfer:   1048576.0k
             +curr.rate:     9776kB/s, avg.rate:     9716kB/s, avg.load:  5.3%

Which gives me just below 10 Mb/s. I can't quite explain this. I would look at bridge performance next, but enough testing for one day :-)

All being said, this is totally non-scientific method of assessing performance (just one run, etc). But it's a ballpoint figure.

But, all in all, it's not near gigabit speeds unfortunately.

jens wrote:

A possible solution would be to replace the dlink firmware with a stripped down version of the firmware dedicated to only fileserving capabilites (no upnp, no wifi) just samba, ftp, and a thin web interface.

Doesnt seem like the guys are getting anywhere with the custom firmware...
Perhaps I could donate my g600 to experimental use??

2.6 kernel would really help with adaptive I/O scheduling. Witout that, we could just tune noatime and friends for ext2/3 or move to faster filesystem, but disk transfer rates are limiting factor.

If you are willing to hack and compile kernel, by all means please do so. I will try to find more time for this little device, but I can't promise much.

Last edited by dpavlin (2007-07-22 17:51:23)