I'm looking at the Pegasos 8641D from a server user perspective.
My expectations are that the system will be much more powerfull than the Pegasos I/II.
I assume that the faster CPU and the much faster memory will give a very nice performance boost. Looking at the spec and freescale pdf, I think the Peg 8641 will give a verz nice database server.


A very important question for me now is:

What will be the max amount of memory that can be used in it?
I think the Freescale documents seem to target a 32 Gigabyte?
Is this reachable and supported by the Firmware atm?

For me it would be very important to use more than 2 GB.
I'm hoping for a minimum of 3 GB, will this be possible?

Is there a difference between the max physical memory expensation and the max memory that will be useable under Linux?

Cheers
Gunnar

Another limiting factor when it comes to this kind of amount of memory is the amount of memory slots on the motherboard. The Pegasos 8641D will have 2x2 of them. Are there even 8GB DDR2 memory modules in existence? At least I haven't seen any through the channels I usually use to look for computer gear. The most common one is 1GB modules, and 2GB modules can also be obtained quite easily. But 8GB?

Well, that particular image is of the Argo Navis reference board (Freescale's design). The Pegasos 8641D should have at least the capability to support the same amount of memory, you're right depending on memory module size.

8GB modules cost anything between $3500 and $6500. If you really needed that kind of memory you're looking at quite an invoice.

What could be one goal is to have each memory controller support 4GB to 8GB on the board, this means an ASMP server (processors running two different OS, maybe virtualised) could have the full 32-bit range to itself, one on each controller. 2GB modules are around $250 :)

There is a problem that CHRP, PCI specifications and suchlike do not support more than 2GB (since peripherals and IO are usually mapped there) and the memory map would have to be split. Linux calls this a sparse memory map. While ppc64 supports this functionality (it has to for POWER and the G5), I am fairly sure that the 32-bit support does not.

Someone would have to fix that up :)

_________________
Matt Sealey

.

Do I read this correct?
2x2 slots means that 8 GB of memory will be ease to physically to equip using normal 2GB modules.

Does this mean that with the current firmware 2 GB is the limit?

I feel its important to change this.
The times that 640 KB, err 2GB are enough for everbody are over. :)

I want to explain why I think supporting more than 2 GB is crucial. A database server with 2.0 GB of memory can max buffer about 1.7 GB of database size. If your database is bigger than this then you will have constant IO/harddisk access.

If you have a very busy database server with a database of for example 2.0 GB size then its too big to fit in the buffers. Having 2 GB main memory or 3 GB main memory will make a 10 times performance difference in this case.
So for $100 more memory you will get a 10 times faster system!

Looking at the market, the percentage of database of up to 4 GB of size is very big. If the Peg 8641D could support this market secment this would be great.

Fixing sounds good.
Do I understand it right, do you plan to support at least 4-8 GB ?

BTW How do other 32bit systems solve this?
There are plenty of 32bit Pentium 4 machines supporting 8 GB of memory.

Can we get a similar functionality?


Cheers

Pegasos II supports 8GB if you can find two cheap 4GB modules. You can only map the first 2GB as memory in Open Firmware. PCI sits at the second 2GB. On the G5 any further memory is mapped past the 4GB boundary so it's in two chunks.

On Pegasos II it would be possible to use the further 6GB via the Marvell DMA controller as a block device (super-swap) or some other clever method of using it for database apps. Using on that board with real memory wouldn't be possible as the Pegasos doesn't have the extra 4 address lines for 36-bit mode connected up on the CPU card.

Like I said though; ppc32 doesn't support it on Linux (either method, or 36-bit addressing on 32-bit chips like the AMCC SoCs or G4 :), as far as I have seen.
I think it would be a waste not to these days. The problem of connecting address lines is gone on the 8641D (internal memory bus) so your problem is all software - how do you present the memory map and how do you make your software use it?
G4 suppports the same 36-bit addressing as Intel PAE, so all you need to do is support it in software.

_________________
Matt Sealey

Hi Matt,

many thanks for your answer!

Great!
Do I understand you right:
The Peg 8641 will physically support > 2GB of memory
But the High mem functionalty of PPC32 Linux does not support it?

Do I understand you right that on Linux 2 GB si the max then?
If I understood you right, does Genesi plan to get this fixed for Linux? Are you working on this?

Cheers
Gunnar

Matt,

I want to give a specific example of what my target is:
I would like to run on one Peg 8641

- 1 database server with 3 GB buffer memory
- 1 memchache server with 1 GB of cache memory
- have 1 GB memory to run a webserver
and a few dozend PHP applications servers with.
- have some more memory for OS and file system cache total ca 1 GB.




I think that the Peg 8641D has the horse power to run this all on one box. And with the above configuratoin you can run a huge website. E.g. an Amazon clone delivering some 10-100 millions of pages per day.
But I would definately need more than 2 GB of memory.

Can you tell me in laymans words:
Is the above setup possible (can several apps use 6 GB of memory together) with the Peg 8641 ?


Another option would be to split the above on two servers with 4 GB each.

Then I would run the webserver the PHP applications server and the memcache server on one machine and the database server on the second machine.
This setup would even have the advance to give me more horse power to run more PHP threads in parrallel.

But it would definately need 4 GB of memory for the database machine (3 GB for the DB and some hunderd MB for the OS).

Would this be possible today?

Cheers
Gunnar