Right, it's already at udma2...Originally Posted by JOCKYW2001
We need to focus at CPU overclocking. ;-)Perhaps the focus should be on the ethernet driver?
In fact, have you tried ttcp with transfering large file via udp?
Moderator & Financial forum supporter :)
Bummer. Getting more speed using hdparam would be simple and quick. Ethernet tweaking will be much more difficult I guess.
Administrator
Right, it's already at udma2...
We need to focus at CPU overclocking. ;-)Perhaps the focus should be on the ethernet driver?
In fact, have you tried ttcp with transfering large file via udp?
Junior Member
..........
Last edited by Whissi; 28-12-2006 at 22:54.
Administrator
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..
My little Asus Collection: Too much to fit inhere, my 2 babies:WL500w 1.9.2.7-10(OLEG) VX2SE Yellow Lamborghini notebook
WL500g Forum Asus Files OpenDir
Asusforum.NL -- Asusforum.DE -- Asusforum.RU -- Asusforum.PL -- Asusforum.NET -- Asusforum.EU -- Asusforum.BE -- Asusforum.ES -- Asusforum.INFO
Junior Member
..........
Last edited by Whissi; 28-12-2006 at 22:54.
Senior Member
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):
transferring firmware image (wait cycles are added by slow flash)Code:# 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.
Code:# 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)
Code:# 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)
Code:# 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.
Senior Member
You mean tweak etc47xx.c here ?
e.g. 0x9A instead of 0x99 ?Code:/* * 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(®s->mdiocontrol, 0x94); if (ch->etc->deviceid == BCM47XX_ENET_ID) { /* 4710A0 has a 100Mhz SB clock and external phy */ W_REG(®s->mdiocontrol, 0x94); } else if (ch->etc->deviceid == BCM4402_ENET_ID) { /* 4402 has 62.5Mhz SB clock and internal phy */ W_REG(®s->mdiocontrol, 0x8d); } else if (ch->etc->deviceid == BCM4310_ENET_ID) { /* 4310 has a 124.8Mhz SB clock and external phy */ W_REG(®s->mdiocontrol, 0x99); } else if (ch->etc->deviceid == BCM4307_ENET_ID) { /* 4307 has 88 MHz SB clock and external phy */ W_REG(®s->mdiocontrol, 0x92);
Administrator
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.
Senior Member
Asus wouldn't be Asus if there isn't anything left to overclock
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?
Senior Member
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.
Code:/* * 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) { ...
Senior Member
looking at my klogd output, I found the following info:
Code: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
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?Code:[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
What do you think?
Administrator
[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
My little Asus Collection: Too much to fit inhere, my 2 babies:WL500w 1.9.2.7-10(OLEG) VX2SE Yellow Lamborghini notebook
WL500g Forum Asus Files OpenDir
Asusforum.NL -- Asusforum.DE -- Asusforum.RU -- Asusforum.PL -- Asusforum.NET -- Asusforum.EU -- Asusforum.BE -- Asusforum.ES -- Asusforum.INFO
Financial forum supporters :)
Any idea when?
Brubber
WL-500g, WL-138g, WL-160g
Administrator
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..
My little Asus Collection: Too much to fit inhere, my 2 babies:WL500w 1.9.2.7-10(OLEG) VX2SE Yellow Lamborghini notebook
WL500g Forum Asus Files OpenDir
Asusforum.NL -- Asusforum.DE -- Asusforum.RU -- Asusforum.PL -- Asusforum.NET -- Asusforum.EU -- Asusforum.BE -- Asusforum.ES -- Asusforum.INFO
Financial forum supporters :)
hi,
...I have a strange problem...my disk values:
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 :-(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
..a little chart...red line is writing to wlhdd....green is a DBox recording..:-(
any idea?
cu,
peter
Last edited by petgun; 13-12-2004 at 14:57.
Posting Permissions