Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.electronics.design > #454372

Re: Memory

Show all headers | View raw

On 3/31/2017 12:01 AM, Martin Brown wrote:
> On 30/03/2017 22:18, Don Y wrote:
>> I'm rebuilding an older server to act as my compile farm.  So, digging
>> through
>> my box of RAM to see what I can find that fits the bill.
>>
>> The documents for the machine indicate (emphasis mine):
>>
>>     DIMMs should be installed in matched sets of four. This enables
>>     quad-channel operation and provides the highest memory bandwidth.
>> The sets
>>     of four must be MATCHED IN SIZE, RANK and ORGANIZATION. This
>> information
>>     can normally be found on the FBD label. For example, the label of
>> each FBD
>>     in a set of four might read: 1G 2R x8, in which 1G represents the
>> size of
>>     the memory module, 2R represents the number of ranks, and x8 represents
>>     the organization.
>
> You can always mount them and then see what SPD finds. What it says is
> generally true that putting odd sized ones in will be the worst possible
> performance (might not even work on some chipsets) pairs are better and on some
> boards quads are (slightly) better still.
>
> If you care about ultimate memory bandwidth performance then you try hard to
> meet these criterion, but it can be expensive to get that last 5-10% and with
> modern on chip multi level cache not always worthwhile.

Your missing the point.

How does <anyone> USING THE INSTRUCTIONS QUOTED HERE satisfy these "two"
constraints?  They don't differ:  "matched" "rank" "size" "organization".

My complaint is with the *text*.

> Superfast (aka gaming) ram is generally not worth the extra money.
>>
>> It goes on to say:
>>
>>     They can also be installed in pairs of two; in this case, the computer
>>     will continue to operate, but with a slight reduction in
>> performance. The
>>     pairs must be MATCHED IN SIZE, RANK and ORGANIZATION.
>>
>> Of course, the SPD devices contain far more information than that outlined,
>> above.  So, its possible that devices can bear the same descriptive
>> labeling
>> yet not be matched *enough* to satisfy the first (vague!) criteria.
>
> What tends to happen if they are the same size, rank and organisation but
> different speeds is that the system runs to match the slowest (rather than not
> running at all).

But you can *state* that speed is another constraint that must be "matched".
I.e., 10600 and 6400 are very obviously different speed devices.

But, are 8G, 2R, x8 PC10600 DIMMs from 4 different vendors a "match"?
Or, do they need to be from the same vendor?  Lot code?  etc.?

I.e., which bytes of the SPD are "don't care" in terms of determining
a correct "match"?  How does Joe IT know that ALL of those necessary
bytes are in agreement for any particular set of devices?

>> Would not a better way of differentiating between these two (descriptively
>> IDENTICAL) sets of criteria been to refer to "having identical part
>> numbers"
>> in the first case and "compatible *descriptions*" in the second?  I.e.,
>> there
>> are obviously more constraints at work in the first case that aren't
>> highlighted in the description that is provided (which is identical to
>> that of the second case).
>
> I prefer pairs or quads from the same maker and batch that way you don't get
> any nasty surprises.

But the *text* doesn't claim that to be a requirement.

>> [It would also be nice if the user had a way of knowing that he had/hadnot
>> met those criteria as "a slight reduction in performance" is probably not
>> the sort of objective symptom that most users could evaluate!]
>
> SPD will tell you enough but otherwise write a memory intensive program or run
> a well known memory speed benchmark program to verify results.

Well, we *know* the SPD contents won't be identical -- cuz they contain
"vendor specific" information!

I.e., "matched" is a vague constraint.

Back to sci.electronics.design | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-30 14:18 -0700
  Re: Memory John Fields <jfields@austininstruments.com> - 2017-03-30 19:12 -0500
    Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-30 17:27 -0700
  Re: Memory whit3rd <whit3rd@gmail.com> - 2017-03-30 17:50 -0700
    Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-30 18:02 -0700
      Re: Memory whit3rd <whit3rd@gmail.com> - 2017-03-30 20:40 -0700
        Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-30 23:55 -0700
      Re: Memory Martin Brown <'''newspam'''@nezumi.demon.co.uk> - 2017-03-31 08:44 +0100
        Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-31 01:51 -0700
          Re: Memory whit3rd <whit3rd@gmail.com> - 2017-03-31 16:39 -0700
  Re: Memory Martin Brown <'''newspam'''@nezumi.demon.co.uk> - 2017-03-31 08:01 +0100
    Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-31 01:42 -0700
      Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-31 12:11 -0700
        Re: Memory Don Y <blockedofcourse@foo.invalid> - 2017-03-31 12:15 -0700

csiph-web