Journal Explications ?!?§!

Posté par  (site web personnel) .
Étiquettes : aucune
0
12
nov.
2003
Salut everybody,

je me suis enfin décidé à me prendre un hd externe, j'ai pu trouver un iomega 60 Go pour pas trop cher (jusqu'ici tout va bien).

Par contre, qqch m'interroge : quand je copie des fichiers dessus via mon konqueror préféré (je suis sous mandrake 9.1), le transfert me semble beaucoup (!) plus rapide que le même transfert sous win98 SE en usb 1.1 (pas encore eu le temps d'acheter une carte contrôleur usb2).

Quelqu'un a une explication sur ce gain de vitesse sensible ?

(l'impression ne m'est pas nouvelle, quand je copie plein de petits fichiers sur ma clé usb, win iscepé met bcp (bcp !) plus de temps à les transférer que sous nux)

++

  • # Re: Explications ?!?§!

    Posté par  . Évalué à 2.

    leur méthode d'estimation du temps restant ? genre celui de windows qui joue au yoyo et celui de konqui te paraît moins long ? ;)

    bon d'accord, y'a ptet aussi des E/S plus performantes dans l'histoire... pfff ils cassent toute la poésie !

    • [^] # Re: Explications ?!?§!

      Posté par  (site web personnel) . Évalué à 1.

      C'est clair que je ne chronomètre pas au 1/10ème près :) , toutefois :

      Méthode d'estimation 1 : sauvegarde du site sur lequel je bosse sur clé usb.
      Approximativement une 50-60aine de petits fichiers.

      Sous nux, le transfert est quasi-instantané.
      Sous XP, ç'est de l'ordre de la minute.

      Méthode d'estimation 2 : gros transferts (genre du 1Go) sur hd externe.

      Je remarque qu'avec de très gros fichiers (6-700 Mo), les perfs sont à peu près les mêmes sous mdk9.1 et sous win98 SE.
      Par contre, linux prend l'avantage sur des transferts de nombreux fichiers de taille moins conséquente.

      Ca m'avait toujours étonné de voir comme le transfert de fichiers était plus long sous win que sous nux, mais là, c'est vraiment flagrant, d'où mon interrogation sur le sujet.

      Sur ce, bonne nuité !

  • # Re: Explications ?!?§!

    Posté par  . Évalué à 3.

    Les periphs amovibles se font monter et demonter automatiquement sous windows98. Mais l'algo est tres loin d'etre optimum, par exemple si le systeme remplit des buffers pour pouvoir ensuite aller rajouter le contenu des buffers sur le disque amovible, Win peut considere que le disque n'est plus utilise et donc le demonte... Donc au moment de lapurge des buffers il faut 1) remonter le disque 2) retrouver le fichier cible (si c'est un seul gros fichier) 3) le reouvrir en append.

    Niveau perf forcement ca se fait tres mal....


    Kha

    • [^] # Re: Explications ?!?§!

      Posté par  (site web personnel) . Évalué à 4.

      La réponse est là, mais peut être mal présentée. Je me permets donc d'y apporter ma petite contribution.

      Sous l'OS au pinguoin, les entrees sorties, quelque soit le type de périphérique de blocs (DD ATAPI/DD USB...), se fait de facon bufferisée. A savoir que l'OS garde en memoire les zones modifiées et/ou accédées, et les écrit/lit effectivement quant ca lui chante. Tout ceci est rendu possible, par le fait que sous unix, les périphériques sont explicitement montés, et donc l'OS sait pertinement qu'un disque est dispo ou pas, et que l'ecriture/lecture sur le média peut donc attendre LE moment opportun.

      Or, ss Windows, les médias ne sont pas montés explicitement. L'OS automounte le média, et ne peut donc pas dans certains cas se prémunir d'une déconnection brutale du média (hop tu débranches le cable usb[1]). La seule solution consiste a faire des entrees/sorties non bufferisées, cad que la lecture/ecriture se fait sans aucun intermédiaire.

      Application a ton cas:
      - Ss windows, tu copies ton fichier sur le DD usb. Le transfert usb se fait immediatement. lA copie prend le temps exact imposé par la vitesse du canal (11Mbit/s pour l'usb 1.1).
      - SS linux, tu copies ton fichier surle DD usb. L'OS, s'il dispose de suffisament de RAM alloue des pages de type "cache", y copie le fichier. Tout cela se fait biensur extremement vite. Qd l'OS juge opportun d'ecrire le contenu de ses pages "cache" (besoin urgent de RAM pour autre chose, umount du média, ...), il vide ses buffers sur le média réel, mais ceci se passe en background, probablement bien après que tu ait copié le fichier via l'explorer KDE. L'explorer KDE te montre en fait le temps de mise en cache dans la plupart des cas.

      [1] Ss unix, la deconnexion d'un média sans un umount préalable rend le filesystem potentiellement inconsistent, car l'OS avait peut etre des buffers importants à y écrire. En gros, l'arrachage de cable c'est toujours aussi mauvais ss n'importe quel OS :)) pas de miracle.

      • [^] # Re: Explications ?!?§!

        Posté par  . Évalué à 2.

        est-il possible d'imposer une ecriture effective immédiate sous linux ?
        juste par curiosité

      • [^] # Re: Explications ?!?§!

        Posté par  . Évalué à 2.

        J'ai constaté aussi une différence de vitesse avec un lecteur Zip sur port parallèle. Relativement rapide sous Linux, interminable sous Windows 98.

        Et c'est pas une question de buffer, car d'une part, on entend bien quand ce genre de lecteur travail (en lecture ou écriture), et d'autre part, j'ai fait le test en utilisant la commande sync pour forcer l'écriture sur le disque.

        C'est donc une question de gestion du matériel.

      • [^] # Re: Explications ?!?§!

        Posté par  (site web personnel) . Évalué à 2.

        Exact. J'avais déjà remarqué ça :
        Sous Linux en ligne de commande, je copie un gros fichier sur ma clé USB - je récupère la main presque immédiatement, et la diode de la clé a à peine clignoté. Je veux récupérer la clé, et donc je la démonte (umount), et là seulement, il se met à écrire, pendant 3 ou 4 minutes, mon fichier, et je vois la diode de la clé qui clignote longtemps.
        Moralité : même si c'est de l'USB, il faut toujours démonter explicitement la clé, pour pas avoir de mauvaise surprise.

  • # Re: Explications ?!?§!

    Posté par  (site web personnel) . Évalué à 1.

    Merci pour vos réponses et pour vos explications.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.