hdparm

• [^]Re: hdparm

  Posté par khalahan () le 12/06/2007 à 17:03. (lien). Évalué à 2.

  Après quelques autres tests avec :
  - la CF branchée et le disque dur
  - les options de boot : ide=nodma nodma
  Le boot a réussi à se terminer.
  Cependant, les débits HDD => CF vont de 2,6Mo/s à 2,7Mo/s...
  
  Toujours sans dma au boot, je tente de l'activer avec hdparm (sur les 2) (oui, n'ayons peur de rien :D) :
  - copie HDD => 18Mo/s à 20Mo/s
  C'est déjà mieux, sauf que le système est plus qu'instable... ("attempt to acces beyond end of device", "dma timeout error")
  
  Je tente la même chose puis configure en udma0 (les 2 toujours) :
  - débit de 8Mo/s à 9Mo/s.
  Système tout aussi instable.
  
  
  Pour ta proposition, est-il possible de le faire juste après que le kernel affiche les messages :
  VP_IDE: VIA vt8283... UDE UDM100 controller....
  ide0 : .... hda:DMA, hdb:DMA
  ide1 : .... hdc:DMA, hdd:DMA
  hda : TRANSCEND, ATA DISK driver
  ...
  hdd : blabla DVDROM
  
  et avant le montage des partitions ? (c'est là que ça déconne) :
  EXT3-fs: mounted filesystem with ordered data mode.
  hda: dma_intr: status=0x51 { DriverReady SeekComplete Error }
  hda: dma_intr: error=0x84 { DriverStatusError BadCRC }
  hda: dma_intr: status=0x51 { DriverReady SeekComplete Error }
  hda: dma_intr: error=0x84 { DriverStatusError BadCRC }
  idem
  ...
  ...
  hdb : DMA disabled (le DMA est activé au boot là, donc pourquoi il touche à hdb qui est le disque dur normal)
  ide0: reset: success

  • [^]Re: hdparm

    Posté par khalahan () le 12/06/2007 à 18:48. (lien). Évalué à 1.

    Voici d'autres tests :
    
    
    * boot avec : ide=nodma nodma
    
    test de copie de fichier de HDD à CF : 2,7Mo/s et 2,6Mo/s
    action du DMA avec hdparm (hdparm -d1 /dev/hda et hdb) : 18,5Mo/s et 19,8Mo/s)
    
    peut après (suite à un 'hdparm -i /dev/hdb' peut être), plantage de la console
    => delogué, erreurs DMA (timeout), ext3-fs error, etc.
    
    
    * boot avec ide=nodma, disque dur avec dma activé (hdparm), CF sans DMA :
    Le système a l'air stable, sauf que la CF est sous vraiment utilisée (5ou6Mo/s en lecture).
    
    Dois-je en conclure d'après vous que c'est l'adaptateur le fautif ?

    • [^]Re: hdparm

      Posté par chimrod (Jabber id, page perso, ) le 12/06/2007 à 20:11. (lien). Évalué à 1.

      J'ai aussi ce système et j'ai du recompiler le noyau en désactivant l'option DMA pour le boot ( j'avais précisé ça dans l'autre post ). En fait cela vient du noyau visiblement plus que du contrôleur ( dans mon cas l'option nodma au boot ne suffisait pas ).
      
      Pour ce qui est du nombre de cycles, il s'agit du nombre d'écriture PAR secteur ! ( Le nombre de lectures est infini ! ) Ce qui rend tout de suite la chose plus intéressante ( il suffit de déplacer certains logs et certains répertoires de /var sur tmpfs et il n'y a plus aucun problèmes : la carte peut passer une journée à tournée sans qu'on y aille écrire quoi que ce soit...
      ( par exemple mettre en tempfs /tmp /var/log/ntpstats, /var/lib/ntp, /var/cache/ddclient et supprimer syslog[-ng] devrait déjà suffire )
      
      Le gros avantage est de pouvoir mettre le disque dur en stand-by à ce moment là, et de ne le laisser s'activer que lorsque l'on a besoin d'accéder à des données ( /home par exemple ).
      -> baisse de la consommation, baisse de la température ( le fanless devient possible )
      
      À ce propos on peut trouver sur ebay de nombreux PC barebones ( aux alentours de 266-533Mhz ) qui ont un slot CF intégré sur la carte mère...
      
      Dans mon cas il ne me reste plus qu'à mettre en place un script init qui irait copier certains fichiers dans /tmp et qui ensuite irait les sauvegarder sur le disque dur au moment où on éteint le pc avant de considérer que mon installation est complète.

      --
      It is no bug, it's future

      • [^]Re: hdparm

        Posté par khalahan () le 12/06/2007 à 21:08. (lien). Évalué à 1.

        Ca signifie donc que ta carte n'est pas à son débit maximum ?
        Quelles sont les performances cependant ?
        Est-ce que le lancement des applications est + réactif quand même ?
        
        
        Je ne compte pas la faire tourner à 5mo/s au lieu de 40mo/s... je vais aller me renseigner du coté du vendeur du convertisseur (le constructeur a l'air chinois lui : mini doc en anglais et en chinois).

        • [^]Re: hdparm

          Posté par chimrod (Jabber id, page perso, ) le 12/06/2007 à 21:58. (lien). Évalué à 1.

          Effectivement, le débit sur la carte est très faible :
          

          
          $ sudo hdparm -tT /dev/hdc
          
          /dev/hdc:
          Timing cached reads: 122 MB in 2.02 seconds = 60.38 MB/sec
          Timing buffered disk reads: 8 MB in 3.70 seconds = 2.16 MB/sec
          

          
          Les applications restent réactives ( enfin pour un serveur ! il n'y a pas X dessus, juste ssh, apache, exim... ) donc pour ce que j'en fait tout cela fonctionne très bien pour moi.. ).
          En fait le débit ne me dérange pas plus que ça, ce qui compte pour moi c'est la fiabilité de la carte, et le fait que je puisse complètement désactiver mon autre disque dur, et donc laisser le pc se faire oublier dans un coin... ( je ne me sers donc pas de ce pc comme ordinateur principal ). Comme il passe la plupart du temps à ne rien faire, autant qu'il se mette en veille, qu'il ne consomme pas, mais qu'il puisse s'activer à la moindre demande.
          
          Enfin renseigne toi, sûrement que d'un matériel à l'autre, les résultats seront différents...

          --
          It is no bug, it's future

        [^]Re: hdparm

        Posté par khalahan () le 12/06/2007 à 21:45. (lien). Évalué à 2.

        Après avoir mis à jour de Sarge (la seule à ma disposition ce soir) à Testing, cela ne marche plu...
        - Kernel 2.6.8 => 2.6.18 (et c bien lui le responsable, car ça boot sans soucis avec le 2.6.8, ou alors c'est un programme lié comme Hal (qui a besoin d'un 2.6.15 pour se lancer)).
        
        Bref... c'est pas simple...

        • [^]Re: hdparm

          Posté par khalahan () le 13/06/2007 à 12:07. (lien). Évalué à 1.

          J'ai réussi à passer le boot sans devoir toucher au kernel avec les options "ide=nodma noapic".
          Il y a des erreurs au boot, cependant ça passe quand même, et une fois le boot terminé je peux voir que le DMA est bien désactivé.
          Je suppose donc que le kernel ne prend en compte l'option nodma qu'à partir d'un certain moment.
          
          Une fois booté, j'ai testé différentes options avec le DMA, et ce qui donne les meilleurs performances est le mode 'mdma2' :
          # hdparm -d1 -Xmdma2 -tT /dev/hda
          Timing buffered disk reads: 44 MB in 3.08 seconds = 14.30 MB/sec
          # hdparm -d1 -Xudma1 -tT /dev/hda
          Timing buffered disk reads: 24 MB in 3.22 seconds = 7.44 MB/sec
          Les autres modes > udma1 provoquent des erreurs DMA.
          
          J'ai trouvé sur cette page [1] une liste des correspondances entre les modes ultra DMA et les normes ATA. Pour mon adapteur qui supporte du ATA33, celà correspond au umda2. Mon adaptateur est éventuellement menteur dans sa doc :D
          
          J'ai aussi constaté un autre problème, sûrement lié à la désactivation du DMA au boot, même après l'activation avec hdparm : le CPU tourne à 100% lors d'une copie de fichier, et pendant plus longtemps que la copie.
          Ex pour un fichier de 170Mo :
          #time cp fichier_hdb fichier_hda
          réel : 0m7.561s
          et temps CPU : 18s à 100%
          Il faut donc se méfier des benchs (vous avez déjà entendu ça qq part non ? :p) et le mode udma1 n'est pas plus lent si on tient compte du CPU.
          
          chimrod > si tu as encore le noyau qui plante, peut-tu tester avec l' option 'noapic' en + voir si ça boot chez toi ?
          
          nicO > en effet, en modifiant le mode avec hdparm il y a eu du progrès, même si on est très loin des 40Mo/s :p
          
          [1] http://gentoo-wiki.com/HOWTO_Use_hdparm_to_improve_IDE_devic(...)

          • [^]Re: hdparm

            Posté par Nicolas Boulay () le 13/06/2007 à 12:20. (lien). Évalué à 2.

            Je te conseillerais de faire les essaies avec le tout dernier noyau et avec les lspci et autre qui vont bien et mettre le tout dans le système de correction de bugsde linux.

            [^]Re: hdparm

            Posté par chimrod (Jabber id, page perso, ) le 13/06/2007 à 20:30. (lien). Évalué à 2.

            Merci pour l'info !
            
            J'ai donc testé le boot avec noapic, et ça me permet d'avoir le dma sur le DD ( pas sur la carte CF, j'ai des erreurs DMA au démarrage, mais qui se terminent sur un DMA désactivé ) Je vais pouvoir revenir au noyau standard !
            ( J'avais fait mes premiers test avec un pentium1, pour qui le passage par la recompilation est obligatoire.. )
            
            Pour info, pour identifier quels sont les programmes qui pourraient éventuellement écrire sur la carte ( pour éviter les points d'usure ), lancer sysctl vm.block_dump=1 et ensuite vérifier avec dmesg quels sont les programmes ayant écrit sur les disques..
            
            Il y a sûrement moyen de faire un bon tuto de tout ça, à partir des différentes config, et des différentes expériences...!

            --
            It is no bug, it's future

            [^]Re: hdparm

            Posté par naibed () le 15/06/2007 à 10:00. (lien). Évalué à 1.

            Je vais peut être dire un connerie mais de mémoire il me semble
            que pour du DMA33 il faut une nappe 40 pin et non pas 80 comme
            pour UDMA66, 100 et 133.
            
            Donc essaye si tu peux avec uniquement la compact flash sur une nappe 40.