Printable View
But very interesting :cool:Quote:
Originally Posted by 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. 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.
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.Quote:
Originally Posted by Styno
NFS uses udp, kernel space nfs does not perform mem copy at all.Quote:
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.
Well, tftp is really limited and all implementations are running in the user space.Quote:
Using a TFTP server might speed up the transferrate a bit in that case.
Also, routing is running at the same 3.5 MB speed (no copy, kernel space only).
Ok, I stay out of this discussion :)
Look at this. My drive is in UDMA2 mode, which is default firmware setting.Quote:
Originally Posted by Oleg
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
Bummer. Getting more speed using hdparam would be simple and quick. Ethernet tweaking will be much more difficult I guess.
Right, it's already at udma2...Quote:
Originally Posted by JOCKYW2001
We need to focus at CPU overclocking. ;-)Quote:
Perhaps the focus should be on the ethernet driver?
In fact, have you tried ttcp with transfering large file via udp?
..........
NOFI:Quote:
Originally Posted by Whissi
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..
..........
Below are ttcp performance tests for the WL-HDD:Quote:
Originally Posted by Oleg
(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.
You mean tweak etc47xx.c here ?Quote:
Originally Posted by Oleg
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);
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.Quote:
Originally Posted by JOCKYW2001
There is no way to change CPU speed.
Asus wouldn't be Asus if there isn't anything left to overclock :DQuote:
Originally Posted by Oleg
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?
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.Quote:
Originally Posted by JOCKYW2001
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)
{
...
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?
[admin@WLHDD /tmp]$ ./hdparm -T /dev/discs/disc0/discQuote:
Originally Posted by hugo
/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
Any idea when?Quote:
Originally Posted by Antiloop
not reallyQuote:
Originally Posted by brubber
no details available yet at all
but they dropped something about first quarter of 2005
but we'll see.. things can go fast sometimes..
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 :-(Quote:
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..:-(
http://petgun.g4.gs/chart1.gif
any idea?
cu,
peter