Pour la nowel je vais (me faire) offir un SSD à mon mac mini 2009.
Il ira à la place de l'ancien DD et l'ancien ira dans un caddy à la
place du graveur qui est mort depuis belle lurette.
Le budget est de maxi 100 euros.
Lequel pouvez-vous me conseiller ?
La star du moment semble être le Vertex 3 ; qu'en pensez vous ?
60 Go me semble un strict minimum pour ce que j'ai à y mettre.
(Je vous demanderais plus tard quoi mettre dessus, système, applis...)
Le 06/12/11 06:51, patpro ~ patrick proniewski a écrit :
In article, pehache wrote:
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher ensuite en background sur le disque. De la sorte, l'utilisateur ne ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie condui(rai)t à une utilisation intensive du SSD en écriture.
J'ai bien fait d'être prudent, en réalité le cache en écriture c'est pas encore pour tout de suite, mais c'est prévu dans une mise à jour du firmware. Cela dit, comme c'est de la mémoire flash SLC, sa durée de vie est supérieure à la mémoire flash des disques grand public de deux ordres de grandeur, donc il n'y a pas d'inquiétude à avoir.
Quoi qu'il en soit, si à mon sens ce disque se base sur le principe le plus rentable (ie. un gros volume à plateaux avec un cache flash et une gestion de ce cache au niveau firmware), on est quand même assez loin d'un résultat intéressant. En terme de performance il est encore comparé à d'autres disques à plateaux. Je suis incapable de dire si ce qui lui manque le plus c'est un controleur performant ou si c'est du volume de mémoire flash.
Même avec un bon contrôleur je ne vois pas comment espérer des perfs géniales avec juste 8Go de SSD
Autre chose : les tests standards reflètent mal les conditions d'utilisation réelle de ce type de disque. Notamment les tests d'accès aléatoires ne veulent rien dire, car justement l'optimisation entre SSD et HD repose sur le fait que les accès ne sont pas totalement aléatoires et que certains fichiers sont lus beaucoup plus souvent que d'autres.
Le 06/12/11 06:51, patpro ~ patrick proniewski a écrit :
In article<9k56o4FehpU2@mid.individual.net>,
pehache<pehache.7@gmail.com> wrote:
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas
idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher
ensuite en background sur le disque. De la sorte, l'utilisateur ne
ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie
condui(rai)t à une utilisation intensive du SSD en écriture.
J'ai bien fait d'être prudent, en réalité le cache en écriture c'est pas
encore pour tout de suite, mais c'est prévu dans une mise à jour du
firmware. Cela dit, comme c'est de la mémoire flash SLC, sa durée de vie
est supérieure à la mémoire flash des disques grand public de deux
ordres de grandeur, donc il n'y a pas d'inquiétude à avoir.
Quoi qu'il en soit, si à mon sens ce disque se base sur le principe le
plus rentable (ie. un gros volume à plateaux avec un cache flash et une
gestion de ce cache au niveau firmware), on est quand même assez loin
d'un résultat intéressant. En terme de performance il est encore comparé
à d'autres disques à plateaux.
Je suis incapable de dire si ce qui lui manque le plus c'est un
controleur performant ou si c'est du volume de mémoire flash.
Même avec un bon contrôleur je ne vois pas comment espérer des perfs
géniales avec juste 8Go de SSD
Autre chose : les tests standards reflètent mal les conditions
d'utilisation réelle de ce type de disque. Notamment les tests d'accès
aléatoires ne veulent rien dire, car justement l'optimisation entre SSD
et HD repose sur le fait que les accès ne sont pas totalement aléatoires
et que certains fichiers sont lus beaucoup plus souvent que d'autres.
Le 06/12/11 06:51, patpro ~ patrick proniewski a écrit :
In article, pehache wrote:
Le 05/12/11 17:53, patpro ~ patrick proniewski a écrit :
Il faudrait que je vérifie au niveau du Momentus XT, mais il n'est pas idiot de supposer que par défaut il écrit sur le cache SSD, pour flusher ensuite en background sur le disque. De la sorte, l'utilisateur ne ressent pas de latence.
Ca paraitrait logique. A ceci près quand même que cette stratégie condui(rai)t à une utilisation intensive du SSD en écriture.
J'ai bien fait d'être prudent, en réalité le cache en écriture c'est pas encore pour tout de suite, mais c'est prévu dans une mise à jour du firmware. Cela dit, comme c'est de la mémoire flash SLC, sa durée de vie est supérieure à la mémoire flash des disques grand public de deux ordres de grandeur, donc il n'y a pas d'inquiétude à avoir.
Quoi qu'il en soit, si à mon sens ce disque se base sur le principe le plus rentable (ie. un gros volume à plateaux avec un cache flash et une gestion de ce cache au niveau firmware), on est quand même assez loin d'un résultat intéressant. En terme de performance il est encore comparé à d'autres disques à plateaux. Je suis incapable de dire si ce qui lui manque le plus c'est un controleur performant ou si c'est du volume de mémoire flash.
Même avec un bon contrôleur je ne vois pas comment espérer des perfs géniales avec juste 8Go de SSD
Autre chose : les tests standards reflètent mal les conditions d'utilisation réelle de ce type de disque. Notamment les tests d'accès aléatoires ne veulent rien dire, car justement l'optimisation entre SSD et HD repose sur le fait que les accès ne sont pas totalement aléatoires et que certains fichiers sont lus beaucoup plus souvent que d'autres.
patpro ~ Patrick Proniewski
In article , pehache wrote:
Autre chose : les tests standards reflètent mal les conditions d'utilisation réelle de ce type de disque. Notamment les tests d'accès aléatoires ne veulent rien dire, car justement l'optimisation entre SSD et HD repose sur le fait que les accès ne sont pas totalement aléatoires et que certains fichiers sont lus beaucoup plus souvent que d'autres.
ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les blocs de manière séquentielle :) Et c'est bien la dessus que repose les tests "random" : lire ou écrire des blocs éparpillés sur le disque. Par opposition à la lecture d'un ensemble de blocs contigus comme dans le cas d'un gros fichier totalement défragmenté.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
In article <9k621dF56vU1@mid.individual.net>,
pehache <pehache.7@gmail.com> wrote:
Autre chose : les tests standards reflètent mal les conditions
d'utilisation réelle de ce type de disque. Notamment les tests d'accès
aléatoires ne veulent rien dire, car justement l'optimisation entre SSD
et HD repose sur le fait que les accès ne sont pas totalement aléatoires
et que certains fichiers sont lus beaucoup plus souvent que d'autres.
ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les
blocs de manière séquentielle :)
Et c'est bien la dessus que repose les tests "random" : lire ou écrire
des blocs éparpillés sur le disque. Par opposition à la lecture d'un
ensemble de blocs contigus comme dans le cas d'un gros fichier
totalement défragmenté.
patpro
--
Je cherche à changer d'air -> http://www.patpro.net/cv
Autre chose : les tests standards reflètent mal les conditions d'utilisation réelle de ce type de disque. Notamment les tests d'accès aléatoires ne veulent rien dire, car justement l'optimisation entre SSD et HD repose sur le fait que les accès ne sont pas totalement aléatoires et que certains fichiers sont lus beaucoup plus souvent que d'autres.
ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les blocs de manière séquentielle :) Et c'est bien la dessus que repose les tests "random" : lire ou écrire des blocs éparpillés sur le disque. Par opposition à la lecture d'un ensemble de blocs contigus comme dans le cas d'un gros fichier totalement défragmenté.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
pehache
On Dec 6, 11:38 am, patpro ~ Patrick Proniewski wrote:
In article ,
pehache wrote: > Autre chose : les tests standards refl tent mal les conditions > d'utilisation r elle de ce type de disque. Notamment les tests d'acc s > al atoires ne veulent rien dire, car justement l'optimisation entre SSD > et HD repose sur le fait que les acc s ne sont pas totalement al atoire s > et que certains fichiers sont lus beaucoup plus souvent que d'autres.
ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les blocs de manière séquentielle :) Et c'est bien la dessus que repose les tests "random" : lire ou crire des blocs péarpillés sur le disque.
Et c'est justement ça qui n'est pas pertinent pour un disque hybride.
Dans le cas du momentus 750Go HD + 8Go SSD (rapport de 100 environ), un test purement random va mesurer 99% du temps le temps d'accès du HD, et seulement 1% du temps le temps d'accès du SSD. Et conclure que le temps d'accès moyen est quasiment le même que pour un simple HD sans SSD.
Alors qu'en utilisation réelle, le SSD représente peut-être 10% des accès (là je lance un chiffre au hasard), et non pas 1% (sinon, le système n'aurait aucun intérêt).
On Dec 6, 11:38 am, patpro ~ Patrick Proniewski
<pat...@boleskine.patpro.net> wrote:
In article <9k621dF56...@mid.individual.net>,
pehache <pehach...@gmail.com> wrote:
> Autre chose : les tests standards refl tent mal les conditions
> d'utilisation r elle de ce type de disque. Notamment les tests d'acc s
> al atoires ne veulent rien dire, car justement l'optimisation entre SSD
> et HD repose sur le fait que les acc s ne sont pas totalement al atoire s
> et que certains fichiers sont lus beaucoup plus souvent que d'autres.
ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les
blocs de manière séquentielle :)
Et c'est bien la dessus que repose les tests "random" : lire ou crire
des blocs péarpillés sur le disque.
Et c'est justement ça qui n'est pas pertinent pour un disque hybride.
Dans le cas du momentus 750Go HD + 8Go SSD (rapport de 100 environ),
un test purement random va mesurer 99% du temps le temps d'accès du
HD, et seulement 1% du temps le temps d'accès du SSD. Et conclure que
le temps d'accès moyen est quasiment le même que pour un simple HD
sans SSD.
Alors qu'en utilisation réelle, le SSD représente peut-être 10% des
accès (là je lance un chiffre au hasard), et non pas 1% (sinon, le
système n'aurait aucun intérêt).
On Dec 6, 11:38 am, patpro ~ Patrick Proniewski wrote:
In article ,
pehache wrote: > Autre chose : les tests standards refl tent mal les conditions > d'utilisation r elle de ce type de disque. Notamment les tests d'acc s > al atoires ne veulent rien dire, car justement l'optimisation entre SSD > et HD repose sur le fait que les acc s ne sont pas totalement al atoire s > et que certains fichiers sont lus beaucoup plus souvent que d'autres.
ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les blocs de manière séquentielle :) Et c'est bien la dessus que repose les tests "random" : lire ou crire des blocs péarpillés sur le disque.
Et c'est justement ça qui n'est pas pertinent pour un disque hybride.
Dans le cas du momentus 750Go HD + 8Go SSD (rapport de 100 environ), un test purement random va mesurer 99% du temps le temps d'accès du HD, et seulement 1% du temps le temps d'accès du SSD. Et conclure que le temps d'accès moyen est quasiment le même que pour un simple HD sans SSD.
Alors qu'en utilisation réelle, le SSD représente peut-être 10% des accès (là je lance un chiffre au hasard), et non pas 1% (sinon, le système n'aurait aucun intérêt).
patpro ~ Patrick Proniewski
In article , pehache wrote:
On Dec 6, 11:38 am, patpro ~ Patrick Proniewski wrote: > In article , > > pehache wrote: > > Autre chose : les tests standards refl tent mal les conditions > > d'utilisation r elle de ce type de disque. Notamment les tests d'acc s > > al atoires ne veulent rien dire, car justement l'optimisation entre SSD > > et HD repose sur le fait que les acc s ne sont pas totalement al atoires > > et que certains fichiers sont lus beaucoup plus souvent que d'autres. > > ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les > blocs de manière séquentielle :) > Et c'est bien la dessus que repose les tests "random" : lire ou crire > des blocs péarpillés sur le disque.
Et c'est justement ça qui n'est pas pertinent pour un disque hybride.
Dans le cas du momentus 750Go HD + 8Go SSD (rapport de 100 environ), un test purement random va mesurer 99% du temps le temps d'accès du HD, et seulement 1% du temps le temps d'accès du SSD. Et conclure que le temps d'accès moyen est quasiment le même que pour un simple HD sans SSD.
Alors qu'en utilisation réelle, le SSD représente peut-être 10% des accès (là je lance un chiffre au hasard), et non pas 1% (sinon, le système n'aurait aucun intérêt).
Je suis d'accord, mais là ça dépend essentiellement de ce que tu fais faire au logiciel de benchmark. Les tests synthétiques (je crois que c'est le terme) visent à simuler un usage réel en collectant les métriques d'usage de logiciels réels, ou en simulant les schémas de fonctionnement de ces logiciels. Ils sont sans doute plus intéressants dans ce cas de figure que les benches brutes à base d'IOMeter.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
In article
<302fa833-b64f-4a76-9574-9a6065de27a8@t16g2000vba.googlegroups.com>,
pehache <pehache.7@gmail.com> wrote:
On Dec 6, 11:38 am, patpro ~ Patrick Proniewski
<pat...@boleskine.patpro.net> wrote:
> In article <9k621dF56...@mid.individual.net>,
>
> pehache <pehach...@gmail.com> wrote:
> > Autre chose : les tests standards refl tent mal les conditions
> > d'utilisation r elle de ce type de disque. Notamment les tests d'acc s
> > al atoires ne veulent rien dire, car justement l'optimisation entre SSD
> > et HD repose sur le fait que les acc s ne sont pas totalement al atoires
> > et que certains fichiers sont lus beaucoup plus souvent que d'autres.
>
> ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les
> blocs de manière séquentielle :)
> Et c'est bien la dessus que repose les tests "random" : lire ou crire
> des blocs péarpillés sur le disque.
Et c'est justement ça qui n'est pas pertinent pour un disque hybride.
Dans le cas du momentus 750Go HD + 8Go SSD (rapport de 100 environ),
un test purement random va mesurer 99% du temps le temps d'accès du
HD, et seulement 1% du temps le temps d'accès du SSD. Et conclure que
le temps d'accès moyen est quasiment le même que pour un simple HD
sans SSD.
Alors qu'en utilisation réelle, le SSD représente peut-être 10% des
accès (là je lance un chiffre au hasard), et non pas 1% (sinon, le
système n'aurait aucun intérêt).
Je suis d'accord, mais là ça dépend essentiellement de ce que tu fais
faire au logiciel de benchmark.
Les tests synthétiques (je crois que c'est le terme) visent à simuler un
usage réel en collectant les métriques d'usage de logiciels réels, ou en
simulant les schémas de fonctionnement de ces logiciels. Ils sont sans
doute plus intéressants dans ce cas de figure que les benches brutes à
base d'IOMeter.
patpro
--
Je cherche à changer d'air -> http://www.patpro.net/cv
On Dec 6, 11:38 am, patpro ~ Patrick Proniewski wrote: > In article , > > pehache wrote: > > Autre chose : les tests standards refl tent mal les conditions > > d'utilisation r elle de ce type de disque. Notamment les tests d'acc s > > al atoires ne veulent rien dire, car justement l'optimisation entre SSD > > et HD repose sur le fait que les acc s ne sont pas totalement al atoires > > et que certains fichiers sont lus beaucoup plus souvent que d'autres. > > ce n'est pas parce que tu lis toujours les memes fichiers que tu lis les > blocs de manière séquentielle :) > Et c'est bien la dessus que repose les tests "random" : lire ou crire > des blocs péarpillés sur le disque.
Et c'est justement ça qui n'est pas pertinent pour un disque hybride.
Dans le cas du momentus 750Go HD + 8Go SSD (rapport de 100 environ), un test purement random va mesurer 99% du temps le temps d'accès du HD, et seulement 1% du temps le temps d'accès du SSD. Et conclure que le temps d'accès moyen est quasiment le même que pour un simple HD sans SSD.
Alors qu'en utilisation réelle, le SSD représente peut-être 10% des accès (là je lance un chiffre au hasard), et non pas 1% (sinon, le système n'aurait aucun intérêt).
Je suis d'accord, mais là ça dépend essentiellement de ce que tu fais faire au logiciel de benchmark. Les tests synthétiques (je crois que c'est le terme) visent à simuler un usage réel en collectant les métriques d'usage de logiciels réels, ou en simulant les schémas de fonctionnement de ces logiciels. Ils sont sans doute plus intéressants dans ce cas de figure que les benches brutes à base d'IOMeter.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
yapu
SbM wrote:
> Mais je pense que FMP aussi tape directement dans le disque, et que > toutes les bases de données le font, sinon je ne vois pas comment ils > pourraient gérer des tables de dizaines de GO.
Quel problème cela pourrait-il poser ?
le comprtement de tous ces caches n'est pas forcement adapté au fonctionnement des bases de données et des autres logiciels qui tapent directement dans les secteurs de ce qu'ils croient etre le disque. -- Philippe Manet en fait, c'est manet avant @
SbM <sebastienmarty@yahoo.fr> wrote:
> Mais je pense que FMP aussi tape directement dans le disque, et que
> toutes les bases de données le font, sinon je ne vois pas comment ils
> pourraient gérer des tables de dizaines de GO.
Quel problème cela pourrait-il poser ?
le comprtement de tous ces caches n'est pas forcement adapté au
fonctionnement des bases de données et des autres logiciels qui tapent
directement dans les secteurs de ce qu'ils croient etre le disque.
--
Philippe Manet
en fait, c'est manet avant @
> Mais je pense que FMP aussi tape directement dans le disque, et que > toutes les bases de données le font, sinon je ne vois pas comment ils > pourraient gérer des tables de dizaines de GO.
Quel problème cela pourrait-il poser ?
le comprtement de tous ces caches n'est pas forcement adapté au fonctionnement des bases de données et des autres logiciels qui tapent directement dans les secteurs de ce qu'ils croient etre le disque. -- Philippe Manet en fait, c'est manet avant @
sebastienmarty
Philippe Manet wrote:
SbM wrote:
> > Mais je pense que FMP aussi tape directement dans le disque, et que > > toutes les bases de données le font, sinon je ne vois pas comment ils > > pourraient gérer des tables de dizaines de GO. > > Quel problème cela pourrait-il poser ?
le comprtement de tous ces caches n'est pas forcement adapté au fonctionnement des bases de données et des autres logiciels qui tapent directement dans les secteurs de ce qu'ils croient etre le disque.
Pas compris, mais je dois manquer des compétences nécessaires.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
Philippe Manet <yapu@invivo.edu> wrote:
SbM <sebastienmarty@yahoo.fr> wrote:
> > Mais je pense que FMP aussi tape directement dans le disque, et que
> > toutes les bases de données le font, sinon je ne vois pas comment ils
> > pourraient gérer des tables de dizaines de GO.
>
> Quel problème cela pourrait-il poser ?
le comprtement de tous ces caches n'est pas forcement adapté au
fonctionnement des bases de données et des autres logiciels qui tapent
directement dans les secteurs de ce qu'ils croient etre le disque.
Pas compris, mais je dois manquer des compétences nécessaires.
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)
> > Mais je pense que FMP aussi tape directement dans le disque, et que > > toutes les bases de données le font, sinon je ne vois pas comment ils > > pourraient gérer des tables de dizaines de GO. > > Quel problème cela pourrait-il poser ?
le comprtement de tous ces caches n'est pas forcement adapté au fonctionnement des bases de données et des autres logiciels qui tapent directement dans les secteurs de ce qu'ils croient etre le disque.
Pas compris, mais je dois manquer des compétences nécessaires.
-- [SbM] <http://sebastienmarty.free.fr> - <http://tradintosh.free.fr> <http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr> "If the French were really intelligent, they'd speak English" (W. Sheed)
contact
Pierre-Olivier TAUBATY wrote:
mmmmouais, sauf que dans les applis, ya un truc qui s'appelle Safari, et qui écrit un max de truc dans son dossier de cache. Y a qu'à voir le trucs monstrueux que Time Machine peut sauvegarder des fois, et ça concerne quasi tout le temps Safari et son cache ...
On peut imposer à Safari de ne pas utiliser de cache. Cela fait, je ne vois pas de ralentissement lors de surfs intensifs sur le web. -- A+
mmmmouais, sauf que dans les applis, ya un truc qui s'appelle Safari, et
qui écrit un max de truc dans son dossier de cache. Y a qu'à voir le
trucs monstrueux que Time Machine peut sauvegarder des fois, et ça
concerne quasi tout le temps Safari et son cache ...
On peut imposer à Safari de ne pas utiliser de cache.
Cela fait, je ne vois pas de ralentissement lors de surfs intensifs sur
le web.
--
A+
mmmmouais, sauf que dans les applis, ya un truc qui s'appelle Safari, et qui écrit un max de truc dans son dossier de cache. Y a qu'à voir le trucs monstrueux que Time Machine peut sauvegarder des fois, et ça concerne quasi tout le temps Safari et son cache ...
On peut imposer à Safari de ne pas utiliser de cache. Cela fait, je ne vois pas de ralentissement lors de surfs intensifs sur le web. -- A+
Romer
Philippe Di Valentin
Le 07/12/11 18:42, Bernd a écrit :
On peut imposer à Safari de ne pas utiliser de cache.
Cache Safari verrouillé ici.
Cela fait, je ne vois pas de ralentissement lors de surfs intensifs sur le web.
Aucun en effet!!!
Le 07/12/11 18:42, Bernd a écrit :
On peut imposer à Safari de ne pas utiliser de cache.
Cache Safari verrouillé ici.
Cela fait, je ne vois pas de ralentissement lors de surfs intensifs sur
le web.
> On peut imposer à Safari de ne pas utiliser de cache.
Cache Safari verrouillé ici.
> Cela fait, je ne vois pas de ralentissement lors de surfs intensifs sur > le web.
Aucun en effet!!!
par curiosité, vous avez une connexion ADSL à quelle vitesse ?
-- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
pas.de.spam
Philippe Manet wrote:
pehache wrote:
> > 2- le prix de 12 go de ram sur les machines qui reste, serait bien plus > > profitablement investit dans un SSD. Pour la majorité des utilisateurs, > > 4 Go sont à peine utilisés, et doubler à 8 ne leur apporte strictement > > aucun gain. > > > > Ce n'est pas tout à fait vrai : la RAM sert aussi de cache disque, donc > elle est utilisé même si on a peu d'applis ouvertes.
d'abord, il faut dire de quoi on parle comme machine :
sur un G5, avec 6 Go, c'est franchement trop meme avec une utilisation très lourde et un uptime de 60 jours ; mais 4 Go c'était parfois limite.
En revanche, il me semble qu'un Intel a besoin de plus de RAM (avec 4 Go en 2 jours d'utilisation amateur j'ai déjà frolé la limite). Et je crois qu'en 64 bits c'est pire.
actuellement, sur mon Mac Pro, uptime de 33 j 1/2, 2 fichiers de swap (128 Mo au total, 8 utilisés). Avec ses 16 Go de Ram, il ne swappe quasiment plus. Par contre avec 8 Go, il swappe beaucoup (j'ai tourné pendant 15 jours, après réception de mon Mac Pro après mon déménagement, où un riser était apparemment mal reconnu, et je n'avais que 8 Go). -- PO.
Pour m'écrire : po_taubaty(arobas)yahoo(point)fr
Philippe Manet <yapu@invivo.edu> wrote:
pehache <pehache.7@gmail.com> wrote:
> > 2- le prix de 12 go de ram sur les machines qui reste, serait bien plus
> > profitablement investit dans un SSD. Pour la majorité des utilisateurs,
> > 4 Go sont à peine utilisés, et doubler à 8 ne leur apporte strictement
> > aucun gain.
> >
>
> Ce n'est pas tout à fait vrai : la RAM sert aussi de cache disque, donc
> elle est utilisé même si on a peu d'applis ouvertes.
d'abord, il faut dire de quoi on parle comme machine :
sur un G5, avec 6 Go, c'est franchement trop meme avec une utilisation
très lourde et un uptime de 60 jours ; mais 4 Go c'était parfois limite.
En revanche, il me semble qu'un Intel a besoin de plus de RAM (avec 4 Go
en 2 jours d'utilisation amateur j'ai déjà frolé la limite).
Et je crois qu'en 64 bits c'est pire.
actuellement, sur mon Mac Pro, uptime de 33 j 1/2, 2 fichiers de swap
(128 Mo au total, 8 utilisés). Avec ses 16 Go de Ram, il ne swappe
quasiment plus. Par contre avec 8 Go, il swappe beaucoup (j'ai tourné
pendant 15 jours, après réception de mon Mac Pro après mon déménagement,
où un riser était apparemment mal reconnu, et je n'avais que 8 Go).
--
PO.
> > 2- le prix de 12 go de ram sur les machines qui reste, serait bien plus > > profitablement investit dans un SSD. Pour la majorité des utilisateurs, > > 4 Go sont à peine utilisés, et doubler à 8 ne leur apporte strictement > > aucun gain. > > > > Ce n'est pas tout à fait vrai : la RAM sert aussi de cache disque, donc > elle est utilisé même si on a peu d'applis ouvertes.
d'abord, il faut dire de quoi on parle comme machine :
sur un G5, avec 6 Go, c'est franchement trop meme avec une utilisation très lourde et un uptime de 60 jours ; mais 4 Go c'était parfois limite.
En revanche, il me semble qu'un Intel a besoin de plus de RAM (avec 4 Go en 2 jours d'utilisation amateur j'ai déjà frolé la limite). Et je crois qu'en 64 bits c'est pire.
actuellement, sur mon Mac Pro, uptime de 33 j 1/2, 2 fichiers de swap (128 Mo au total, 8 utilisés). Avec ses 16 Go de Ram, il ne swappe quasiment plus. Par contre avec 8 Go, il swappe beaucoup (j'ai tourné pendant 15 jours, après réception de mon Mac Pro après mon déménagement, où un riser était apparemment mal reconnu, et je n'avais que 8 Go). -- PO.
