Re: Question about ram

From: Robert Brockway (rbrockway_at_opentrend.net)
Date: 03/30/05

  • Next message: tom: "wine help" 
    Date: Wed, 30 Mar 2005 14:14:47 -0500 (EST)
To: debian-user@lists.debian.org

    On Wed, 30 Mar 2005, Helge Tore Høyland wrote:

    > What would be the speediest solution?
    >
    > 1. 512MB 333MHz ram
    > 2 768MB 266MHz ram

    It depends on how much memory you'll typically be using, and how.

    The more memory you use for applications the less will be available for
    cache. So you are more likely to hit cached files with more memory - this
    will result in faster file accesses despite having slower RAM.

    If you use so much that the system swaps regularly then any advantage of
    the faster memory will be swamped by the delays in swapping.

    A suggestion with no guarantee: If you expect to regularly use up to 300MB
    for applications then 512MB of faster memory may be better. If you expect
    to regularly use more than 300MB for applications then 768MB of slower
    memory may be better.

    This is a gut feel and is not based on a serious analysis.

    A proper assessment of system performance is very indepth and requires
    knowledge of the hardware and the expected uses of the machine.

    I was assuming here that you're intending to use the system as a general
    purpose workstation with a few services running (ie, a typical Linux box
    accessing the net).

    Rob 

    -- 
Robert Brockway B.Sc.
Senior Technical Consultant, OpenTrend Solutions Ltd.
Phone: 416-669-3073 Email: rbrockway@opentrend.net http://www.opentrend.net
OpenTrend Solutions: Reliable, secure solutions to real world problems.
Contributing Member of Software in the Public Interest (http://www.spi-inc.org)
-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: tom: "wine help"

    Relevant Pages

    • Re: xmalloc string functions
      ... require memory allocations depending on the way the system works. ... If the toolkit being used is not one of those, then it is irrelevant that some provide a means to do so, particularly if the "some" are not available for the platform being targeted. ... Not enough context for most real-world applications to recover at this point. ... At this point g_malloccalling abortbecomes a moot point, particularly if your auto-save code is robust against memory allocation errors. ...
      (comp.lang.c)
    • Re: ProDOS Plus
      ... operating system was not considered worth the problems when it was just as easy to make the applications support 128k or more ram. ... your suggested P-code system could do something similar by running in the aux 64k memory range $D000...FFFF or perhaps the aux ram used by the P8 /ram driver code space. ... the OS could fit in *only* the space that ProDOS now occupies. ... if practicality were a concern we probably wouldn't be using old hardware. ...
      (comp.sys.apple2)
    • Re: xmalloc string functions
      ... If these were the only choices (crashing applications or a frozen ... trying to malloc some rediculously large amount of memory - e.g. in the ... because their malloc wrapper decided to exit. ... Exiting on malloc failure makes sense for a utility like sort. ...
      (comp.lang.c)
    • Re: xmalloc string functions
      ... require memory allocations depending on the way the system works. ... Not enough context for most real-world applications to ... It is /more/ reliable to routinely auto-save the user's work (as you ... particularly if your auto-save code is robust against memory allocation ...
      (comp.lang.c)
    • RE: DLLHOST.EXE and Secure Server Crash
      ... This is a very common problem with COM+ components and IIS. ... | Applications view switch to Status View) ... |>with 2-3 dedicated SSL servers. ... A symptom of the problem centers around memory ...
      (microsoft.public.inetserver.iis.security)