# [hdparm ?] 2.4.26 -> 2.6.7  -20 Mo/s (?!) [resolu]

## Angelion

J'ai voulu passer une de mes machines sous linux 2.6.7, avant elle etait sous un 2.4.26, je config, compile , comme d'hab, pas de pbm, ca boot, nikel, puis vient le fameux test de hdparm , je lance, resultat: 35 Mo/s.

Tiens, ca parait peu pour un seagate 7200.7 sur une KT7-Raid (controlleur Raid HPT 370), je reboot sur le 2.4.26, et là 55 Mo/s.

Du coup j'ouvre les config des 2 kernels, qui sont tres minimalistes, et je ne trouve aucune difference dans la section driver.

Une idée ? (autre que activer le DMA et autres   :Wink:   )

2.4.26

```

hdparm -tTdi /dev/hdh

/dev/hdh:

 using_dma    =  1 (on)

 Model=ST380011A, FwRev=3.16, SerialNo=3JV8PFNW

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=156250000

 IORDY=on/off, 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=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

 * signifies the current active mode

 Timing buffer-cache reads:   464 MB in  2.00 seconds = 232.00 MB/sec

 Timing buffered disk reads:  166 MB in  3.00 seconds =  55.33 MB/sec

```

2.6.7

```
hdparm -tTdi /dev/hdh

/dev/hdh:

 using_dma    =  1 (on)

 Model=ST380011A, FwRev=3.16, SerialNo=3JV8PFNW

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=156250000

 IORDY=on/off, 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=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

 * signifies the current active mode

 Timing buffer-cache reads:   456 MB in  2.01 seconds = 227.13 MB/sec

 Timing buffered disk reads:  106 MB in  3.02 seconds =  35.07 MB/sec

```

Last edited by Angelion on Wed Jun 23, 2004 10:11 am; edited 2 times in total

----------

## DuF

Perso j'avais pas fait gaffe et j'ai pas de noyau 2.4 pour tester là, mais ce que tu dis m'inquiètes car qd je teste mon disque WD80Gb 7200 j'obtiens : 

```
 Timing buffer-cache reads:   1072 MB in  2.00 seconds = 534.74 MB/sec

 Timing buffered disk reads:  100 MB in  3.04 seconds =  32.93 MB/sec

```

Je me dis que ça se trouve je suis comme toi !

----------

## scout

hum, mis à part le dma, le mode 32 bits est il activé et le readahead est il suffisament important ?

----------

## Angelion

oui oui, c les meme options dans les 2 cas.

[EDIT]

Je viens de tester avec knoppix 3.4, si je boot en 2.4 (knoppix) ou 2.6 (knoppix26), idem, je perd 20 Mo/s

[/EDIT]Last edited by Angelion on Mon Jun 21, 2004 3:24 pm; edited 1 time in total

----------

## DuF

Perso j'ai 

```
genduf root # hdparm -cd /dev/hda

/dev/hda:

 IO_support   =  1 (32-bit)

 using_dma    =  1 (on)

```

Le readahead ça se voit comment ?

----------

## yoyo

 *DuF wrote:*   

> Le readahead ça se voit comment ?

 

Simplement par "hdparm /dev/hdx" ...

----------

## DuF

Merci, comme un boulet depuis tout à l'heure je tape les options une par une et je cherchai le mode qui affichait toutes les infos basiques comme je faisais avant, mais dont je ne me souvenais plus et dont je ne trouvai pas la commande dans l'aide... la prochaine fois je réfléchirai  :Wink: 

Bon beh sinon j'ai : 

```
 readahead    = 256 (on)

```

----------

## Angelion

J'ai beau activer/desactiver ce dont je n'etais pas sur a 100% ds le 2.6, rien n'y fait.

Les resultats sont obtenus sans que je touche a hdparm.

[EDIT]

On est pas les seuls DuF: https://forums.gentoo.org/viewtopic.php?t=133756

Et là un post d'une personne ayant les meme "doutes" que moi:

https://forums.gentoo.org/viewtopic.php?t=134916

[/EDIT]

----------

## Sleeper

Je me disais bine que j'avais lu qq chose dans ce gout la :

http://kerneltrap.org/node?from=27

J'ai pas essaye le patch ...

----------

## DuF

Je ne suis pas sûr d'avoir tout compris, mais d'après certains le scheduler aurait un impact non négligeable, problème j'utilise le noyau ck-sources 2.6.7 donc logiquement j'ai déjà le scheduler qu'ils conseillent......

[EDIT]

J'ai testé en passant le paramètre elevator=cfq au noyau pour utiliser l' IO cfq scheduler, c'est pas mieux, limite un peu moins bien.

[/EDIT]

----------

## CryoGen

erf , j'ai jms été testé sous 2.4 seulement en testant apres avoir lu votre post

Timing buffer-cache reads:   1180 MB in  2.00 seconds = 588.91 MB/sec

 Timing buffered disk reads:  120 MB in  3.03 seconds =  39.65 MB/sec

Bref le meme genre de valeur   :Crying or Very sad: 

noyau 2.6.5-mm6

une quinzaine de Mo de transfert en plus , c'est toujours bon à prendre  :Smile:  va falloir que je surveille ca lol ...mais là il se fait tard   :Arrow:   :Arrow:   :Arrow:  on verra ca demain.. enfin tout à l'heure  :Very Happy: 

----------

## guilc

Pour ton 2.6.5-mm6, je pense que c'est une limite de ton dur. (D'ailleurs, j'ai aussi un dur qui donne ce débit, un seagate, et poru un seagate, c un débit totu a fait normal)...

Avec le 2.6.5-mm6 et 2.6.6-mm5 (mon noyau actuel), j'ai de très bonnes performances (et avec toute la série des mm d'ailleurs) :

 Timing buffer-cache reads:   2708 MB in  2.00 seconds = 1352.85 MB/sec

 Timing buffered disk reads:  162 MB in  3.00 seconds =  54.99 MB/sec

Je pense que d'ailleurs, pour ce qui ont ce probleme, vous devriez tester le kernel mm  :Smile: 

----------

## Sleeper

 *guilc wrote:*   

> 
> 
> Je pense que d'ailleurs, pour ce qui ont ce probleme, vous devriez tester le kernel mm 

 

Le seul pb des mm c'est qu'ils ne sont pas tj hyper-stables .. ma carte wifi refusait de marchait avec un 2.6.6-mm1 (ou mm2 je me rappelle plus bien) , mais marchait nickel-chrome avec un 2.6.6 vanilla ..

----------

## Angelion

En effet, moi aussi j'ai eu des pbm avec les mm.

Pour ce qui est du scheduler, j'ai testé les 4 qui sont dans le kernel.

@DuF: Pas besoin de passer elevator en parametre, suffit de choisir cfq dans la config.

Aller hop, c parti, test des differents patchs.

----------

## Angelion

Arf, le patch est déjà intégré au 2.6.7 , donc ca change rien pour moi.

----------

## Angelion

De mieux en mieux, avec les mm je suis à 17 Mo/s, avec le dma activé et le mode 32 bit, et mon framebuffer scintille comme jamais ...

----------

## Angelion

Les ck, c pas mieux.

De toute facon, j'ai l'impression qu'un 2.6 n'est jamais plus rapide en lecture disk qu'un 2.4, cf ici

De facon globale je ressens presque un ralentissement de mon systeme avec un 2.6, en tout cas, aucun gain.

En parcourant le net et en discutant avec pas mal de gens je me rend compte que je ne suis pas le seul.

----------

## Gentoo_Lover

 *Angelion wrote:*   

> Les ck, c pas mieux.
> 
> De toute facon, j'ai l'impression qu'un 2.6 n'est jamais plus rapide en lecture disk qu'un 2.4, cf ici
> 
> De facon globale je ressens presque un ralentissement de mon systeme avec un 2.6, en tout cas, aucun gain.
> ...

 

hé bien pas trop d'accord regarde mon résultat de hdparm avec 32 bits ultra-dma5 , HDPARM-2.6.5

----------

## Angelion

J'ai jamais dit que ct general, heuresement !

Mais juste comme ca, essaye avec un 2.4.26.

----------

## Gentoo_Lover

 *Angelion wrote:*   

> J'ai jamais dit que ct general, heuresement !
> 
> Mais juste comme ca, essaye avec un 2.4.26.

 

ensuite oui sur certain point peut etre que les 2.4.x sont mieux car ils sont plus léger (moins de modules......etc) alors que les 2.6x sont plus lourds cela dépend ensuite des machines !

vois tu un intérer à ce que j'essais un 2.4.26 ? cela va t-il changer beaucoup ?

(au niveau de l'hdparm par exemple ?)

----------

## Angelion

 *Quote:*   

> ensuite oui sur certain point peut etre que les 2.4.x sont mieux car ils sont plus léger (moins de modules......etc) alors que les 2.6x sont plus lourds cela dépend ensuite des machines ! 

 

 :Question:   :Exclamation:   :Question:   :Exclamation: 

Un kernel de 2 Mo n'a jamais été plus "lent" qu'un de 1MoLast edited by Angelion on Tue Jun 22, 2004 9:22 am; edited 1 time in total

----------

## Gentoo_Lover

oui enfin c'est ce que j'ai lus sur un site , alors c'est peut être pas vrai !  :Laughing: 

mais par exemple j'ai entendu dire qu'il y avait du lague en Frammebuffer sous les 2.4 qu'il n'y a pas sur les 2.6 (ca c'est vrai je l'ai constaté moi même quand j'étais en 2.4.25 )

----------

## Angelion

 *Gentoo_Lover wrote:*   

> oui enfin c'est ce que j'ai lus sur un site , alors c'est peut être pas vrai ! 
> 
> mais par exemple j'ai entendu dire qu'il y avait du lague en Frammebuffer sous les 2.4 qu'il n'y a pas sur les 2.6 (ca c'est vrai je l'ai constaté moi même quand j'étais en 2.4.25 )

 

Bah ecoute, peut etre avec cet affreux driver VESA, mais moi je n'ai jamais eu de "lag" en fb avec le driver radeon

Regarde les chiffres du site que j'ai donné, j'ai pas inventé les resultats.

----------

## DuF

De toute façon après faut pas non plus écouter la légende urbaine, faut rester crédible un minimum et ne pas colporter des trucs invérifiés. Toujours est-il que pour le moment Angelion a qd même un gros souci entre un 2.4 et un 2.6 sans que cela ne soit expliqué ni qu'il y ait une explication...

----------

## Angelion

Tu peux essayer avec un 2.4.26 DuF ?

----------

## zdra

 *Angelion wrote:*   

> Un kernel de 2 Mo n'a jamais été plus "lent" qu'un de 1Mo

 

Biensure ! En général c'est le gros compromis souvent trollesque entre l'optimisation de code et la taille de l'executable. Car en optimisant le code avec les option -O3 de gcc par exemple tu obtient un code plus gros mais plus rapide théoriquement... Mais ce n'est pas toujours le cas car il faut compter sur la cache du processeur ! un code plus petit peut rentrer plus facilement en cache et donc prendre moins de temps en IO et donc s'executer plus vite qu'un code plus optimisé mais pus gros.

----------

## Angelion

Mais de koi tu parles ?

Tu vas me dire que tu modifies le CFLAGS du noyau aussi ?

Note: si les reponses a ce thread pouvaient concerner mon pbm, merci

----------

## guiguidoc

en 2.6.7-r3

/dev/hda:

 Timing buffer-cache reads:   1664 MB in  2.00 seconds = 830.88 MB/sec

 Timing buffered disk reads:  134 MB in  3.03 seconds =  44.27 MB/sec

/dev/hdi:

 Timing buffer-cache reads:   1676 MB in  2.00 seconds = 836.04 MB/sec

 Timing buffered disk reads:  162 MB in  3.01 seconds =  53.90 MB/sec

/dev/hdb:

 Timing buffer-cache reads:   1708 MB in  2.00 seconds = 852.00 MB/sec

 Timing buffered disk reads:  156 MB in  3.02 seconds =  51.65 MB/sec

----------

## DuF

 *Angelion wrote:*   

> Tu peux essayer avec un 2.4.26 DuF ?

 

ALors j'ai repris des vieux noyaux 2.4 que j'avais, ça va d'un 2.4.20 gaming-sources à un 2.4.25 gentoo en passant par divers autres noyaux, juste en bootant dessus et en tapant la commande de test, je varie entre 22MB/sec  et 37MB/sec. 

Il n'y a que sur les 2.6 où j'ai pratiquement aucune variation, les valeurs restant à une moyenne de 30MB/sec.

Même si l'écart en moins grave que toi, j'aimerai bien connaître ce qui pourrai autant influer sur ces valeurs, cela me laisse perplexe dans l'immédiat car à chaque fois dma et mode 32 bits sont actifs.

----------

## yoyo

Je vais peut-être dire une bêtise (et ça ne sera probablement pas la dernière) mais j'ai souvenir d'un thread dans lequel quelqu'un disait que les tests hdparm n'étaient pas fiables sur un système monté (ou plutôt utilisé).

C'est-à-dire que faire le test hdparm en même temps qu'un emerge sync vous amène à des valeurs minables ...

Dans le même ordre d'idée, il est possible que la série des 2.6 sollicite d'avantage le disque dur (gestion de swap différente par exemple) et donc ferait chuter les tests hdparm.

Avez-vous fait vos tests avec un liveCD basé sur un noyau 2.6 ???

----------

## DuF

Euh nop, perso j'ai pas de liveCD sous la main et j'ai qu'un disque donc cela peut expliqué ceci... mais il y a quand même un delta suivant les noyaux dans les mêmes conditions de tests.

----------

## yoyo

 *DuF wrote:*   

> Euh nop, perso j'ai pas de liveCD sous la main et j'ai qu'un disque donc cela peut expliqué ceci...

 Pas de LiveCD ?! Même pas une knoppix ??? Au fou !!!

J'ai dépanné un collègue sous win avec hier : recupération des données (grâce au LiveCD et à samba) avant formatage imposé par un plantage windows ... Il en est toujours pas revenu (et ce n'est pas le seul ...) d'avoir pu récupérer son travail aussi rapidement !!! Ça fait de la super pub pour Linux et ça c'est cool ...   :Cool: 

 *DuF wrote:*   

> mais il y a quand même un delta suivant les noyaux dans les mêmes conditions de tests.

 Et cela peut peut-être venir d'une gestion différente de pages de swap (par exemple) !?

----------

## Angelion

La swap ? avec hdparm ? pas du tout (d'ailleurs meme sans swap les reulstats sont les meme)

Il est a signaler que chaque tests est effectué alors que la machine n'est pas 'chargée', je ne v evidement pas faire un emerge sync pdt le test ...

Et pour ceux qui en voudrait a hdparm,  meme un cp sur mon mon autre dur donne des valeurs bien differentes entre un 2.6 et un 2.4

----------

## yoyo

 *Angelion wrote:*   

> La swap ? avec hdparm ? pas du tout (d'ailleurs meme sans swap les reulstats sont les meme)

 

Non, ce que je voulais dire c'est que si ton noyau demande un accès à la swap (ou tout autre accès au disque) pendant le test hdparm, cela risque de le fausser ...

Je pense que le résultat est le même avec le cp. Tes fichier sont mis en mémoire avant d'être copiés. Et selon la méthode de gestion de ta mémoire, tu peux ou non envoyer une partie de tes données en swap, ce qui ralenti ton cp (elles sont copiées 2 fois).

À noter que je ne crois que très moyennement à ce que j'avance : 20Mo/s de différence ça me paraît énorme pour ça ... c'est simplement une piste de réflexion.

----------

## DuF

Perso quand je fais le test hdparm je viens juste de booter le noyau et je suis en console, rien lancé d'autres, etc... donc bon. A la limite je veux bien accepter que cela vient d'un paramêtre du noyau ou autre, mais lequel, que me vaut un tel delta (même si moi c'est inférieur à Angelion, j'ai environ 15%) d'un noyau à l'autre, j'aimerai bien maîtriser ce phénomène.

Sinon non je n'ai pas de knoppix, j'ai pas de windows à réparer  :Smile: 

Ma gentoo tient bon, je dois faire une installation tous les 2 ans, quand je change un périphérique trop important et encore...  :Smile: 

Et de toute façon maintenant j'ai décidé que je n'aidais plus personne qui était sous windows donc comme ça c'est rêglé  :Smile: 

----------

## Angelion

Au fait, c'est quoi ton chipset ?

D'ailleurs ca serait bien de poster sa config pour ceux qui veulent mettre leurs resultats.

Pour ma part c un duron 750 sur Abit KT7 Raid, chipset Via KT133.

----------

## DuF

Athlon XP200+, Abit NF7, chipset nforce2, 512ram PC3200 et 

```
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA

hda: WDC WD800BB-32CCB0, ATA DISK drive

hda: max request size: 128KiB

hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)

```

----------

## zarasoustra17

Ca serait pas un probleme dans le module ide ?, parce que moi avec un Seagate Barracuda 7200 ide et un chipset nforce2 avec 512 Mo, j'obtiens:

```

Linux toutoune.org 2.6.7-rc2-mm2 #3 Sun Jun 6 23:05:08 CEST 2004 i686 AMD Athlon(tm) XP 2500+ AuthenticAMD GNU/Linux

/dev/hdb:

 using_dma    =  1 (on)

 Model=ST3120026A, FwRev=3.06, SerialNo=3JT1ND8B

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648

 IORDY=on/off, 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=no WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 2:

 * signifies the current active mode

 Timing buffer-cache reads:   1628 MB in  2.00 seconds = 814.12 MB/sec

 Timing buffered disk reads:  168 MB in  3.01 seconds =  55.79 MB/sec

```

J'ai pas testé sous 2.4 car je suis sous nptl, bootsplash, udev....et je crains que mon install n'aprécie guère ce brusque retour apres un an de 2.6...

----------

## DuF

Je vais tester en changeant la configuration IDE je verrai bien.

D'ailleurs quand je boot j'ai : 

```
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

NFORCE2: not 100% native mode: will probe irqs later

NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround.

NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller

hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)

```

La première ligne surtout, pas sûr de bien la comprendre, logiquement je devrais être en 100MHz non vu que mon disque est en UDMA100 et que le chipset supporte le 133 ?

[EDIT]Bon c'est la vitesse du bus donc logiquement ça parait normal[/EDIT]

J'ajouterai : 

```
genduf root # cat /proc/ide/amd74xx 

----------AMD BusMastering IDE Configuration----------------

Driver Version:                     2.13

South Bridge:                       0000:00:09.0

Revision:                           IDE 0xa2

Highest DMA rate:                   UDMA133

BM-DMA base:                        0xf000

PCI clock:                          33.3MHz

-----------------------Primary IDE-------Secondary IDE------

Prefetch Buffer:              yes                 yes

Post Write Buffer:            yes                 yes

Enabled:                      yes                 yes

Simplex only:                  no                  no

Cable Type:                   80w                 40w

-------------------drive0----drive1----drive2----drive3-----

Transfer Mode:       UDMA       DMA       DMA       DMA

Address Setup:       30ns      90ns      30ns      90ns

Cmd Active:          90ns      90ns      90ns      90ns

Cmd Recovery:        30ns      30ns      30ns      30ns

Data Active:         90ns     330ns      90ns     330ns

Data Recovery:       30ns     270ns      30ns     270ns

Cycle Time:          20ns     600ns     120ns     600ns

Transfer Rate:   99.9MB/s   3.3MB/s  16.6MB/s   3.3MB/s

```

Donc tout à l'air OK... sauf les perfs, je vais finir par retester le mm-sources  :Smile: 

----------

## Possum

Histoire d'apporter ma pierre à l'édifice des bordels à la con avec hdparm, voilà mes résultats et quelques infos sur ma config  :Smile: 

Commençons par le début, avec la config de hdparm tel qu'il se lance au démarrage:

```
roo@opossum root # cat /etc/conf.d/hdparm 

# Copyright 2003 Gentoo Technologies, Inc. 

# Distributed under the terms of the GNU General Public License, v2 or later

# $Header: /home/cvsroot/gentoo-x86/sys-apps/hdparm/files/hdparm-conf.d,v 1.1 2003/03/01 21:17:39 sethbc Exp $

# You can either set hdparm arguments for each drive using disc*_args and cdrom*_args..

# eg.

 disc0_args="-d1 -c1 -u1 -X100"

 disc1_args="-d1 -c1 -u1 -X100"

 cdrom0_args="-d1"

 cdrom1_args="-d1"

# Or, you can set hdparm options for ALL drives using all_args..

# eg.

# this mimics the behavior of the current script

# all_args="-d1"

```

Suivent les tests de mes deux disques:

```
root@opossum root # hdparm -tTdi /dev/hda

/dev/hda:

 using_dma    =  1 (on)

 Model=IC35L040AVER07-0, FwRev=ER4OA44A, SerialNo=SXPTXNQ1352

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40

 BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80418240

 IORDY=on/off, 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: disabled (255) WriteCache=enabled

 Drive conforms to: ATA/ATAPI-5 T13 1321D revision 1: 

 * signifies the current active mode

 Timing buffer-cache reads:   1080 MB in  2.00 seconds = 539.81 MB/sec

 Timing buffered disk reads:  114 MB in  3.01 seconds =  37.84 MB/sec

root@opossum root # hdparm -tTdi /dev/hdb

/dev/hdb:

 using_dma    =  1 (on)

 Model=HDS722580VLAT20, FwRev=V32OA60A, SerialNo=VNR21EC2R8A8SL

 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }

 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52

 BuffType=DualPortCache, BuffSize=1794kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160836480

 IORDY=on/off, 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: disabled (255) WriteCache=enabled

 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a: 

 * signifies the current active mode

 Timing buffer-cache reads:   1092 MB in  2.01 seconds = 544.45 MB/sec

 Timing buffered disk reads:  164 MB in  3.03 seconds =  54.19 MB/sec

```

Mettons les infos équivalentes à celles de DuF:

```
root@opossum root # cat /proc/ide/via 

----------VIA BusMastering IDE Configuration----------------

Driver Version:                     3.38

South Bridge:                       VIA vt8235

Revision:                           ISA 0x0 IDE 0x6

Highest DMA rate:                   UDMA133

BM-DMA base:                        0xe400

PCI clock:                          33.3MHz

Master Read  Cycle IRDY:            0ws

Master Write Cycle IRDY:            0ws

BM IDE Status Register Read Retry:  yes

Max DRDY Pulse Width:               No limit

-----------------------Primary IDE-------Secondary IDE------

Read DMA FIFO flush:          yes                 yes

End Sector FIFO flush:         no                  no

Prefetch Buffer:               no                  no

Post Write Buffer:             no                  no

Enabled:                      yes                 yes

Simplex only:                  no                  no

Cable Type:                   80w                 80w

-------------------drive0----drive1----drive2----drive3-----

Transfer Mode:       UDMA      UDMA      UDMA       DMA

Address Setup:      120ns     120ns     120ns     120ns

Cmd Active:          90ns      90ns      90ns      90ns

Cmd Recovery:        30ns      30ns      30ns      30ns

Data Active:         90ns      90ns      90ns      90ns

Data Recovery:       30ns      30ns      30ns      30ns

Cycle Time:          22ns      22ns      30ns     120ns

Transfer Rate:   88.8MB/s  88.8MB/s  66.6MB/s  16.6MB/s

```

Pour info, si mes souvenirs sont bon, mon premier disque est un IBM et le deuxième un Maxtor. Et j'ai la flemme d'ouvrir la machine pour vérifier. Et je tourne en ce moment avec un kernel 2.6.5-gentoo-r1 sur un AMD Athlon-XP 2400+ sur un chipset VIA KT400  :Wink:  En espérant que ça vous mette sur la piste  :Smile:  Et comme j'ai pas de kernel 2.4 sous la main, à part une knoppix (et oh, je vais pas rebooter mon nux hein)... Mais je crois me souvenir que j'avais des résultats sensiblement équivalents sous le 2.4.

Ceci dit, bonne chance les gars  :Smile: 

----------

## robinhood

ça pourrait être un problème de nappe, j'ai eu ce genre de problème dans une vie antérieure. ahem...

----------

## DuF

Pour le coup de la nappe pas vraiment possible vu que les résultats varient avec la même nappe.

@Possum :

Merci pour les infos, bon il ne reste qu'une chose à faire, prendre une knoppix et voir les résultats, s'ils sont bons c'est qu'il y a un truc qui fait que suivant le noyau, le dur où est installé le système a forcément des performances moins bonnes et cela est dépendant du noyau, pas très clair mais à tester  :Smile: 

----------

## yoyo

Mouais, il y a quand même quelque chose de pas très net dans les résultats de possum : 

 *Quote:*   

> disc0_args="-d1 -c1 -u1 -X100"
> 
> disc1_args="-d1 -c1 -u1 -X100"

 

 *Quote:*   

> hdparm -tTdi /dev/hda
> 
>  Timing buffer-cache reads:   1080 MB in  2.00 seconds = 539.81 MB/sec
> 
>  Timing buffered disk reads:  114 MB in  3.01 seconds =  37.84 MB/sec
> ...

 

Les 2 disques sont sur la même nappe, ont les mêmes paramètres hdparm (même mode udma etc.) et pourtant, il ont une différence de perf de 16Mo/s !!!

Je me demende si les test hdparm ne sont pas un peu "juste" : est-il possible de spécifier la quantité de données ou plutôt la durée du test ???

Un test plus long serait peut-être plus fiable (moins d'influence de la mise en rotation des plateaux et du positionnement des têtes ??) ...

----------

## Angelion

 *Quote:*   

> Les 2 disques sont sur la même nappe, ont les mêmes paramètres hdparm

 

... et sont 2 disques differents

Mais je crois reconnaitre un IBM DTLA 120GXP là non ?

Si oui, en effet, 35 Mo/s c pas bcp pour ce disque.

----------

## Thom N2h

Comme le dit yoyo faudrait essayer de faire un test plus long, parce que c vrai qu'il ne met pas longtemps pour effectuer le test. Vous pouvez essayer aussi avec piozone qui est ds le portage

----------

## Angelion

Comme je l'ai dit plus haut, pour ceux qui ne croient pas en hdparm (alors qu'il ny a aucune raison et que rien n'explique les differences) meme un copié   est plus long sur un 2.6.

Meme si des benchmarks me sortent pleins de chiffres peut etre equivalent je ne passerai pas en 2.6 sur une machine devant faire serveur de fichiers en perdant 20Mo/s en lecture.

----------

## yoyo

 *Angelion wrote:*   

>  *Quote:*   Les 2 disques sont sur la même nappe, ont les mêmes paramètres hdparm 
> 
> ... et sont 2 disques differents.

 

avec les mêmes paramètres udma (udma5) :

 *possum wrote:*   

> -------------------drive0----drive1
> 
> Transfer Mode:       UDMA      UDMA
> 
> Address Setup:      120ns     120ns
> ...

 

Je veux bien que deux disques différents aient des performances légèrement différentes, mais là on parle d'un écart de 30% !!!

@possum : quel utilisation fais-tu de tes deux disques (par ex, hda sert à ton "/") ???

EDIT : @Angelion, je suis tout à fait d'accord avec toi sur le fait de rester sur un 2.4 dans ce cas cependant, je testerai quand même un 2.6 quelques jours pour voir si à l'utilisation cette différence dans les tests se ressent en utilisation normale ...

EDIT 1 : cela n'explique toujours pas cette différence entre 2.4 et 2.6 ...   :Confused: 

----------

## Possum

Mon hda supporte: /boot , la swap, / et /home. sur hdb c'est uniquement du data, donc pas d'acces constants, juste quand j'encode et autres broutilles  :Smile: 

Alors, p'tet que l'écart vient du fait que ça soit mon disque "système", avec des accès plus nombreux..  Faudrait que je teste avec un live-cd, si y'a aucune utilisation du disque... alley, je m'y colle, je vous donne les résultats juste après  :Smile: 

----------

## Angelion

avec piozone, pareil, 20 Mo/s de difference.

----------

## Angelion

Tiens tiens http://kerneltrap.org/node/view/2786

[EDIT]

Avec hdparm -a 8192 je retrouve mes 55Mo/s

[/EDIT]Last edited by Angelion on Wed Jun 23, 2004 9:55 am; edited 1 time in total

----------

## Possum

Bon, voilà, 3 reboots après, voici les résultats.

J'ai utilisé le Live-CD Gentoo 2004.1 et j'ai testé avec le kernel 2.4 (gentoo) et le kernel 2.6 (smp). En sachant que y'a aucune optimisation particulière dans ces cas là.

kernel 2.4:

```
hdparm -tT /dev/hda

Timing buffer-cache reads: 1276 MB in 2.00 seconds = 638.00 MB/sec

Timing buffered disk reads: 118 MB in 3.04 seconds = 38.82 MB/sec

hdparm -tTdi /dev/hdb

Timing buffer-cache reads: 1236 MB in 2.00 seconds = 618.00 MB/sec

Timing buffered disk reads: 172 MB in 3.01 seconds = 57.14 MB/sec
```

kernel 2.6:

```
hdparm -tT /dev/hda

Timing buffer-cache reads: 1224 MB in 2.00 seconds = 611.48 MB/sec

Timing buffered disk reads: 116 MB in 3.01 seconds = 38.49 MB/sec

hdparm -tTdi /dev/hdb

Timing buffer-cache reads: 1200 MB in 2.00 seconds = 599.79 MB/sec

Timing buffered disk reads: 172 MB in 3.03 seconds = 56.76 MB/sec
```

Donc, y'a une légère différence, par rapport à mes précédents résultats en utilisation normale de la machine, je pense due au montage des filesystem. Par contre, il est clair qu'il y a une diff entre les perfs suivant les kernels, bien qu'elle paraissent minimes pour mon cas. Si qqun y comprend qqch  :Smile: 

Alley, je vais au taff  :Smile:  je verrais les résultats de tout ça ce soir :p

----------

## Angelion

Bon, avec /usr/bin/time j'ai regardé l'utilisation cpu pdt un hdparm -tT, en 2.6 avec readahead a 8 je suis a 23%, et à 30% avec un 2.4.26 (readahead 8 ) ou un 2.6.7 (readahead 8192) 

Donc, resolu.

----------

## omné

 *Angelion wrote:*   

> Bon, avec /usr/bin/time j'ai regardé l'utilisation cpu pdt un hdparm -tT, en 2.6 avec readahead a 8 je suis a 23%, et à 30% avec un 2.4.26 (readahead 8 ) ou un 2.6.7 (readahead 8192) 
> 
> Donc, resolu.

 

Je n'ai pas tt compris, tu aurais ne courage d'un petit résumé ?

De nous donner ton /etc/conf.d/hdparm ? Ou autre qui te paraisse necessaire ?

Moi, mes résultats sont nul, mais mes disques très plein.

----------

## fafounet

L´utilisation du CPU n´est pas la meme pendant les deux tests. On n´est donc pas dans les meme conditions, il est donc normal d´avoir une difference

----------

## Angelion

Si t'avais la reponse fafounet, fallit le dire des le debut, et pour rappel on a inventé de DMA pour eviter de surcharger le processeur.

Sur une bonne machine homogene en SCSI l'utilisation proc chute encore plus, pourtant avec debit superieur.

A l'inverse si ton driver n'est pas bon, ton utilisation monte à 100% pour des resultats deplorables, donc non l'utilisation cpu n'est pas proportionelle au debit des disques.

@omné: Au boot, hdparm n'est pas chargé (en tout cas chez moi), les perfs s'ameliorent nettement en changeant le paramettre readahead, c tout   :Wink: 

----------

## omné

 *Angelion wrote:*   

> 
> 
> @omné: Au boot, hdparm n'est pas chargé (en tout cas chez moi), les perfs s'ameliorent nettement en changeant le paramettre readahead, c tout  

 

Et comment s'assurer qu'il est bien chargé ?

Qq infos

Mon /etc/conf.d/hdparm

```
disc0_args="-d1 -A1 -m16 -u1 -a64"

disc1_args="-d1 -A1 -m16 -u1 -a64"

cdrom0_args="-d1 -a8 -u1"

cdrom1_args="-d1 -a8 -u1"

```

Mon noyau :

2.6.6-mm5

Le truc qui n'est pas bien du tout :

```
df -h                                         [13:40]

Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur

/dev/hdb3              72G   66G  3,0G  96% /

/dev/hdb2             464M   48M  392M  11% /boot

/dev/hda1              11G  7,9G  2,9G  73% /mnt/win

/dev/hda2              63G   55G  5,5G  91% /mnt/media
```

Mes perfs :

```
thalie/root-/etc/conf.d $ hdparm -tT /dev/hda                           [13:37]

                                                                                

/dev/hda:

 Timing buffer-cache reads:   848 MB in  2.00 seconds = 423.01 MB/sec

 Timing buffered disk reads:   74 MB in  3.02 seconds =  24.51 MB/sec

thalie/root-/etc/conf.d $ hdparm -tT /dev/hdb                           [13:38]

                                                                                

/dev/hdb:

 Timing buffer-cache reads:   840 MB in  2.00 seconds = 419.23 MB/sec

 Timing buffered disk reads:   84 MB in  3.06 seconds =  27.48 MB/sec

```

Merci...

----------

## Angelion

si t'as un /etc/conf.d/hdparm je presume que hdparm est lancé au boot, apres c a toi de jouer avec les parametres pour ameliorer les perfs.

----------

## fafounet

 *Angelion wrote:*   

> Si t'avais la reponse fafounet,

 

Non non j´ai juste traduit ce que tu avais poste comme l´avait demande ommne

----------

## DuF

Bon ce soir dès que je rentre je modifie le paramètre readahead pour tester, j'en profiterai pour vérifier quel est son influence sur les performances autre ce que sort l'hdparm.

----------

## Sleeper

 *Angelion wrote:*   

> si t'as un /etc/conf.d/hdparm je presume que hdparm est lancé au boot, apres c a toi de jouer avec les parametres pour ameliorer les perfs.

 

Nope pas forcement .. J'ai du faire un 

```
rc-update add hdparm boot
```

pour l'avoir ...

----------

## guilc

J'ai fait quelques petits tests rapides, le readahead a 4096 semble un peu plus rapide qu'a 8192 chez moi... D'ailleurs, 4096 est la valeur par défaut sur les 2.4...

----------

## DuF

Bon alors moi aussi je vais mettre 4096 car c'est à cette valeur que j'ai les meilleures performances et le temps CPU le plus faible grosso modo, disons que dans mon cas cela me semble être la meilleure solution.

Vite fait à titre d'exemple : 

```
genduf root # hdparm -a 4096 /dev/hda9

/dev/hda9:

 setting fs readahead to 4096

 readahead    = 4096 (on)

genduf root # time hdparm -Tt /dev/hda9

/dev/hda9:

 Timing buffer-cache reads:   1140 MB in  2.00 seconds = 568.95 MB/sec

 Timing buffered disk reads:  118 MB in  3.02 seconds =  39.13 MB/sec

real    0m13.118s

user    0m0.212s

sys     0m1.941s

genduf root # hdparm -a 8 /dev/hda9

/dev/hda9:

 setting fs readahead to 8

 readahead    =  8 (on)

genduf root # time hdparm -Tt /dev/hda9

/dev/hda9:

 Timing buffer-cache reads:   1096 MB in  2.00 seconds = 547.26 MB/sec

 Timing buffered disk reads:   40 MB in  3.01 seconds =  13.31 MB/sec

real    0m13.192s

user    0m0.217s

sys     0m1.862s

```

De toute façon cela n'a pas réellement de valeur, à part qu'une valeur de 8 est plutôt à proscrire  :Smile: 

----------

## Angelion

attention, ne pas confondre la meta fonction time de bash et le programme time (/usr/bin/time)

----------

## DuF

J'aurai du préciser que la fonction time que j'utilise n'a pas de lien avec le temps CPU occupé, logiquement ça se comprend vu les valeurs données, mais bon tu fais bien de le préciser pour que personne ne se méprenne.

Moi j'ai utilisé time juste pour m'assurer que le temps d'exécution était similaire (histoire de voir qu'il n'y a pas un loup ailleurs).

----------

## herlock

Bonjour,

j'ai fait les mêmes testes que vous, à savoir le readahead mis à 4096 et 8192.

4096 me donne les meilleurs résultats.

Cependant, je voudrais bien savoir exactement ce qu'est readahead. J'ai bien lu la page de man de hdparm, mais je ne suis pas sur d'avoir tout bien compris.

Merci d'avance.

----------

## Thom N2h

Et ya pas moyen de donner ces valeurs au noyau ?

c un peu bidon de devoir lancer un script pour les modifier

----------

## cylgalad

Il semble que le paramètre readahead diffère entre un noyau 2.4 ( 8 ) et un noyau 2.6 ( 256 ), d'ailleurs sur un 2.4 on ne peut pas le passer à 4096 :

```

hdparm -a 4096 /dev/hda

/dev/hda:

 setting fs readahead to 4096

 BLKRASET failed: Invalid argument

 readahead    =  8 (on)

```

Donc encore un mystère et boule de gomme...

----------

## Angelion

Oui, contraireemnt a ce qu'a dit guilc, sur les 2.4 la valeur max est de 255.

@Thom N2h: j'ai regardé vite fait, pas trouvé.

----------

## guilc

Non non, c'est bien ce que j'ai dit, je confirme, y a juste imprécision sur l'unité...

Le 2.4 par défaut est bien a 4096 en octets ! ce qui correspond a la valeur "-a 8", car le 2.4 ne compte pas en octets, mais en bloc de 512  :Wink: 

C'est expliqué la par exemple : http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6405.html

Petit récapitulatif :

2.4 -- 2.6

  8  --  4096

  16 --  8192

etc... donc mettre 4096 sur un 2.6 revient a mettre l'ancienne valeur utilisée sur les 2.4 (a savoir 8 donc)...

----------

## Angelion

Oki doki, merci de la precision.

----------

## Thom N2h

Et pourquoi n'ont-ils pas gardé la même valeur, ct sensé prendre moins de ressources ?

----------

## guilc

Aucune idée, et c'est plutot l'inverse : si le readahead est plus faible, les transferts auront plus d'impact sur l'utilisation processeur...

----------

