Custom Firmware v1.1.2.7

**Whissi** · 26-10-2004, 13:25

..........

**Oleg** · 26-10-2004, 13:51

Well, I've compiled hdparm (linked statically).
Somebody should try it and post output here.

**Styno** · 26-10-2004, 14:01

Originally Posted by Antiloop

okay.. and how to turn DMA on ?

(feeling dumb..)

hdparam of course

To be serious, I don't know. But because hdparam can do it on a regular Linux box, it probably can be set beforehand as well. I don't know enough of Linux to tell you where to do it.
Edit: Ah, Oleg allready produced hdparam. Jeez you're working fast *thumbs-up-smiley*

Originally Posted by Oleg

Launch epi_ttcp and measure it.
CPU as seems is too slow to give you more...

I thought these CPU's had hardware accelerated network stuff, or at least be optimized to be able to push a lot of packets. But apparently they do not. They are primary built for internet connections where 4 Mb/s is a lot, but not for LAN serving tasks where 100 Mb/s is the standard I guess.

To be not serious: We'll just have to wait for the competition in home routers to go into a megaherz race. In five years everyone will have a 4 GHz router for 100,-- Euro which uses more then 100 Watt/h. But at least they will be able to pump a 1 Gb/s pipe full of data from my year 2009 WL-RAID5-HDD while I'm playing the latest games on it with 200+ frames/s

**Oleg** · 26-10-2004, 14:11

Originally Posted by Styno

I thought these CPU's had hardware accelerated network stuff, or at least be optimized to be able to push a lot of packets.

It has nothing except integrated ethernet controller.

**Styno** · 26-10-2004, 14:42

Originally Posted by Oleg

Maximum ethernet speed for this box is something about 3.5 MB sec.

Hmm, that should bring the WL-500gx (Deluxe) to around 5.5 Mb/s second (Assuming it has the same ALU's but at 200MHz CPU instead of 125 MHz for WL-500g and WL-HDD).

**JOCKYW2001** · 26-10-2004, 15:19

Originally Posted by Oleg

Well, I've compiled hdparm (linked statically).
Somebody should try it and post output here.

I will definitely try, but I think it's the ethernet nic driver which needs a boost. Although what I can imagine is that hdd in pio mode terribly slows down the nic.

A while ago I did some measurements:
- Raw write speed to HDD is ~4.5mB/s and read speed ~9.5mB/s (measured by dd from and to /dev/zero)
- The NFS read/write speeds are ~2mB/s (direct 100mbs full duplux connect).

From this I more or less concluded that it is the nic driver to blame but who knows.

Improving performance is high up on my priority list and I will start work as soon as samba 3.0.7 is running stable on the wl-hdd.

**Oleg** · 26-10-2004, 15:27

Originally Posted by JOCKYW2001

I will definitely try, but I think it's the ethernet nic driver which needs a boost. Although what I can imagine is that hdd in pio mode terribly slows down the nic.

A while ago I did some measurements:
- Raw write speed to HDD is ~4.5mB/s and read speed ~9.5mB/s (measured by dd from and to /dev/zero)
- The NFS read/write speeds are ~2mB/s (direct 100mbs full duplux connect).

From this I more or less concluded that it is the nic driver to blame but who knows.

Improving performance is high up on my priority list and I will start work as soon as samba 3.0.7 is running stable on the wl-hdd.

Try running epi_ttcp using something like this:

Code:

epi_ttcp -t -v -u your_host_name < very_large_file_on_the_hdd

This will push the entire file to your host using udp (actually to nothing) and you will get maximum samba speed expectation (nfs should be a bit faster)...

**Oleg** · 26-10-2004, 15:30

Originally Posted by JOCKYW2001

I can imagine is that hdd in pio mode terribly slows down the nic.

Check the /proc/loadavg during the large transfer to/from /dev/null to check for dma/pio. If you see something like 1.0 - then it's definitely pio.

**Oleg** · 26-10-2004, 15:44

Some numbers:

Transferring 16MB data (mostly kernel space, everything is cached):

Code:

[root@wl500g root]$ epi_ttcp -t -s -v -u 192.168.0.1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Tue Oct 26 18:32:35 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.0.1 #
ttcp-t: 16777216 bytes in 4.593677 real seconds = 3.483 MB/sec +++
ttcp-t: 16777216 bytes in 4.600000 cpu  seconds = 3.478 MB/cpu sec
ttcp-t: 2054 I/O calls, 2.236 msec(real)/call, 2.240 msec(cpu)/call
ttcp-t: 0.060000user 4.540000sys 0:04real 100.1% 0i+0d 0maxrss 1+0pf 0+0csw
ttcp-t: buffer address 0x10008000
ttcp-t: File-Descriptor  fd 0x3 Closed
ttcp done.

Transferring cached data from RAM, interacting with user space - pipes, etc (mostly samba alike)

Code:

[root@wl500g root]$ epi_ttcp -t -v -u 192.168.0.1 < /tmp/test
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Tue Oct 26 18:30:50 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.0.1 #
ttcp-t: 3801552 bytes in 1.280250 real seconds = 2.832 MB/sec +++
ttcp-t: 3801552 bytes in 1.280000 cpu  seconds = 2.832 MB/cpu sec
ttcp-t: 470 I/O calls, 2.724 msec(real)/call, 2.723 msec(cpu)/call
ttcp-t: 0.000000user 1.280000sys 0:01real 100.0% 0i+0d 0maxrss 1+1pf 0+0csw
ttcp-t: buffer address 0x10008000
ttcp-t: File-Descriptor  fd 0x3 Closed
ttcp done.

transferring firmware image (wait cycles are added by slow flash)

Code:

[root@wl500g root]$ epi_ttcp -t -v -u 192.168.0.1 < /dev/mtdblock/1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Tue Oct 26 18:31:05 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.0.1 #
ttcp-t: 3801552 bytes in 2.502654 real seconds = 1.449 MB/sec +++
ttcp-t: 3801552 bytes in 1.370000 cpu  seconds = 2.646 MB/cpu sec
ttcp-t: 470 I/O calls, 5.325 msec(real)/call, 2.915 msec(cpu)/call
ttcp-t: 0.030000user 1.340000sys 0:02real 54.7% 0i+0d 0maxrss 1+1pf 0+0csw
ttcp-t: buffer address 0x10008000
ttcp-t: File-Descriptor  fd 0x3 Closed
ttcp done.

Transferring big file from usb flash drive

Code:

[root@wl500g root]$ epi_ttcp -t -v -u 192.168.0.1 < /tmp/harddisk/hydravision-3-20-2020.exe
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Tue Oct 26 18:33:24 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.0.1 #
ttcp-t: 11642283 bytes in 19.597037 real seconds = 580.160 KB/sec +++
ttcp-t: 11642283 bytes in 4.490000 cpu  seconds = 2.473 MB/cpu sec
ttcp-t: 1428 I/O calls, 13.723 msec(real)/call, 3.144 msec(cpu)/call
ttcp-t: 0.040000user 4.450000sys 0:19real 22.9% 0i+0d 0maxrss 2+1pf 0+0csw
ttcp-t: buffer address 0x10008000
ttcp-t: File-Descriptor  fd 0x3 Closed
ttcp done.

**Oleg** · 26-10-2004, 15:58

It's become really offtopic.

Yet another thing: USB is driven by dma:

Code:

[root@wl500g root]$ time dd if=/tmp/harddisk/hydravision-3-20-2020.exe of=/dev/null
22736+1 records in
22736+1 records out
real    0m 16.16s
user    0m 0.19s
sys     0m 1.14s

As you see CPU was idle most of the time (user + sys < real).

**Styno** · 26-10-2004, 16:15

Originally Posted by Oleg

It's become really offtopic.

Yet another thing: USB is driven by dma:

But very interesting

I have some problems understanding the figures you just gave with ttcp-t, but if I understand right, mem to mem copy over TCP/IP gives 3.6 MB/s. Thats not much and probably mostly CPU bound I guess. If its CPU bound then sending data using UDP might help a lot, because it requires much less CPU power. Using a TFTP server might speed up the transferrate a bit in that case.

**Oleg** · 26-10-2004, 16:26

Originally Posted by Styno

I have some problems understanding the figures you just gave with ttcp-t, but if I understand right, mem to mem copy over TCP/IP gives 3.6 MB/s.

In fact, 3.6 MB looks like no memory copy at all (but it should be one copy from user space to kernel) - ttcp just sends the same data over and over and it's cached.

Thats not much and probably mostly CPU bound I guess. If its CPU bound then sending data using UDP might help a lot, because it requires much less CPU power.

NFS uses udp, kernel space nfs does not perform mem copy at all.

Using a TFTP server might speed up the transferrate a bit in that case.

Well, tftp is really limited and all implementations are running in the user space.

**Oleg** · 26-10-2004, 16:28

Also, routing is running at the same 3.5 MB speed (no copy, kernel space only).

**Styno** · 26-10-2004, 16:58

Ok, I stay out of this discussion

**JOCKYW2001** · 27-10-2004, 21:54

Originally Posted by Oleg

Well, I've compiled hdparm (linked statically).
Somebody should try it and post output here.

Look at this. My drive is in UDMA2 mode, which is default firmware setting.
I guess there is not much more we can do about improving IDE speed.
Perhaps the focus should be on the ethernet driver?

Code:

# ../hdparm.mipsel -i /dev/ide/host0/bus0/target0/lun0/disc

/dev/ide/host0/bus0/target0/lun0/disc:

 Model=FUJITSU MHT2080AT, FwRev=0022, SerialNo=NN5AT4915M5H
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:

 * signifies the current active mode

Thread: Custom Firmware v1.1.2.7

Thread Tools

Display

Similar Threads

Custom Firmware v1.1.2.8

New custom firmware

New custom firmware - 1.7.5.6-1

custom firmware

Posting Permissions