Custom Firmware v1.1.2.7

[JOCKYW2001]

For all WL-HDD users here's a custom firmware which includes:
* telnet daemon
* nfsv3 daemon
* ftp daemon (replaces stupid-ftpd)
* doesn't poll for the harddisk ãnymore each 5 seconds

Every feature of the original 1.1.2.7 firmware is in this custom version, except NTFS R/W support!

You find the 11.5Mb zip file here:
http://website.wl500g.info/beta/firmware.php?fid=10
(courtesy of Antiloop, thanks man :cool: )

Below you find a copy of the accompanying readme.

JockyW



Readme.txt:
----------

Date: 17 Oct 2004
Created by: JockyW

THIS STUFF IS ONLY FOR WL-HDD2.5 USERS WHO KNOW WHAT THEY ARE DOING!!!
I TAKE NO RESPONSIBILITY FOR ANY DAMAGE

Consult the WL-HDD forum on http://www.chupa.nl if you need support.
(Since my time is limited I can not offer 24/7 support-:) )

What's it all about
-------------------

This 1.1.2.7 based firmware + files which need to be installed on the built-in harddisk offers TELNET, NFSv3 (kernelspace), VSFTPD 2.0.1, Samba and HDD watchdog removed. I use this custom firmware for streaming from and to my satreceiver (Dbox2)

Prerequisites
-------------

- An Asus WL-HDD2.5 with built-in HDD which contains a shared partition "part1" which can be accessed from your PC with RW access
- I assume the IP of the Asus is 192.168.1.220
- After unpacking the zip file you should have these 3 files:
WLHDD_1.1.2.7_en.trx
tmp.rar
conf.tar.gz
- you have an unrar util on your PC (I use Winrar)

How to install
--------------

1) connect your PC by wire to the WL-HDD
2) boot up your WL-HDD
3) copy the files tmp.rar and conf.tar.gz to the root directory of the part1 share
4) unrar the file tmp.rar to /tmp (be careful: the files should be in /tmp *not* in /tmp/tmp !)
5) open the "backdoor" webpage in your browser: http://192.168.1.220/Main_AdmStatus_Content.asp
http://wl-hdd/index.asp : Admin
6) copy the following command to the "System Command" textbox and then click the "Refresh" button:
chmod a+x /tmp/harddisk/part1/tmp/busybox
7) copy the following command to the "System Command" textbox and then click the "Refresh" button:
chmod a+x /tmp/harddisk/part1/tmp/telnetd
8) copy the following command to the "System Command" textbox and then click the "Refresh" button:
ln -s /tmp/harddisk/part1/tmp/busybox /tmp/harddisk/part1/tmp/sh
9) copy the following command to the "System Command" textbox and then click the "Refresh" button:
/tmp/harddisk/part1/tmp/telnetd -d -l /tmp/harddisk/part1/tmp/sh &
10) the previous command started the telnet daemon and now you can access it from your PC with: telnet 192.168.1.220
11) on the prompt type:
cd /tmp/harddisk/part1
12) enter the command:
tmp/busybox tar xzvf conf.tar.gz
13) all necessary files are now installed on the harddisk and now you flash the new firmware WLHDD_1.1.2.7_en.trx on your WL-HDD
14) wait until flashing is done and until the Asus has rebooted itself
15) congratulations! you (hopefully) made it :D

How to use
----------

1) you can now telnet directly into your Asus with: telnet 192.168.1.220
2) same for ftp (ftp 192.168.1.220): username = admin , password = admin
3) to use NFS you have to edit the file "exports" which you can do with a Unix compatible texteditor such as ultraedit on Windowz. You find it in the directory /conf/etc on the "part1" share. The absolute pathname is /tmp/harddisk/part1/conf/etc/exports

What's to come
--------------

Eventually a full blown Linux distribution with interesting apps which still can perform in the 16MB ram of the WL-HDD.
But that only with the efforts of other more experienced Linux coders.

My next version will be based on the now available 1.1.2.8

Credits
-------

Without the help of Oleg and Antiloop of www.chupa.nl things would have taken much longer.
Greetings to petgun and rubberdick who tested the NFS with their dbox satreceivers.

Enjoy!
JockyW

[Styno]

What is that new FTP daemon able to do? Is it better then stupid-ftp?

[JOCKYW2001]

it's not that stupid as stupid-ftpd :)

You can up and dl trees, define users, chmod, optional pam security etc. It's also faster. See http://vsftpd.beasts.org/ for more info

[Oleg]

JockyW, do you've any thoughts regarding unified firmware sources? Check this thread (http://wl500g.info/showthread.php?t=1036).

[JOCKYW2001]

JockyW, do you've any thoughts regarding unified firmware sources? Check this thread (http://wl500g.info/showthread.php?t=1036).

Yeah, sure am interested in a unified firm. I dl your stuff and will see if I can develop a "merger". I suppose "make menuconfig" should have a target select.

[Oleg]

Yeah, sure am interested in a unified firm. I dl your stuff and will see if I can develop a "merger". I suppose "make menuconfig" should have a target select.
No, it's just have special targets in the makefile to allow mass builds.
Wait for 1.8.1.7-2 sources, they're updated a bit.

[Styno]

it's not that stupid as stupid-ftpd :)

You can up and dl trees, define users, chmod, optional pam security etc. It's also faster. See http://vsftpd.beasts.org/ for more info
Lol, I am in the process of building my own compiler environment to get this one compiled (but I'm low on spare time lately). I'm very interested in a binary for testing on WL-500g! :p

If this FTP server works well, Oleg might compile it into the custom firmwares (hint, hint ;)).

I hope it does 'upload resume', I really need that!

[Oleg]

If this FTP server works well, Oleg might compile it into the custom firmwares (hint, hint ;)).
Yes, I'm interesting in replacing stupid-ftpd and happily include vs-ftpd if it's provides fully functional replacement for stupid-ftpd in the firmware.

[JOCKYW2001]

Wait for 1.8.1.7-2 sources, they're updated a bit.
Ok,pls leave a message when ready

[Antiloop]

it's not that stupid as stupid-ftpd :)

You can up and dl trees, define users, chmod, optional pam security etc. It's also faster. See http://vsftpd.beasts.org/ for more info
is it included in the firmware or in the files you have to put on the hdd?

(thus how big is it??)

[JOCKYW2001]

In the files for the hdd.
I just mailed this to Styno:

--------------------
It's contained in the file conf.tar.gz which sits in the 11.5Mb .zip which you can download from the thread. But there are a couple of prerequisites:
1. you need a /etc/passwd and /etc/group
2. you need the libs where vsftpd dynamically links with (libc.so, and the libnss_files)
3. you need the file /etc/vsftpd.conf

All this stuff is in conf.tar.gz which I suggest you untar on a usb memstick or usb hdd.

Then open a telnet session and export LD_LIBRARY_PATH=...../conf/usr/lib ,fill in the dots!)

Then change to ..../conf/bin and start vsftpd by:
./vsftpd &

My passwd and group files contain a user admin with passw admin who is a superuser with homedir /tmp/harddisk (you probably need to change that too). You should also take a look at /etc/vsftpd.conf and suit it to your needs.
------------------------

[ardidi]

how to add a new user?

I can only use admin:admin now

[JOCKYW2001]

Good question, I didn't explain it yet.

In /tmp/harddisk/part1/conf/bin you find a file called busybox.new with contains unix account functions such as adduser, passwd, addgroup, etc.
(I compiled busybox.new from the busybox 1.0.0 tarball and had to patch it a bit because STDIN doesn't work for whatever reason)

To create new users do the following:
0. open telnet session
1. export LD_LIBRARY_PATH=/tmp/harddisk/part1/conf/usr/lib
2. cd /tmp/harddisk/part1/conf/bin
3. ./busybox.new (this shows all available functions)
4. ./busybox.new adduser -h /tmp/harddisk -s /bin/sh john (this adds user john)
5. ./busybox.new passwd john
6. ./busybox.new vi /etc/passwd (edit the passwd file and set for example gui to 0)

You can check it with:
more /etc/passwd
which shows a line like this:
john:$1$$f3u7Mm0KiM3Gt.egss/KI.:500:0:Linux User,,,:/tmp/harddisk:/bin/sh

Now use a ftp client and test your new account. Should work :)

Have fun,
JockyW

[Whissi]

..........

[JOCKYW2001]

After I flashed, the power-led is blinking. The Disk-Status is "File system inconsistence". I try'ed a filecheck - nothing changed.

Your disk is fine. I removed some Asus specific code from the "watchdog" loop. That code checks each ~5 seconds if the HDD is present by creating a directory, checking if it's there and then removing it again. By removing that piece of code the Asus now permanently believes that the filesystem is inconsistent and that is indicated by a flashing powerled and in the webinterface. Ignore it for now, I will fix that in the next custom firm version. Another symptom is that the Asus can not be brought down anymore by pressing the button.




How do I have to cónfigure nfs to work with my dbox2?
The only thing is to edit the file /tmp/harddisk/part1/conf/etc/exports. There you indicate which directories you wish to share to one or more PCs.
You can do that with the vi editor which is part of the busybox and busybox.new in /tmp/harddisk/part1/conf/bin or with a unix friendly editor such as ultraedit. In case you like to use vi you open a telnet session and type:
/tmp/harddisk/part1/conf/bin/busybox vi /tmp/harddisk/part1/conf/etc/exports

In case you use ultraedit you must share part1 (rw) via the webinterface.

JockyW

[Whissi]

..........

[JOCKYW2001]

I had similar thoughts :) The ethernet nic and wlan nic must have different ip addresses. Atm they have the same address. I have to look into using ifconfig to configure different addresses. Once that is solved the wlan can be in AP mode. If you have an existing wlan router the asus can also be a wlan client.

I don't have much time atm, so either wait or inspire someone else to do this job.

JockyW

[Whissi]

..........

[JOCKYW2001]

Give it a shot: Configure the asus as an Access Point (AP) and try.

JockyW

[Whissi]

..........

[Whissi]

..........

[Styno]

After I recorded a movie, I tried to download it via network (100mbit over a switch). The download took about 10minutes!!! Is it normal? I don't use 2.5" hdd so often, but I thought I've bought a good hdd (http://www.hgst.com/hdd/travel/tr80gn.htm)... Is it normal or the hdd?
WL-HDD transferrate is horrible. Check the following topic:
http://wl500g.info/showthread.php?t=1025

[Whissi]

..........

[Styno]

Hmm... sounds bad :mad:

I searched for other payable NAS devices, but all devices, which are between 100-300euro, are having a max speed of 1,5MB/s... so I think I'll keep my wl-hdd...
I guess there needs to be done some research into this problem. There are some things to consider:
- Theoratical HD transfer 3+ MB/s (4200 rpm 2.5")
- Theoratical ethernet 8+ MB/s (100Mb/s)

It seems to me there are 2 major bottlenecks to tackle. The slow transferrate can be explained if the HDD is in PIO mode and/or the CPU load is maxed out when transferring files.

I think the first thing to do about the slow transferrate is to modify the kernel so it supports DMA transfers to the HDD. When the HDD is in DMA mode the CPU load will be lower as well, so theres a win-win situation...

[Oleg]

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

[Styno]

Maximum ethernet speed for this box is something about 3.5 MB sec.
Okay, but thats still 3 times more than whats being reached now. I think a DMA mode driver for the Promise IDE chip should accomplish this.

[JOCKYW2001]

Maximum ethernet speed for this box is something about 3.5 MB sec.
Where did you find this? Can it be improved by modifying the driver?

[Oleg]

Where did you find this? Can it be improved by modifying the driver?
Launch epi_ttcp and measure it.
CPU as seems is too slow to give you more...

[Oleg]

Okay, but thats still 3 times more than whats being reached now. I think a DMA mode driver for the Promise IDE chip should accomplish this.
Yes, if still not turned on.

[Antiloop]

okay.. and how to turn DMA on ? :D (feeling dumb..)

[Whissi]

..........

[Oleg]

Well, I've compiled hdparm (http://wl500g.dyndns.org/hdparm.mipsel) (linked statically).
Somebody should try it and post output here.

[Styno]

okay.. and how to turn DMA on ? :D (feeling dumb..)
hdparam of course :D

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*


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 :p

[Oleg]

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]

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]

Well, I've compiled hdparm (http://wl500g.dyndns.org/hdparm.mipsel) (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]

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:



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]

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]

Some numbers:

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


[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)


[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)


[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


[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]

It's become really offtopic. :)

Yet another thing: USB is driven by dma:



[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]

It's become really offtopic. :)
Yet another thing: USB is driven by dma:
But very interesting :cool:

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]

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]

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

[Styno]

Ok, I stay out of this discussion :)

[JOCKYW2001]

Well, I've compiled hdparm (http://wl500g.dyndns.org/hdparm.mipsel) (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?



# ../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

[Styno]

Bummer. Getting more speed using hdparam would be simple and quick. Ethernet tweaking will be much more difficult I guess.

[Oleg]

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.

Right, it's already at udma2...


Perhaps the focus should be on the ethernet driver?

We need to focus at CPU overclocking. ;-)

In fact, have you tried ttcp with transfering large file via udp?

[Whissi]

..........

[Antiloop]

There is something, I cannot understand:
A dbox2 has got a 67Mhz CPU, but this box can reach nearly 10mbit.

I connected my WL-HDD device via cable to my router (100mbit) and at least to my computer (via this router (=switch)). So a 100mbit connection was established.

I start down/uploading a file and my ftp program (flashfpx) said, that I reached a max transferspeed of 2000kb/s, which are ~14mbit If I didn't calculate wrong... only 14% of 100mbit...
NOFI:
Mhz do not mean anything...

e.g. a Via epia thingie CPU at 533 is not as fast as a Pentium3 running at 533.. etc..

and a AMD XP2000+ running at 1666mhz should be compareble with a P4 2Ghz so it doesn't mean anything..

[Whissi]

..........

[JOCKYW2001]

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

Below are ttcp performance tests for the WL-HDD:
(The 192.168.1.123 is a Knoppix linux box)

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


# epi_ttcp -t -s -v -u 192.168.1.123
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Fri Oct 29 17:13:56 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.1.123 #
ttcp-t: 16777216 bytes in 4.753009 real seconds = 3.366 MB/sec +++
ttcp-t: 16777216 bytes in 4.760000 cpu seconds = 3.361 MB/cpu sec
ttcp-t: 2054 I/O calls, 2.314 msec(real)/call, 2.317 msec(cpu)/call
ttcp-t: 0.050000user 4.710000sys 0:04real 100.1% 0i+0d 0maxrss 1+0pf 0+0csw
ttcp-t: buffer address 0x10004000
ttcp-t: File-Descriptor fd 0x3 Closed
ttcp done.


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


# epi_ttcp -t -v -u 192.168.1.123 < /dev/mtdblock/1
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Fri Oct 29 16:50:06 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.1.123 #
ttcp-t: 3867096 bytes in 2.346390 real seconds = 1.572 MB/sec +++
ttcp-t: 3867096 bytes in 1.350000 cpu seconds = 2.732 MB/cpu sec
ttcp-t: 478 I/O calls, 4.909 msec(real)/call, 2.824 msec(cpu)/call
ttcp-t: 0.000000user 1.350000sys 0:02real 57.5% 0i+0d 0maxrss 1+0pf 0+0csw
ttcp-t: buffer address 0x10004000
ttcp-t: File-Descriptor fd 0x3 Closed
ttcp done.



Transferring a 47MB big file from harddisk (Samba 2.0.7)


# epi_ttcp -t -v -u 192.168.1.123 < /tmp/harddisk/part1/Movies/ML.ts
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Fri Oct 29 17:09:45 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.1.123 #
ttcp-t: 49006302 bytes in 19.605465 real seconds = 2.384 MB/sec +++
ttcp-t: 49006302 bytes in 17.810000 cpu seconds = 2.624 MB/cpu sec
ttcp-t: 5988 I/O calls, 3.274 msec(real)/call, 2.974 msec(cpu)/call
ttcp-t: 0.120000user 17.690000sys 0:19real 90.8% 0i+0d 0maxrss 4+0pf 0+0csw
ttcp-t: buffer address 0x10004000
ttcp-t: File-Descriptor fd 0x3 Closed
ttcp done.



Transferring a 47MB big file from harddisk (Samba 3.0.7)


# epi_ttcp -t -v -u 192.168.1.123 < /tmp/harddisk/part1/Movies/ML.ts
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5010
ttcp-t: start time Fri Oct 29 17:11:18 2004
ttcp-t: File-Descriptor 0x3 Opened
sockbufsize=32767,
# udp sender -> 192.168.1.123 #
ttcp-t: 49006302 bytes in 19.677441 real seconds = 2.375 MB/sec +++
ttcp-t: 49006302 bytes in 17.860000 cpu seconds = 2.617 MB/cpu sec
ttcp-t: 5988 I/O calls, 3.286 msec(real)/call, 2.983 msec(cpu)/call
ttcp-t: 0.110000user 17.750000sys 0:19real 90.8% 0i+0d 0maxrss 4+0pf 0+0csw
ttcp-t: buffer address 0x10004000
ttcp-t: File-Descriptor fd 0x3 Closed
ttcp done.

[JOCKYW2001]

.... We need to focus at CPU overclocking. ;-)


You mean tweak etc47xx.c here ?


/*
* We want the phy registers to be accessible even when
* the driver is "downed" so initialize MDC preamble, frequency,
* and whether internal or external phy here.
*/
/* default: 100Mhz SB clock and external phy */
W_REG(&regs->mdiocontrol, 0x94);
if (ch->etc->deviceid == BCM47XX_ENET_ID) {
/* 4710A0 has a 100Mhz SB clock and external phy */
W_REG(&regs->mdiocontrol, 0x94);
} else if (ch->etc->deviceid == BCM4402_ENET_ID) {
/* 4402 has 62.5Mhz SB clock and internal phy */
W_REG(&regs->mdiocontrol, 0x8d);
} else if (ch->etc->deviceid == BCM4310_ENET_ID) {
/* 4310 has a 124.8Mhz SB clock and external phy */
W_REG(&regs->mdiocontrol, 0x99);
} else if (ch->etc->deviceid == BCM4307_ENET_ID) {
/* 4307 has 88 MHz SB clock and external phy */
W_REG(&regs->mdiocontrol, 0x92);

e.g. 0x9A instead of 0x99 ?

[Oleg]

You mean tweak etc47xx.c here ?

e.g. 0x9A instead of 0x99 ?

No, this was just a joke. Our device is identified as BCM47XX_ENET_ID. Changes here will just change internal timings and it will not 10/100 compatible anymore.
There is no way to change CPU speed.

[JOCKYW2001]

No, this was just a joke. Our device is identified as BCM47XX_ENET_ID. Changes here will just change internal timings and it will not 10/100 compatible anymore.
There is no way to change CPU speed.
Asus wouldn't be Asus if there isn't anything left to overclock :D

Okay, then for the other options:
1. The ethernet watchdog kicks in each second. Will performance improve if we lower that frequency?
2. Is the eth driver in pio mode?
3. Can we do anything else to improve driver performance?

[JOCKYW2001]

... 3. Can we do anything else to improve driver performance?
I read this in et_linux.c and it gives me the creaps. To me it seems there's a lot which can be done to improve ethernet performance.

/*
* Yeah, queueing the packets on a tx queue instead of throwing them
* directly into the descriptor ring in the case of dma is kinda lame,
* but this results in a unified transmit path for both dma and pio
* and localizes/simplifies the netif_*_queue semantics, too.
*/
static int
et_start(struct sk_buff *skb, struct net_device *dev)
{
...

[hugo]

looking at my klogd output, I found the following info:



Nov 17 11:22:51 wl-hdd user.info kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Nov 17 11:22:51 wl-hdd user.warn kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: IDE controller on PCI bus 01 dev 08
Nov 17 11:22:51 wl-hdd user.warn kernel: PCI: Enabling device 01:01.0 (0004 -> 0007)
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: chipset revision 2
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: not 100% native mode: will probe irqs later
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: ROM enabled at 0x000d0000
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode.
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: FORCING BURST BIT 0x00 -> 0x01 ACTIVE
Nov 17 11:22:51 wl-hdd user.warn kernel: ide0: BM-DMA at 0x0140-0x0147, BIOS settings: hda:pio, hdb:pio
Nov 17 11:22:51 wl-hdd user.warn kernel: ide1: BM-DMA at 0x0148-0x014f, BIOS settings: hdc:pio, hdd:DMA
Nov 17 11:22:51 wl-hdd user.warn kernel: hda: IBM-DADA-25400, ATA DISK drive
Nov 17 11:22:51 wl-hdd user.warn kernel: ide2: ports already in use, skipping probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ing probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ide4: ports already in use, skipping probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ide5: ports already in use, skipping probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ide0 at 0x100-0x107,0x10a on irq 6
Nov 17 11:22:51 wl-hdd user.warn kernel: blk: queue c002f2c8, I/O limit 4095Mb (mask 0xffffffff)
Nov 17 11:22:51 wl-hdd user.info kernel: hda: 10553760 sectors (5404 MB) w/460KiB Cache, CHS=11168/15/63, UDMA(33)
Nov 17 11:22:51 wl-hdd user.info kernel: Partition check:
Nov 17 11:22:51 wl-hdd user.info kernel: /dev/ide/host0/bus0/target0/lun0: [PTBL] [698/240/63] p1 p2
N


Notice the "Assuming 33 Mhz bus", and the "hda: pio, hdb: pio" line. Is there something wrong with the controler? I mean the bus speed is probably ok, but maybe can be tweaked, but the fact hda report as pio?

My hdparm output is


[admin@wl-hdd bin]$ ./hdparm.mipsel -i /dev/hda

/dev/hda:

Model=IBM-DADA-25400, FwRev=AD5OA4BA, SerialNo=ZB2ZB018828
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=11168/15/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=460kB, MaxMultSect=16, MultSect=16
CurCHS=11168/15/63, CurSects=10553760, LBA=yes, LBAsects=10553760
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17: 1 2 3 4

* signifies the current active mode

So the hdparm think it is dma. Isn't it fooled by the system? Maybe it is still pio mode and reports badly under hdparm?

What do you think?

[Antiloop]

looking at my klogd output, I found the following info:



Nov 17 11:22:51 wl-hdd user.info kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31
Nov 17 11:22:51 wl-hdd user.warn kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: IDE controller on PCI bus 01 dev 08
Nov 17 11:22:51 wl-hdd user.warn kernel: PCI: Enabling device 01:01.0 (0004 -> 0007)
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: chipset revision 2
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: not 100% native mode: will probe irqs later
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: ROM enabled at 0x000d0000
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: (U)DMA Burst Bit DISABLED Primary PCI Mode Secondary PCI Mode.
Nov 17 11:22:51 wl-hdd user.warn kernel: PDC20265: FORCING BURST BIT 0x00 -> 0x01 ACTIVE
Nov 17 11:22:51 wl-hdd user.warn kernel: ide0: BM-DMA at 0x0140-0x0147, BIOS settings: hda:pio, hdb:pio
Nov 17 11:22:51 wl-hdd user.warn kernel: ide1: BM-DMA at 0x0148-0x014f, BIOS settings: hdc:pio, hdd:DMA
Nov 17 11:22:51 wl-hdd user.warn kernel: hda: IBM-DADA-25400, ATA DISK drive
Nov 17 11:22:51 wl-hdd user.warn kernel: ide2: ports already in use, skipping probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ing probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ide4: ports already in use, skipping probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ide5: ports already in use, skipping probe
Nov 17 11:22:51 wl-hdd user.warn kernel: ide0 at 0x100-0x107,0x10a on irq 6
Nov 17 11:22:51 wl-hdd user.warn kernel: blk: queue c002f2c8, I/O limit 4095Mb (mask 0xffffffff)
Nov 17 11:22:51 wl-hdd user.info kernel: hda: 10553760 sectors (5404 MB) w/460KiB Cache, CHS=11168/15/63, UDMA(33)
Nov 17 11:22:51 wl-hdd user.info kernel: Partition check:
Nov 17 11:22:51 wl-hdd user.info kernel: /dev/ide/host0/bus0/target0/lun0: [PTBL] [698/240/63] p1 p2
N


Notice the "Assuming 33 Mhz bus", and the "hda: pio, hdb: pio" line. Is there something wrong with the controler? I mean the bus speed is probably ok, but maybe can be tweaked, but the fact hda report as pio?

My hdparm output is


[admin@wl-hdd bin]$ ./hdparm.mipsel -i /dev/hda

/dev/hda:

Model=IBM-DADA-25400, FwRev=AD5OA4BA, SerialNo=ZB2ZB018828
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=11168/15/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=460kB, MaxMultSect=16, MultSect=16
CurCHS=11168/15/63, CurSects=10553760, LBA=yes, LBAsects=10553760
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17: 1 2 3 4

* signifies the current active mode

So the hdparm think it is dma. Isn't it fooled by the system? Maybe it is still pio mode and reports badly under hdparm?

What do you think?

[admin@WLHDD /tmp]$ ./hdparm -T /dev/discs/disc0/disc

/dev/discs/disc0/disc:
Timing cached reads: 100 MB in 2.03 seconds = 49.26 MB/sec
[admin@WLHDD /tmp]$ ./hdparm -t /dev/discs/disc0/disc

/dev/discs/disc0/disc:
Timing buffered disk reads: 22 MB in 3.15 seconds = 6.98 MB/sec

should say enough I think
the WL-HDD is not sufficient to handle more than it does..

please wait for WL-HDD3.5 if you need more power

[brubber]

please wait for WL-HDD3.5 if you need more powerAny idea when?

[Antiloop]

Any idea when?
not really

no details available yet at all

but they dropped something about first quarter of 2005
but we'll see.. things can go fast sometimes..

[petgun]

hi,
...I have a strange problem...my disk values:


Model=TOSHIBA MK6021GAS, FwRev=GA024A, SerialNo=14HA5387S
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=46
BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117210240
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: device does not report version:

* signifies the current active mode

compared to your values I wonder about my 'BuffSize' ? you have 8192kb..I know that my Toshiba has a 2048kb but the WL-HDD don't see it....so my write performance is very bad :-(
..a little chart...red line is writing to wlhdd....green is a DBox recording..:-(
http://petgun.g4.gs/chart1.gif

any idea?

cu,
peter