Hola :) El Thursday 18 September 2008, Juan Erbes escribió: [...]
Es decir, tengo una MoBo (o blade) con 2 sockets y 4 ranuras de expansi�n de memoria para cada socket. Lleno las 8 ranuras de expansi�n con RAM. Si quiero a�adir m�s RAM, pueden ocurrir dos cosas:
- si tengo procesadores _SIN_ controlador de memoria, a�ado otro blade (o MoBo) que _S�LO_ contiene ranuras de expansi�n de RAM y ampl�o la RAM, no es necesario ampliar el n�mero de CPUs
El controlador de memoria del blade, en este caso, no consume energia y no genera calor? O es una placa boba sin ningun chip?
Es "casi boba" en el sentido de qu elo �nico que tiene es: controlador de memoria + RAM, no tiene elemento CPU ni FPU ni coprocesador alguno (aka: GPGPU, GPU, Cell, ...). Y el consumo que tiene es MUCHO menor que una CPU dual o quad core. Si las comparamos, es casi imperceptible.
Lo que citas de la ampliaci�n de memoria, si tienes todos los zocalos de memoria ocupados, se soluciona reemplazando los modulos de memoria existentes por otros de mayor capacidad.
Y, �qu� hacemos cuando hemos utilizado el m�dulo de memoria m�ximo y tenemos todos los slots ocupados? �Compramos una m�quina nueva? Esta soluci�n es a�n m�s cara ya que: - tienes otra m�quina m�s - otro sistema operativo que gestionar - una aplicaci�n clusterizada que gestionar - m�s tr�fico de red - una nueva red - m�s calor - m�s fr�o que suministrar - m�s consumo energ�tico - ...
Es como si me obligan a comprarme el traje entero s�lo porque la camisa me est� peque�a.
Ya que NUMA nos brinda la posibilidad de no necesitar que la RAM y la CPU est�n estrechamente asociadas ... aprovech�moslo en aquellos casos en que sea �til.
No dices que sistema de interconexi�n utilizan esas memorias externas, ni del cuello de botella que produce el tener que acceder a memoria externa, pero de manera mas lenta que en una conexi�n de alta velocidad como el HyperTransport.
Aquí hay que diferenciar dos situaciones: 1.- tiempo de acceso, anchos de banda, latencias, ... entre RAM local y la CPU 2.- tiempo de acceso, anchos de banda, latencias, ... entre RAM remota y la CPU Los dos casos _NO_ son comparables. Antes de comparar nada, vamos a ponernos ante la misma situación: 1.- Intel aún no tiene CPUs con controlador de memoria integrado en CPU 2.- AMD sí tiene Comparando el acceso a memoria LOCAL desde la CPU, tenemos: AMD: si no me equivoco, que me corrijan los que se lo sepan mejor: System Bus Bandwidth: 5.3 GB/s Memory Addressing: 1 TB RAM Intel Itanium System Bus Bandwidth: 6.4 GB/s Memory Addressing: 1024 TB RAM Esto sería "en la propia placa base". En el caso que preguntas tú, es decir, CPU - RAM remota (es decir: entre una placa base y otra en un sistema NUMA). Te puedo dar los datos de SGI (los de los otros fabricantes no los tengo a mano y es mejor que hablen ellos por sí mismos): Nuestra conexión se llama NUMAlink Ancho de banda: 3.2 GB/s unidireccional por conexión, teniendo en cuenta que hay dos conexiones bidireccionales entre cada blade, el ancho de banda es de 6.4 GB/s por cada dirección. Es decir: 6,4 GB/s del blade A al blade B y 6.4 GB/s del blade B al blade A. En cuanto a latencias, tenemos una latencia MPI menor a 1 microsegundo
http://www.novell.com/collateral/4621437/4621437.pdf L I M I T A T I O N S A N D O U T L O O K On a bigger system, there is normally a hierarchy in the interconnect. This means that neighboring nodes can be accessed more quickly than remote nodes. NUMA API currently represents the system as a flat set of nodes. Future versions will allow the application to query node distances. Future versions of NUMA API may also allow setting a policy on the file cache.
En cuanto al acceso a los diferentes nodos, esto es una generalidad que ha puesto Novell. En función de la topología (torus, fat tree, hypercube, estrella, ...) las latencias, el número de hops, los anchos de banda, precios, ... cambian.
Un link con + info sobre el tema: http://www.open-mag.com/00133844923.shtml http://www.open-mag.com/features/Vol_117/EM64T/EM64T.htm http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/432 37-A_AMD64_and_solidDB_White_paper_PDF.pdf
¿Y? Son benchmarks ... no sé si leíste mi opinión acerca de las estadísticas (aka benchmarks) en un hilo anterior. Tampoco sé si leíste mi opinión acerca de los benchmarks (por si no lo has leído, te pego el link): http://www.muylinux.com/2008/06/12/mentiras-malditas-mentiras-y-benchmarks/ También te pego otro que escribí sobre NUMA: http://www.muylinux.com/2008/05/21/numa-es-gran-desconocido/ Por si no lo quieres leer entero, en el último párrafo escribo: "Muy importante, NUMA no es la solución a todos nuestros problemas, igual que no lo es un cluster." No seas tan radical Juan, en este hilo no he dicho que AMD sea mejor que Intel o al revés, ni he dicho que incluir el controlador de memoria sea bueno o malo, ni he dicho que AMD o Intel hagan o no hagan NUMA, ni que NUMA sea mejor que UMA, ... Me da la impresión que crees que te estoy corrigiendo o que intento demostrar que estás equivocado o algo así. No es así. Lo que digo es que no es necesario tener el controlador de memoria en la CPU para hacer NUMA. Eso no es ni bueno ni malo. La definición/diseño de NUMA no exige eso, ni tampoco lo necesita. Es como si me dices que para que sea un traje debe llevar corbata. Un traje es una chaqueta + pantalón, la corbata es un accesorio. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org