Hi all,
not much to say about, just read. All are vanilla kernels w/o any patch.
/dev/hda5 on /home type ext3 (rw,data=ordered)
/dev/hda5 10080488 731488 8836932 8% /home
UDMA100 IDE Drive, DMA is on. All these runs were done right after bootup.
Mashine is a Celeron 1,3GHz, 512MB RAM, 512MB SWAP.
root@codeman:[/] # uname -r
2.4.18
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 119.140681 seconds (18024772 bytes/sec)
root@codeman:[/] #
root@codeman:[/] # uname -r
2.4.19
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 140.305836 seconds (15305733 bytes/sec)
root@codeman:[/] # uname -r
2.4.20
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 172.327570 seconds (12461637 bytes/sec)
root@codeman:[/] # uname -r
2.4.21-pre2
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 177.743959 seconds (12081894 bytes/sec)
ciao, Marc
On Sunday 22 December 2002 14:47, Marc-Christian Petersen wrote:
Hi again,
> root@codeman:[/] # uname -r
> 2.4.20
> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
> 131072+0 records in
> 131072+0 records out
> 2147483648 bytes transferred in 172.327570 seconds (12461637 bytes/sec)
root@codeman:[/] # uname -r
2.4.20-rmap15b
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 140.460427 seconds (15288887 bytes/sec)
ciao, Marc
On Sunday 22 December 2002 15:38, Marc-Christian Petersen wrote:
And hi again ^3,
> root@codeman:[/] # uname -r
> 2.4.20-rmap15b
> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
> 131072+0 records in
> 131072+0 records out
> 2147483648 bytes transferred in 140.460427 seconds (15288887 bytes/sec)
root@codeman:[/] # uname -r
2.4.20aa1
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 286.054011 seconds (7507266 bytes/sec)
ciao, Marc
On 2002.12.22 Marc-Christian Petersen wrote:
>On Sunday 22 December 2002 15:38, Marc-Christian Petersen wrote:
>
>And hi again ^3,
>
>> root@codeman:[/] # uname -r
>> 2.4.20-rmap15b
>> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
>> 131072+0 records in
>> 131072+0 records out
>> 2147483648 bytes transferred in 140.460427 seconds (15288887 bytes/sec)
>
>root@codeman:[/] # uname -r
>2.4.20aa1
>root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072
>131072+0 records in
>131072+0 records out
>2147483648 bytes transferred in 286.054011 seconds (7507266 bytes/sec)
>
Check you timer...
werewolf:~> uname -a
Linux werewolf.able.es 2.4.20-jam2 #2 SMP vie dic 20 22:35:33 CET 2002 i686 unknown unknown GNU/Linux
werewolf:~> time dd if=/dev/zero of=kk bs=16384 count=131072
131072+0 records in
131072+0 records out
0.51user 60.63system 1:23.73elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (133major+15minor)pagefaults 0swaps
Box is a dual PII@400, 950Mb of RAM. FS is ext3.
So about 83 seconds on -jam2, which is mainly just 2.4.20aa1 with ext3 fixes.
Ah, no special options to ext3 mount (no data=ordered). That's the point ?
???
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.20-jam2 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-2mdk))
On Sunday 22 December 2002 23:21, J.A. Magallon wrote:
Hi J.A.
> On 2002.12.22 Marc-Christian Petersen wrote:
> >On Sunday 22 December 2002 15:38, Marc-Christian Petersen wrote:
> >
> >And hi again ^3,
> >
> >> root@codeman:[/] # uname -r
> >> 2.4.20-rmap15b
> >> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
> >> count=131072 131072+0 records in
> >> 131072+0 records out
> >> 2147483648 bytes transferred in 140.460427 seconds (15288887 bytes/sec)
> >
> >root@codeman:[/] # uname -r
> >2.4.20aa1
> >root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
> > count=131072 131072+0 records in
> >131072+0 records out
> >2147483648 bytes transferred in 286.054011 seconds (7507266 bytes/sec)
>
> Check you timer...
the timer is right.
> Box is a dual PII@400, 950Mb of RAM. FS is ext3.
> So about 83 seconds on -jam2, which is mainly just 2.4.20aa1 with ext3
> fixes. Ah, no special options to ext3 mount (no data=ordered). That's the
> point ?
nono, ordered is default if nothing is specified.
Seems it makes a big difference with DUAL and 1GB RAM. Now with Dual P3 1GHz,
1GB RAM, ext3 ordered mode:
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
131072+0 records in
131072+0 records out
2147483648 bytes transferred in 55.741130 seconds (38526016 bytes/sec)
Anyway, the comparison to the different kernels shows up again a better
throughput than with -aa. That is pretty obvious because of the lowlatency
elevator in -aa. But that's not the point. The point is that with
every new kernel release the performance drops. So it shows by dd. Not to
mention the pauses/stops grow up with every new release. It cannot be true
that compared 2.4.18 to 2.4.20 there is a 6mb/s performance loss.
What the hell we can get with $MONSTER-BOX w/o the performance issues ;)
Anyway, that dd call with those options is pretty expensive to mem_load.
I wonder why this doesn't affect contest [tm]. Or am I blind?
ciao, Marc
> 2.4.18
> 2147483648 bytes transferred in 119.140681 seconds (18024772 bytes/sec)
>
> 2.4.19
> 2147483648 bytes transferred in 140.305836 seconds (15305733 bytes/sec)
Well I'm getting the numbers the other way round. <g>
Machine:
$ egrep 'model name|MHz' /proc/cpuinfo
model name : AMD Athlon(tm) processor
cpu MHz : 996.037
$ grep MemTotal /proc/meminfo
MemTotal: 516588 kB
$ egrep 'Bridge|DMA rate' /proc/ide/via
South Bridge: VIA vt82c686b
Highest DMA rate: UDMA100
$ cat /proc/ide/ide0/hda/model
ST380021A
$ su -c 'hdparm -Iv /dev/hda| grep -i dma'
using_dma = 1 (on)
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5
$ grep [[:blank:]]/[[:blank:]] /etc/fstab
/dev/hda3 / reiserfs defaults 1 1
Tests:
$ uname -r
2.4.18
$ time sh -c 'sync; sync; sync; dd if=/dev/zero of=hoax bs=16k count=131072; sync; sync; sync'
131072+0 records in
131072+0 records out
real 1m44.708s
user 0m0.140s
sys 0m20.340s
=> 19.56MB/s
$ uname -r
2.4.20
$ time sh -c 'sync; sync; sync; dd if=/dev/zero of=hoax bs=16k count=131072; sync; sync; sync'
131072+0 records in
131072+0 records out
real 1m27.980s
user 0m0.120s
sys 0m20.290s
=> 23.28MB/s
I also tried machines with disks connected to various SCSI controllers
and in all cases more recent kernels gave better results than older
ones (sym53c8xx: two-disk raid1 - 2.4.18: ~35MB/s, 2.4.20: ~40MB/s).
I'm using reiserfs 3.6 everywhere.
--
Tomas Szepe <[email protected]>
hi
What disk/controller is this?
On Sunday, December 22, 2002, at 02:47 PM, Marc-Christian Petersen
wrote:
> Hi all,
>
> not much to say about, just read. All are vanilla kernels w/o any
> patch.
>
> /dev/hda5 on /home type ext3 (rw,data=ordered)
> /dev/hda5 10080488 731488 8836932 8% /home
>
> UDMA100 IDE Drive, DMA is on. All these runs were done right after
> bootup.
> Mashine is a Celeron 1,3GHz, 512MB RAM, 512MB SWAP.
>
> root@codeman:[/] # uname -r
> 2.4.18
> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
> count=131072
> 131072+0 records in
> 131072+0 records out
> 2147483648 bytes transferred in 119.140681 seconds (18024772 bytes/sec)
> root@codeman:[/] #
>
> root@codeman:[/] # uname -r
> 2.4.19
> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
> count=131072
> 131072+0 records in
> 131072+0 records out
> 2147483648 bytes transferred in 140.305836 seconds (15305733 bytes/sec)
>
> root@codeman:[/] # uname -r
> 2.4.20
> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
> count=131072
> 131072+0 records in
> 131072+0 records out
> 2147483648 bytes transferred in 172.327570 seconds (12461637 bytes/sec)
>
> root@codeman:[/] # uname -r
> 2.4.21-pre2
> root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384
> count=131072
> 131072+0 records in
> 131072+0 records out
> 2147483648 bytes transferred in 177.743959 seconds (12081894 bytes/sec)
>
>
> ciao, Marc
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Monday 23 December 2002 13:03, Tomas Szepe wrote:
Hi Tomas,
> > 2.4.18
> > 2147483648 bytes transferred in 119.140681 seconds (18024772 bytes/sec)
> >
> > 2.4.19
> > 2147483648 bytes transferred in 140.305836 seconds (15305733 bytes/sec)
>
> Well I'm getting the numbers the other way round. <g>
lol, strange.
root@codeman:[/] # egrep 'model name|MHz' /proc/cpuinfo
model name : Intel(R) Celeron(TM) CPU 1300MHz
cpu MHz : 1295.718
root@codeman:[/] # grep MemTotal /proc/meminfo
MemTotal: 515056 kB
root@codeman:[/proc/ide] # egrep 'Intel|UDMA enabled' /proc/ide/piix
Intel PIIX4 Ultra 100 Chipset.
UDMA enabled: yes no no no
UDMA enabled: 5 X X X
root@codeman:[/] # hdparm -i /dev/hda
/dev/hda:
Model=MAXTOR 6L060J3, FwRev=A93.0500, SerialNo=663219752652
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16
CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=117266688
IORDY=on/off, tPIO={min:120,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 udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 1 2 3 4 5
ciao, Marc