Are you liking that dual-channel operation already? Wondering how you ever lived without it? 
Ughā¦wish I read this before buying the HyperX CL11 2x8 gig kit. Will return for a 2x4 kitā¦ughh!
I wish Synology would just tell us about memory options.
Oh yeah! Itās amazing! =)
@ChuckPA said:
The J3455 CPU can only address and USE 8GB of ram, not 16Intel Celeron Processor J3455 2M Cache up to 2.30 GHz Product Specifications
I just saw this, and the advisory on the home page of this forum as I came to find out if the 6.2 upgrade is safe. Intel is somewhat dodgy about the statement, noting only that itās a SOC so support is up to the manufacturers, meanwhile loads of boards with J3455 chips are stating 16GB support and Synology has been reporting 16GB (and supposedly using it) since my original post.
Iām old enough to remember the days of 32bit OSes and āX installed Y in useā since it was not addressable but this seems really odd to me that 8GB is the maximum and yet everything is showing 16GB. There was even a user on the Syno forums installing 32GB and having it recognized.
Doesnāt seem that Intel could reasonably allow the system to see 16GB and only utilize 8, or somehow how swap address space around in real time?
It has nothing to do with Intel. The amount of memory on a DIMM is reported by the SPD chip.
Synology queries the SPD chips. If both chips report 8 then 8 + 8 = 16.
End of mystery
@ChuckPA said:
It has nothing to do with Intel. The amount of memory on a DIMM is reported by the SPD chip.
Synology queries the SPD chips. If both chips report 8 then 8 + 8 = 16.
End of mystery
Even if the SPD queries 16 gig that does not mean that all 16 gig will be used by DSM correct?
@ChuckPA said:
It has nothing to do with Intel. The amount of memory on a DIMM is reported by the SPD chip.
Synology queries the SPD chips. If both chips report 8 then 8 + 8 = 16.
End of mystery
Yea I guess I still donāt understand how that relates to me seeing this:
Is it that:
A) It sees and is using 16GB and thatās good
B) It sees and is using 16GB but thatās bad because some magical register shifting is going on to do so
C) It sees but cannot use 16GB and it simply appears itās using it but the OS is doing some extra work here
D)?
Iām not trying to be difficult, I am curious if installing 2x8gb is worse than 2x4gb or if 2x8gb is actually roughly the same as 2x4gb.
I donāt understand if itās not supported why itās showing up as though itās there and if itās not using it how that works and is there a performance penalty for having it operate that way.
Buying 2x 8GB is usually more expensive than 2x 4GB and therefore A. Unncessary and B. Misleading because NONE of the 2nd 8GB will ever be used
There is the problem. Youāll lulled into a false sense of security if you see 7GB used and have forgotten you only have 1GB left which the processor can use
@SteveFP said:
@ChuckPA said:
It has nothing to do with Intel. The amount of memory on a DIMM is reported by the SPD chip.
Synology queries the SPD chips. If both chips report 8 then 8 + 8 = 16.
End of mysteryEven if the SPD queries 16 gig that does not mean that all 16 gig will be used by DSM correct?
Steve,
It doesnāt matter if 2x 64GB were detected, only the first 8GB would be addressable and usable by the processor.
This is the danger Iām trying to convey to everyone:
- Waste of funds
- False sense of security
- Untested/unknown behavior when the system truly runs out of memory
Hi ChuckPA, apologies for resurrecting this thread. Iāve been researching this quite a bit and I had been thinking that Intelās 8GB max was final. Then I saw this thread on Reddit:
User ssps created a script to allocate and lock a user-specified amount of RAM, fill it with random numbers, and then verify the checksum. Other people have reported successfully locking up to 12GB of RAM.
Itās worth reiterating sspsā comment:
āHowever note, that even if it works it does not really mean much. Intels and Synology limit this product to 8Gb. While this may be just a product segmentation as opposed to technical limitation ā the consequence is that this configuration did not receive the same amount of testing (of any) and hence is not safe to use.ā
What do you reckon?
The kernel reads the sizes stored in the DIMMs SPD chips.
This is what DSM is displaying.
There is no way the processor can address it. Look at the processor address line pins and do the math. You will count 32 address lines.
I tell everyone to NOT overload addressable memory because if the OS thinks it has 16GB, attempts to wire memory to non-existent physical memory addresses, it will overwrite something critical and cause corruption.
From the Intel datasheet.
I show LPDDR here because it is not encumbered by the multiplexed strobing used for DDR3L.
The processor will address both DDR3L and LPDDR
Thanks ChuckPA - this makes sense! So the script that ssps created is fooled by the report from the SPD chips that there is 16GB available, just the same way DSM is fooled?
Yes. Unfortunately there is no real way to do this unless the kernel maintains a memory size max for each CPU and then indexes off that identifier at boot.
In order to keep the Linux kernel more pure, the better solution is for each kernel team to make adjustment(s) for their product(s).
Sorry but you are most likelly wrong. It seems likelly that the CPU supports up to a total of 16GB of RAM.
Check out e.g. Gigabyte GA-J3455N-D3H. The manual states that it supports 16GB of RAM.
The manual: GA-J3455N-D3H
And e.g. the Asus J3455M-E states the following in the manual:
Due to the chipset limitation, we recommend that you use single-sided 4GB or 8GB, or double-sided 8GB DDR3 per DIMM slot. The maximum memory for the two DIMM slots is 16GB.
Do I need to find more?
This is the source I quote. It is their processor after all.
Obviously Intel and Gigabyte have a disagreement.
Your assertion that 2x 8GB works is, knowing the kernel as I do, the effect of reading the SPD chip on each DIMM and adding the sum. It may indeed show more but the CPU can only address 8GB
I have just been looking the datasheet for IntelĀ® PentiumĀ® and CeleronĀ® Processor N- and J- Series
and it states 8GB as a āMaximum Total System Capacityā. See page 63.
Also the Intel NUC with the J3455 CPU is also limiter to 8GB as the maximum.
Okay, sorry!
It seems likelly that you are correct.
(Thanks for saving me money)
Youāre welcome.
Iāve been a system and kernel developer for 30+ years now. 
Should you wish to experiment, I offer this code fragment to learn and further your knowledge.
You will need the Synology SDK and ToolChains to compile natively on DSM.
Here is what Iāve handed out in class as an assignment to complete
/*
* In this exercise, we will allocate kernel memory.
*
* Your task:
* Successfully allocate 14 GB of kernel memory, handling all error conditions
* Verify memory is valid.
* Handle the removal of memory without recompiling code.
*
*/
#define BUF_LEN (1048576 * 1024)
#define NBUF 14
char *buf[NBUF];
for (i=0; i<NBUF; i++) {
/* we want DMA-capable memory,
* and we can sleep if needed */
buf[i] = kmalloc(BUF_LEN, GFP_DMA | GFP_KERNEL);
if (!buf[i]) {
printf("ERROR: Cannot allocate block %d\n", i+1);
for (int j=0; j<i; j++) kfree(buf[i]);
exit();
}
/* Now start writing to each block and verify the readback (simple memtest-pages style)
}
