Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage
FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la
sauvegarde complète de mes partitions, soit un total de 109 Gio sur un
autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule
partition.
Cas 1 : Disque formaté FAT32 : 64 minutes
Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture,
mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf :
Disque 1 : NTFS clusters de 4 kio
Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante
augmentation de temps ?
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des
partitions ?
Merci.
--
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
"Résultats 1 - 10 sur un total d'environ 5 640 000 pour Linux swap (0,29 secondes)" __ CB - Je participe, je demande ... C&C Message-ID: <4a8fe48e$0$2863$ ... mais je n'affirme pas ;+) !
Michel__D <Michel.NOSPAM@orange-ft.com.invalid> écrivit dans
news:4a8fdf26$0$12622$ba4acef3@news.orange.fr:
tu confirmes toujours tes dires ?
Bénon, je découvre !
"Résultats 1 - 10 sur un total d'environ 5 640 000 pour Linux swap
(0,29 secondes)"
__
CB - Je participe, je demande ...
C&C Message-ID: <4a8fe48e$0$2863$ba620e4c@news.skynet.be
... mais je n'affirme pas ;+) !
"Résultats 1 - 10 sur un total d'environ 5 640 000 pour Linux swap (0,29 secondes)" __ CB - Je participe, je demande ... C&C Message-ID: <4a8fe48e$0$2863$ ... mais je n'affirme pas ;+) !
Sergio
Michel__D a écrit :
Et le système Linux n'utilise pas de swap ?
Non, c'est particulier à Windows. __ CB C&C
C'est bizarre, moi j'ai toujours été contraint de créer une partition dédié au swap, tu confirme toujours tes dires ?
Pour une utilisation standard (poste de travail, serveur, etc.), Linux aura sûrement besoin d'un swap. Mais pour une utilisation spécifique (CD juste destiné à lancer un programme de sauvegarde, par exemple), il saura utiliser un minimum de ressources, et se passer de swap.
Ce n'est pas une guerre d'OS : je pense qu'un "Windows minimal" comme un CD BartPE, se passera très bien de swap.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Michel__D a écrit :
Et le système Linux n'utilise pas de swap ?
Non, c'est particulier à Windows.
__ CB
C&C
C'est bizarre, moi j'ai toujours été contraint de créer une partition
dédié au swap, tu confirme toujours tes dires ?
Pour une utilisation standard (poste de travail, serveur, etc.), Linux aura sûrement besoin d'un swap. Mais pour une utilisation
spécifique (CD juste destiné à lancer un programme de sauvegarde, par exemple), il saura utiliser un minimum de ressources, et se
passer de swap.
Ce n'est pas une guerre d'OS : je pense qu'un "Windows minimal" comme un CD BartPE, se passera très bien de swap.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
C'est bizarre, moi j'ai toujours été contraint de créer une partition dédié au swap, tu confirme toujours tes dires ?
Pour une utilisation standard (poste de travail, serveur, etc.), Linux aura sûrement besoin d'un swap. Mais pour une utilisation spécifique (CD juste destiné à lancer un programme de sauvegarde, par exemple), il saura utiliser un minimum de ressources, et se passer de swap.
Ce n'est pas une guerre d'OS : je pense qu'un "Windows minimal" comme un CD BartPE, se passera très bien de swap.
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Dominique Ottello
Michel__D écrivait :
> Pour ce cas particulier de très gros fichiers, la taille des clusters > est importante. D'ailleurs, ce soir, je vais essayer avec des clusters > de 64 kio ; juste pour voir.
Ok, je m'incline.
Le passage à 64 kio par cluster ne fait pas gagner de vitesse et aurait même tendance à très légèrement en faire perdre.
Bilan, avec toujours les mêmes conditions et même disque dur utilisé :
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture de gros fichiers sont plus rapides s'ils sont formatés avec des unités d'allocation de 32 kio.
-- Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
> Pour ce cas particulier de très gros fichiers, la taille des clusters
> est importante. D'ailleurs, ce soir, je vais essayer avec des clusters
> de 64 kio ; juste pour voir.
Ok, je m'incline.
Le passage à 64 kio par cluster ne fait pas gagner de vitesse et aurait
même tendance à très légèrement en faire perdre.
Bilan, avec toujours les mêmes conditions et même disque dur utilisé :
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture
de gros fichiers sont plus rapides s'ils sont formatés avec des unités
d'allocation de 32 kio.
--
Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation :
il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau,
même si c'est pire qu'avant et cela de toute évidence. Montherlant
Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
> Pour ce cas particulier de très gros fichiers, la taille des clusters > est importante. D'ailleurs, ce soir, je vais essayer avec des clusters > de 64 kio ; juste pour voir.
Ok, je m'incline.
Le passage à 64 kio par cluster ne fait pas gagner de vitesse et aurait même tendance à très légèrement en faire perdre.
Bilan, avec toujours les mêmes conditions et même disque dur utilisé :
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture de gros fichiers sont plus rapides s'ils sont formatés avec des unités d'allocation de 32 kio.
-- Aujourd'hui, l'idéal du progrès est remplacé par l'idéal de l'innovation : il ne s'agit pas que ce soit mieux, il s'agit seulement que ce soit nouveau, même si c'est pire qu'avant et cela de toute évidence. Montherlant Technologie aéronautique - http://ottello.net - Les anciens de Vilgénis
Eric PETIT
Dominique Ottello wrote: ....
Bilan, avec toujours les mêmes conditions et même disque dur utilisé :
Que des clusters de 32 permettent de gagner en vistesse ne parait pas extraordinaire, ça réduit dramatiquement le nombre de transactions avec le disque ;-) Il doit y avoir une histoire de compromis dans les échanges, une taille où l'info est la mieux proportionnée pour que le disque la reçoive (tailles de tampons) et la sauvegarde (je ne pense pas que les échanges entre la carte controleur du disque et le disque lui même se fasse avec la même notion)
Je ne serais même pas étonné que tes résultats ne puissent être interpolés à n'importe quel autre disque ! (Même si à la base la direction pourrait êre bonne). Tu confirme cependant une habitude que j'ai (eu) de créé des partitions dédiés au swap avec des gros clusters ;-))
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture de gros fichiers sont plus rapides s'ils sont formatés avec des unités d'allocation de 32 kio.
Va savoir, p'têt qu'avec des clusters de 16Ko ça irait plus vite >:-> -- Eric Reply-to valide, laissez tel quel ! Texte brut vivement conseillé !!
Dominique Ottello wrote:
....
Bilan, avec toujours les mêmes conditions et même disque dur utilisé :
Que des clusters de 32 permettent de gagner en vistesse ne parait pas
extraordinaire, ça réduit dramatiquement le nombre de transactions avec le
disque ;-)
Il doit y avoir une histoire de compromis dans les échanges, une taille où
l'info est la mieux proportionnée pour que le disque la reçoive (tailles de
tampons) et la sauvegarde (je ne pense pas que les échanges entre la carte
controleur du disque et le disque lui même se fasse avec la même notion)
Je ne serais même pas étonné que tes résultats ne puissent être interpolés à
n'importe quel autre disque ! (Même si à la base la direction pourrait êre
bonne). Tu confirme cependant une habitude que j'ai (eu) de créé des
partitions dédiés au swap avec des gros clusters ;-))
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture
de gros fichiers sont plus rapides s'ils sont formatés avec des unités
d'allocation de 32 kio.
Va savoir, p'têt qu'avec des clusters de 16Ko ça irait plus vite >:->
--
Eric
Reply-to valide, laissez tel quel !
Texte brut vivement conseillé !!
Que des clusters de 32 permettent de gagner en vistesse ne parait pas extraordinaire, ça réduit dramatiquement le nombre de transactions avec le disque ;-) Il doit y avoir une histoire de compromis dans les échanges, une taille où l'info est la mieux proportionnée pour que le disque la reçoive (tailles de tampons) et la sauvegarde (je ne pense pas que les échanges entre la carte controleur du disque et le disque lui même se fasse avec la même notion)
Je ne serais même pas étonné que tes résultats ne puissent être interpolés à n'importe quel autre disque ! (Même si à la base la direction pourrait êre bonne). Tu confirme cependant une habitude que j'ai (eu) de créé des partitions dédiés au swap avec des gros clusters ;-))
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture de gros fichiers sont plus rapides s'ils sont formatés avec des unités d'allocation de 32 kio.
Va savoir, p'têt qu'avec des clusters de 16Ko ça irait plus vite >:-> -- Eric Reply-to valide, laissez tel quel ! Texte brut vivement conseillé !!
markorki
Dominique Ottello a écrit :
Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la sauvegarde complète de mes partitions, soit un total de 109 Gio sur un autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule partition.
Cas 1 : Disque formaté FAT32 : 64 minutes Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture, mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf : Disque 1 : NTFS clusters de 4 kio Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante augmentation de temps ?
Oui, déjà, il y a 8 fois plus d'écritures physiques de clusters dans ce cas pour le NTFS que pour la FAT32, et NTFS doit produire des chainages plus complexes (avant et arrière ?) permettant de **corriger** autamatiquement les erreurs entrainées par un plantage ou une coupure de tension en cours de modif, au moins dans un certain pourcentage de cas.
Si ça ne dure pas 8 fois plus longtemps, c'est que le temps de passage des *commandes* d'écriture plus nombreuses, plus long, est quand même encore relativement faible par rapport au volume des données (mais s'en approche, puisque la différence est sensible). Il y a plus de blocs d'échange DMA plus petits qui passent sur le bus (qu'il soit parallèle ou série). Le cache interne au disque doit lisser les temps exigés par les mouvements de tête, surtout vers une partition fraichement formattée.
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des partitions
Oui, tu peux sans doute améliorer la granularité du disque cible en diminuant la taille de ses clusters: sur ma machine actuelle (W98SE-lite custom), j'ai une partition FAT32 de 149GO avec des clusters de 4KO (obtenu avec un équivalent de fdisk "moderne", pas celui de W98 et encore moins des outils XP, qui refusent probablement des partitions FAT32 aussi grosses).
Tu peux donc probablement diminuer la granularité à 16KO en FAT32 (voire moins, je n'ai jamais testé de partition de l'ordre de 500GO en FAT32), ce qui te permettrait de ralentir un peu la sauvegarde en FAT32 ;-) ... et n'améliorerait le taux de remplissage que pour les petits fichiers, inutile donc si la partition ne sert qu'à sauvegarder des images de partitions, DD, ou des images ISO de CD ou DVD.
... et je suis surpris qu'Acronis TU puisse sauver des images énormes en FAT32, dont la taille maxi de fichier est de 4GO. Je suppose qu'il produit une chaine de fichiers qu'il sait "recoller" à la restauration.
Dominique Ottello a écrit :
Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage
FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la
sauvegarde complète de mes partitions, soit un total de 109 Gio sur un
autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule
partition.
Cas 1 : Disque formaté FAT32 : 64 minutes
Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture,
mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf :
Disque 1 : NTFS clusters de 4 kio
Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante
augmentation de temps ?
Oui, déjà, il y a 8 fois plus d'écritures physiques de clusters dans ce
cas pour le NTFS que pour la FAT32, et NTFS doit produire des chainages
plus complexes (avant et arrière ?) permettant de **corriger**
autamatiquement les erreurs entrainées par un plantage ou une coupure de
tension en cours de modif, au moins dans un certain pourcentage de cas.
Si ça ne dure pas 8 fois plus longtemps, c'est que le temps de passage
des *commandes* d'écriture plus nombreuses, plus long, est quand même
encore relativement faible par rapport au volume des données (mais s'en
approche, puisque la différence est sensible). Il y a plus de blocs
d'échange DMA plus petits qui passent sur le bus (qu'il soit parallèle
ou série). Le cache interne au disque doit lisser les temps exigés par
les mouvements de tête, surtout vers une partition fraichement formattée.
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des
partitions
Oui, tu peux sans doute améliorer la granularité du disque cible en
diminuant la taille de ses clusters: sur ma machine actuelle (W98SE-lite
custom), j'ai une partition FAT32 de 149GO avec des clusters de 4KO
(obtenu avec un équivalent de fdisk "moderne", pas celui de W98 et
encore moins des outils XP, qui refusent probablement des partitions
FAT32 aussi grosses).
Tu peux donc probablement diminuer la granularité à 16KO en FAT32 (voire
moins, je n'ai jamais testé de partition de l'ordre de 500GO en FAT32),
ce qui te permettrait de ralentir un peu la sauvegarde en FAT32 ;-)
... et n'améliorerait le taux de remplissage que pour les petits
fichiers, inutile donc si la partition ne sert qu'à sauvegarder des
images de partitions, DD, ou des images ISO de CD ou DVD.
... et je suis surpris qu'Acronis TU puisse sauver des images énormes en
FAT32, dont la taille maxi de fichier est de 4GO. Je suppose qu'il
produit une chaine de fichiers qu'il sait "recoller" à la restauration.
Diapublié sur : fr.comp.os.ms-windows,fr.comp.stockage FU2 : fr.comp.os.ms-windows
Bonjour,
À partir du CD de démarrage, lancement de Acronis True Image pour la sauvegarde complète de mes partitions, soit un total de 109 Gio sur un autre disque dur SATA, HITACHI HDP72505GLA360 de 480 Gio en une seule partition.
Cas 1 : Disque formaté FAT32 : 64 minutes Cas 2 : Disque formaté NTFS : 106 minutes
+ 60% de temps pour la même quantité ; c'est énorme !
Je savais que NTFS était légèrement plus lent que FAT32 en écriture, mais pas à ce point là.
Tout est absolument identique dans les deux cas sauf : Disque 1 : NTFS clusters de 4 kio Disque 2 : FAT32 clusters de 32 kio
Serait-ce la taille des clusters qui induit cette importante augmentation de temps ?
Oui, déjà, il y a 8 fois plus d'écritures physiques de clusters dans ce cas pour le NTFS que pour la FAT32, et NTFS doit produire des chainages plus complexes (avant et arrière ?) permettant de **corriger** autamatiquement les erreurs entrainées par un plantage ou une coupure de tension en cours de modif, au moins dans un certain pourcentage de cas.
Si ça ne dure pas 8 fois plus longtemps, c'est que le temps de passage des *commandes* d'écriture plus nombreuses, plus long, est quand même encore relativement faible par rapport au volume des données (mais s'en approche, puisque la différence est sensible). Il y a plus de blocs d'échange DMA plus petits qui passent sur le bus (qu'il soit parallèle ou série). Le cache interne au disque doit lisser les temps exigés par les mouvements de tête, surtout vers une partition fraichement formattée.
Ou y aurait-il d'autres paramètres à modifier dans les propriétés des partitions
Oui, tu peux sans doute améliorer la granularité du disque cible en diminuant la taille de ses clusters: sur ma machine actuelle (W98SE-lite custom), j'ai une partition FAT32 de 149GO avec des clusters de 4KO (obtenu avec un équivalent de fdisk "moderne", pas celui de W98 et encore moins des outils XP, qui refusent probablement des partitions FAT32 aussi grosses).
Tu peux donc probablement diminuer la granularité à 16KO en FAT32 (voire moins, je n'ai jamais testé de partition de l'ordre de 500GO en FAT32), ce qui te permettrait de ralentir un peu la sauvegarde en FAT32 ;-) ... et n'améliorerait le taux de remplissage que pour les petits fichiers, inutile donc si la partition ne sert qu'à sauvegarder des images de partitions, DD, ou des images ISO de CD ou DVD.
... et je suis surpris qu'Acronis TU puisse sauver des images énormes en FAT32, dont la taille maxi de fichier est de 4GO. Je suppose qu'il produit une chaine de fichiers qu'il sait "recoller" à la restauration.
Dominique Ottello
markorki <moicestmarkorkichezorangefr> écrivait :
Tu peux donc probablement diminuer la granularité à 16KO en FAT32 (voire moins, je n'ai jamais testé de partition de l'ordre de 500GO en FAT32),
Ça fonctionne très bien avec des disques de 500 Go (486 Gio) partitionnés avec FDISK 1.3.1 de FreeDos, mais le formatage impose des clusters de 32 kio.
... et je suis surpris qu'Acronis TU puisse sauver des images énormes en FAT32, dont la taille maxi de fichier est de 4GO. Je suppose qu'il produit une chaine de fichiers qu'il sait "recoller" à la restauration.
- Un fichier de 109 Gio en sauvegarde sur disque NTFS - 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32
Et les restaurations fonctionnent très bien, que ce soit à partir de sauvegardes sur FAT32 ou NTFS. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
markorki <moicestmarkorkichezorangefr> écrivait :
Tu peux donc probablement diminuer la granularité à 16KO en FAT32 (voire
moins, je n'ai jamais testé de partition de l'ordre de 500GO en FAT32),
Ça fonctionne très bien avec des disques de 500 Go (486 Gio)
partitionnés avec FDISK 1.3.1 de FreeDos, mais le formatage impose des
clusters de 32 kio.
... et je suis surpris qu'Acronis TU puisse sauver des images énormes en
FAT32, dont la taille maxi de fichier est de 4GO. Je suppose qu'il
produit une chaine de fichiers qu'il sait "recoller" à la restauration.
- Un fichier de 109 Gio en sauvegarde sur disque NTFS
- 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32
Et les restaurations fonctionnent très bien, que ce soit à partir de
sauvegardes sur FAT32 ou NTFS.
--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net)
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Tu peux donc probablement diminuer la granularité à 16KO en FAT32 (voire moins, je n'ai jamais testé de partition de l'ordre de 500GO en FAT32),
Ça fonctionne très bien avec des disques de 500 Go (486 Gio) partitionnés avec FDISK 1.3.1 de FreeDos, mais le formatage impose des clusters de 32 kio.
... et je suis surpris qu'Acronis TU puisse sauver des images énormes en FAT32, dont la taille maxi de fichier est de 4GO. Je suppose qu'il produit une chaine de fichiers qu'il sait "recoller" à la restauration.
- Un fichier de 109 Gio en sauvegarde sur disque NTFS - 27 fichiers de 4Gio + 1 du reliquat sur disque FAT32
Et les restaurations fonctionnent très bien, que ce soit à partir de sauvegardes sur FAT32 ou NTFS. -- Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net) Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr
Pascal Hambourg
Salut,
Dominique Ottello a écrit :
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture de gros fichiers sont plus rapides s'ils sont formatés avec des unités d'allocation de 32 kio.
Je trouve que tu vas un peu vite dans ta conclusion car tu n'as effectués tes mesures qu'avec Acronis True Image. Il n'est pas totalement exclu que ce soit une particularité de ce dernier qui rende l'écriture plus lente avec de petits clusters.
Salut,
Dominique Ottello a écrit :
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture
de gros fichiers sont plus rapides s'ils sont formatés avec des unités
d'allocation de 32 kio.
Je trouve que tu vas un peu vite dans ta conclusion car tu n'as
effectués tes mesures qu'avec Acronis True Image. Il n'est pas
totalement exclu que ce soit une particularité de ce dernier qui rende
l'écriture plus lente avec de petits clusters.
Conclusion : Les disques durs NTFS utilisés exclusivement à l'écriture de gros fichiers sont plus rapides s'ils sont formatés avec des unités d'allocation de 32 kio.
Je trouve que tu vas un peu vite dans ta conclusion car tu n'as effectués tes mesures qu'avec Acronis True Image. Il n'est pas totalement exclu que ce soit une particularité de ce dernier qui rende l'écriture plus lente avec de petits clusters.
Pascal Hambourg
Salut,
_Dine & Clau_ a écrit :
Michel__D écrivit :
Et le système Linux n'utilise pas de swap ?
Il peut.
Non, c'est particulier à Windows.
Mais non, ça existe au moins depuis qu'il y a des OS utilisant la pagination.
Mais non, ça existe au moins depuis qu'il y a des OS utilisant la pagination.
Droger Jean-Paul
Pascal Hambourg avait écrit le 24/08/2009 :
Salut,
_Dine & Clau_ a écrit :
Michel__D écrivit :
Et le système Linux n'utilise pas de swap ?
Il peut.
Non, c'est particulier à Windows.
Mais non, ça existe au moins depuis qu'il y a des OS utilisant la pagination.
le swap ou mémoire dite virtuelle existait déjà vers 1975 sur les ordinateurs IBM (et sans doute CDC mais je ne me rappelle plus) donc bien avant l'invention du PC, sur des machines très puissantes (mémoire centrale 5Mo pour le 2ème plus gros centre de calcul en France en 1975/6!!! )
Par contre une constante dans le temps: le système utilise le swap avant que la Ram ne soit saturée, et cela ralentit les calculs!!
Pour les vitesse d'écrirure sur DD, faut savoir que le système fait des écritures par paquets d'octets .... et que même en ne demandant que le transfert d'un gros fichier, il se fait que windows (mais la plupart des autres systèmes aussi) fait faire autre chose ... et cela conduit à des accès non prévus, des déplacements de bras de lecture .... Bref c'est un peu la bouteille à encre!! Mais globalement avoir de gros cluster (qui ne peuvent qu'être écrit ou lus qu'en une seule fois) fait théoriquement gagner du temps mais perdre de la place .... car tout fichier comporte un nombre entier de cluster!!! Mais cela est théorique, et je suis étonné qu'on en voit la réalité ... Ne pas oublier qu'il y a toujours des opérations parasites et surtout des goulots d'étranglement dans les PC car, malheureusement, rien n'est optimisé (et je ne parle pas des bus de liaison dont on parle peu voire pas du tout ... et qui sont au au moindre cout)!
Sur ce bonne semaine.
-- Pour m'envoyer un mail, remplacer anti par droger et manama par wanadoo; to send me directly a mail replace anti with droger and manama with wanadoo;
Mais non, ça existe au moins depuis qu'il y a des OS utilisant la
pagination.
le swap ou mémoire dite virtuelle existait déjà vers 1975 sur les
ordinateurs IBM (et sans doute CDC mais je ne me rappelle plus) donc
bien avant l'invention du PC, sur des machines très puissantes (mémoire
centrale 5Mo pour le 2ème plus gros centre de calcul en France en
1975/6!!! )
Par contre une constante dans le temps: le système utilise le swap
avant que la Ram ne soit saturée, et cela ralentit les calculs!!
Pour les vitesse d'écrirure sur DD, faut savoir que le système fait des
écritures par paquets d'octets .... et que même en ne demandant que le
transfert d'un gros fichier, il se fait que windows (mais la plupart
des autres systèmes aussi) fait faire autre chose ... et cela conduit à
des accès non prévus, des déplacements de bras de lecture .... Bref
c'est un peu la bouteille à encre!! Mais globalement avoir de gros
cluster (qui ne peuvent qu'être écrit ou lus qu'en une seule fois) fait
théoriquement gagner du temps mais perdre de la place .... car tout
fichier comporte un nombre entier de cluster!!! Mais cela est
théorique, et je suis étonné qu'on en voit la réalité ... Ne pas
oublier qu'il y a toujours des opérations parasites et surtout des
goulots d'étranglement dans les PC car, malheureusement, rien n'est
optimisé (et je ne parle pas des bus de liaison dont on parle peu voire
pas du tout ... et qui sont au au moindre cout)!
Sur ce bonne semaine.
--
Pour m'envoyer un mail, remplacer anti par droger et manama par
wanadoo; to send me directly a mail replace anti with droger and manama
with wanadoo;
anti.jean-paul@manama.fr
Mais non, ça existe au moins depuis qu'il y a des OS utilisant la pagination.
le swap ou mémoire dite virtuelle existait déjà vers 1975 sur les ordinateurs IBM (et sans doute CDC mais je ne me rappelle plus) donc bien avant l'invention du PC, sur des machines très puissantes (mémoire centrale 5Mo pour le 2ème plus gros centre de calcul en France en 1975/6!!! )
Par contre une constante dans le temps: le système utilise le swap avant que la Ram ne soit saturée, et cela ralentit les calculs!!
Pour les vitesse d'écrirure sur DD, faut savoir que le système fait des écritures par paquets d'octets .... et que même en ne demandant que le transfert d'un gros fichier, il se fait que windows (mais la plupart des autres systèmes aussi) fait faire autre chose ... et cela conduit à des accès non prévus, des déplacements de bras de lecture .... Bref c'est un peu la bouteille à encre!! Mais globalement avoir de gros cluster (qui ne peuvent qu'être écrit ou lus qu'en une seule fois) fait théoriquement gagner du temps mais perdre de la place .... car tout fichier comporte un nombre entier de cluster!!! Mais cela est théorique, et je suis étonné qu'on en voit la réalité ... Ne pas oublier qu'il y a toujours des opérations parasites et surtout des goulots d'étranglement dans les PC car, malheureusement, rien n'est optimisé (et je ne parle pas des bus de liaison dont on parle peu voire pas du tout ... et qui sont au au moindre cout)!
Sur ce bonne semaine.
-- Pour m'envoyer un mail, remplacer anti par droger et manama par wanadoo; to send me directly a mail replace anti with droger and manama with wanadoo;
