Re: Wieviel RAM ist eigentlich sinnvoll bei i386?

From: O. Hartmann <ohartman(at)uni-mainz.de>
Date: Sat, 08 Apr 2006 12:48:12 +0200

Oliver Fromme schrieb:
> Rainer Duffner <rainer(at)ultra-secure.de> wrote:
> > wie diverse Diskussionen ja gezeigt haben ist mehr als 4 GB eher keine
> > Gute Idee.
> > Aber wieviel ist denn noch sinnvoll?
>
> Ganz einfach: Soviel, wie Du benötigst. (D.h. soviel, daß
> aktive Prozesse im Normalfall nicht rauspagen müssen).
>
> Man sollte die Größe des RAM nicht von der Architektur ab-
> hängig machen, sondern umgekehrt: Wenn Du für einen vorge-
> gebenen Anwendungsfall mehr als etwa 3 GByte RAM benötigst,
> solltest Du auf am64 gehen.
>
> Deine Frage (Subject) ergibt also eigentlich keinen Sinn.
>
> > Annahme ist, das man für diverse Prozesse (Mail, Web) logischerweise
> > möglichst viel RAM bereit halten will,
>
> Nicht möglichst viel, sondern ausreichend viel. Ich bin
> kein Anhänger davon, möglichst viel RAM in einen Rechner
> reinzuklopfen, von dem dann die meiste Zeit der größte Teil
> brachliegt.
>
> Gruß
> Olli
>

Man sollte aber auch beachten, daß ein Bedarf an 3GB RAM auf i386
Architekturen zwingend einen Ausbau auf 4GB erforderlich macht, sofern
man einen 128 Bit Dual Channel Speicherinterface nutzen möchte, auch
wenn 0,5 bis 1 GB RAM 'flöten' gehen, je nach Anzahl PCI Geräte und PCI
Option-ROMs.

Es ist zwar Off-Topic and dieser Stelle, ich verfolge diesen Thread nun
mit großem Interesse und er deckt eine generelle 'Schwäche' der AMD64
Architektur auf, wie sie dieser Tage realisiert wird. Durch die
Verwendung vieler 32 Bit Geräte, wie PCI oder AC97-Codec bzw. diverse
IEEE-1694 Chips oder Super-IO Chips sind ohne größere Tricks sowieso
nicht mehr als 4 GB RAM sinnvoll. War nicht selbst AMDs Referenz Chipset
der 8000er Serie nicht ganz 64 Bit sauber? Der USB Controller hatte doch
so seine 32-Bit Limitation.

Oliver

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 08 Apr 2006 - 12:49:21 CEST

search this site