[opensuse-es] Escalabilidad de Linux en el mundo NUMA
Otra vez NUMA, en un articulo publicado por LinuxWorld: Les dejo una parte del articulo traducida: Numa (NUMA): como el número de procesadores en un sistema aumenta, el ancho de banda total entre los procesadores y la memoria también aumenta. La construcción de una interconexión simétricos que pueden proporcionar el ancho de banda que se hace cada vez más caro. Una solución es un tipo de sistema conocido como NUMA (Non-Uniform Memory Access). Un sistema NUMA conecta los procesadores y los bancos de memoria de esta manera: * Conectar directamente algunos procesadores (o local) a algunos bancos de memoria. * Proporcionar un método de transmisión de datos para el acceso a bancos de memoria para los procesadores no están directamente vinculadas a bancos de memoria. Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores han integrado los controladores de memoria. http://www.linux-mag.com/id/6868 Quizas algunos digan que este articulo es pro AMD, pero no, no lo es, ya que está escrito por un ingeniero de intel. Salu2 --------------------------------------------------------------------- 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
Hola :) El Monday 15 September 2008, Juan Erbes escribió:
Otra vez NUMA, en un articulo publicado por LinuxWorld: Les dejo una parte del articulo traducida:
Numa (NUMA): como el n�mero de procesadores en un sistema aumenta, el ancho de banda total entre los procesadores y la memoria tambi�n aumenta. La construcci�n de una interconexi�n sim�tricos que pueden proporcionar el ancho de banda que se hace cada vez m�s caro. Una soluci�n es un tipo de sistema conocido como NUMA (Non-Uniform Memory Access). Un sistema NUMA conecta los procesadores y los bancos de memoria de esta manera:
* Conectar directamente algunos procesadores (o local) a algunos bancos de memoria. * Proporcionar un m�todo de transmisi�n de datos para el acceso a bancos de memoria para los procesadores no est�n directamente vinculadas a bancos de memoria.
Hoy en d�a, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores han integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Quizas algunos digan que este articulo es pro AMD, pero no, no lo es, ya que est� escrito por un ingeniero de intel.
El artículo está interesante :) Sólo una aclaración: realmente NUMA Non-Uniform Memory Access es un acceso no uniforme por parte de los procesadores a la memoria RAM. No tiene por qué tener el controlador de memoria integrado en la CPU (procesador). Nosotros (SGI) llevamos montando NUMA desde hace muchos años sin que el controlador de memoria estuviera integrado en la CPU ... y escalamos hasta 2048 cores en imagen única (SSI). En un sistema UMA, todos los procesadores tienen el mismo "derecho" de acceder a la totalidad de la memoria RAM. En cambio, en un sistema NUMA, cada procesador tiene _su_ memoria y si un procesador quiere acceder a la memoria de otro procesador, tiene que "pedir permiso". Además, puede haber una memoria global a la que todos los procesadores pueden acceder "sin pedir permiso". 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
El día 15 de septiembre de 2008 13:47, Rafa Grimán <rafagriman@gmail.com> escribió:
Hola :)
El Monday 15 September 2008, Juan Erbes escribió:
Otra vez NUMA, en un articulo publicado por LinuxWorld: Les dejo una parte del articulo traducida:
Numa (NUMA): como el número de procesadores en un sistema aumenta, el ancho de banda total entre los procesadores y la memoria también aumenta. La construcción de una interconexión simétricos que pueden proporcionar el ancho de banda que se hace cada vez más caro. Una solución es un tipo de sistema conocido como NUMA (Non-Uniform Memory Access). Un sistema NUMA conecta los procesadores y los bancos de memoria de esta manera:
* Conectar directamente algunos procesadores (o local) a algunos bancos de memoria. * Proporcionar un método de transmisión de datos para el acceso a bancos de memoria para los procesadores no están directamente vinculadas a bancos de memoria.
Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores han integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Quizas algunos digan que este articulo es pro AMD, pero no, no lo es, ya que está escrito por un ingeniero de intel.
El artículo está interesante :)
Sólo una aclaración: realmente NUMA Non-Uniform Memory Access es un acceso no uniforme por parte de los procesadores a la memoria RAM. No tiene por qué tener el controlador de memoria integrado en la CPU (procesador). Nosotros (SGI) llevamos montando NUMA desde hace muchos años sin que el controlador de memoria estuviera integrado en la CPU ... y escalamos hasta 2048 cores en imagen única (SSI).
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture). Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricación. Salu2 --------------------------------------------------------------------- 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
Hola :) El Tuesday 16 September 2008, Juan Erbes escribió:
El d�a 15 de septiembre de 2008 13:47, Rafa Grim�n
<rafagriman@gmail.com> escribi�:
Hola :)
El Monday 15 September 2008, Juan Erbes escribi�:
Otra vez NUMA, en un articulo publicado por LinuxWorld: Les dejo una parte del articulo traducida:
Numa (NUMA): como el n�mero de procesadores en un sistema aumenta, el ancho de banda total entre los procesadores y la memoria tambi�n aumenta. La construcci�n de una interconexi�n sim�tricos que pueden proporcionar el ancho de banda que se hace cada vez m�s caro. Una soluci�n es un tipo de sistema conocido como NUMA (Non-Uniform Memory Access). Un sistema NUMA conecta los procesadores y los bancos de memoria de esta manera:
* Conectar directamente algunos procesadores (o local) a algunos bancos de memoria. * Proporcionar un m�todo de transmisi�n de datos para el acceso a bancos de memoria para los procesadores no est�n directamente vinculadas a bancos de memoria.
Hoy en d�a, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores han integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Quizas algunos digan que este articulo es pro AMD, pero no, no lo es, ya que est� escrito por un ingeniero de intel.
El art�culo est� interesante :)
S�lo una aclaraci�n: realmente NUMA Non-Uniform Memory Access es un acceso no uniforme por parte de los procesadores a la memoria RAM. No tiene por qu� tener el controlador de memoria integrado en la CPU (procesador). Nosotros (SGI) llevamos montando NUMA desde hace muchos a�os sin que el controlador de memoria estuviera integrado en la CPU ... y escalamos hasta 2048 cores en imagen �nica (SSI).
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el artículo sea incorrecto, sólo aclaraba un poco (resumiendo) para los que no hablan/leen inglés o no quieren leer el artículo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricaci�n.
NUMA no tiene nada que ver con integración del controlador memoria en la CPU. Es más, en el documento, dice esto mismo: "A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks." Que es precisamente lo que yo he puesto en el correo anterior. Como he dicho antes, hemos estado hacinedo esto durante años sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria esté en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA. 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
El 17 de septiembre de 2008 7:39, Rafa Grimán <rafagriman@gmail.com> escribió:
Hola :)
El Tuesday 16 September 2008, Juan Erbes escribió:
El día 15 de septiembre de 2008 13:47, Rafa Grimán
<rafagriman@gmail.com> escribió:
Hola :)
El Monday 15 September 2008, Juan Erbes escribió:
Otra vez NUMA, en un articulo publicado por LinuxWorld: Les dejo una parte del articulo traducida:
Numa (NUMA): como el número de procesadores en un sistema aumenta, el ancho de banda total entre los procesadores y la memoria también aumenta. La construcción de una interconexión simétricos que pueden proporcionar el ancho de banda que se hace cada vez más caro. Una solución es un tipo de sistema conocido como NUMA (Non-Uniform Memory Access). Un sistema NUMA conecta los procesadores y los bancos de memoria de esta manera:
* Conectar directamente algunos procesadores (o local) a algunos bancos de memoria. * Proporcionar un método de transmisión de datos para el acceso a bancos de memoria para los procesadores no están directamente vinculadas a bancos de memoria.
Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores han integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Quizas algunos digan que este articulo es pro AMD, pero no, no lo es, ya que está escrito por un ingeniero de intel.
El artículo está interesante :)
Sólo una aclaración: realmente NUMA Non-Uniform Memory Access es un acceso no uniforme por parte de los procesadores a la memoria RAM. No tiene por qué tener el controlador de memoria integrado en la CPU (procesador). Nosotros (SGI) llevamos montando NUMA desde hace muchos años sin que el controlador de memoria estuviera integrado en la CPU ... y escalamos hasta 2048 cores en imagen única (SSI).
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el artículo sea incorrecto, sólo aclaraba un poco (resumiendo) para los que no hablan/leen inglés o no quieren leer el artículo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricación.
NUMA no tiene nada que ver con integración del controlador memoria en la CPU. Es más, en el documento, dice esto mismo:
"A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks."
Que es precisamente lo que yo he puesto en el correo anterior.
Como he dicho antes, hemos estado hacinedo esto durante años sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria esté en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA.
Que NUMA no tiene nada que ver con integración del controlador memoria en la CPU? Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "???? Traducido, viene a ser algo como: Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868 No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extraño. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm Salu2 --------------------------------------------------------------------- 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
Hola :) El Wednesday 17 September 2008, Juan Erbes escribió: [...]
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el art�culo sea incorrecto, s�lo aclaraba un poco (resumiendo) para los que no hablan/leen ingl�s o no quieren leer el art�culo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricaci�n.
NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU. Es m�s, en el documento, dice esto mismo:
"A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks."
Que es precisamente lo que yo he puesto en el correo anterior.
Como he dicho antes, hemos estado hacinedo esto durante a�os sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria est� en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA.
Que NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en d�a, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extra�o. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm
Es curioso, porque los farbicantes que ofrecemos NUMA desde hace muchos años (y somos unos cuantos fabricantes y NUMA no es nada nuevo) llevamos haciendo esto con Itanium desde que, por ejemplo, salió el Itanium (que NO tiene el controlador de memoria en la CPU). SGI, HP, Bull, Fujitsu usan Itanium, otros fabricantes (IBM) usan otros procesadores. Antes de Itanium, por ejemplo, SGI utilizaba MIPS en los sistemas NUMA. En el caso de SGI, te podemos montar un NUMA con una placa que tiene dos sockets Itanium dual-core cada uno y ninguno de ellos tiene controlador de memoria en la CPU. Y, en nuestro caso, tampoco añadimos "hardware extraño", como pones en tu correo. Es más, el tener el controlador de memoria en la propia CPU puede ser un inconveniente en determinados modelos de NUMA ya que te obliga a meter un blade (o MoBo) _CON_ la CPU aunque sólo quieras ampliar memoria. Ya que es la CPU la que tiene el controlador de memoria. 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 - si tengo procesadores _CON_ controlador de memoria, añado otro blade (o MoBo) que contiene ranuras de expansión de RAM _Y_ sockets de CPU. Luego me veo _OBLIGADO_ a ampliar el número de CPUs a la vez que amplío la RAM, cosa que no quiero porque, por ejemplo, el sw que estoy ejecutando se licencia por CPU (Oracle, por ejemplo) Luego tener el controlador de memoria en CPU me sale más caro porque al ampliar RAM, tengo que ampliar CPU (las tengo que pagar/comprar) y tengo que pagar las licencias adicionales del sw que esté ejecutando (en caso de que sea así el caso). Pero mínimo, tengo que pagar nuevas CPUs que _NO_ quiero y _NO_ necesito. Esto también aumenta el consumo eléctrico, la producción de calor, ... Conozco varios casos reales que te pondría como ejemplo de un sistema NUMA que tiene este problema. Te voy a poner uno sólo: un cliente corriendo Oracle quiere ampliar RAM (tiene 256 GB de RAM y 16 CPUs). El fabricante le dice que para ampliar RAM, tiene que ampliar CPUs, concretamente, tiene que añadir otras 16 CPUs. Resultado: - tiene 32 CPUs de las cuáles _SÓLO_ usa 16* - está pagando 32 licnecias de Oracle, aunque sólo usa 16 CPUs* - el sistema ha ampliado mucho el consumo eléctrico - el sistema ha ampliado mucho la producción de calor - han tenido que ampliar el sistema de refrigeración Lo bueno de tener el controlador de memoria en la CPU: menor latencia, por ejemplo. Luego clientes que ejecutan aplicaciones multihilo que requieran una baja latencia (y que no se licencien por core) se verán favorecidos. Las cosas no son 100% buenas o malas. Depende de la situación en la que te encuentres. 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
2008/9/17 Rafa Grimán <rafagriman@gmail.com>:
Hola :)
El Wednesday 17 September 2008, Juan Erbes escribió:
[...]
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el artículo sea incorrecto, sólo aclaraba un poco (resumiendo) para los que no hablan/leen inglés o no quieren leer el artículo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricación.
NUMA no tiene nada que ver con integración del controlador memoria en la CPU. Es más, en el documento, dice esto mismo:
"A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks."
Que es precisamente lo que yo he puesto en el correo anterior.
Como he dicho antes, hemos estado hacinedo esto durante años sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria esté en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA.
Que NUMA no tiene nada que ver con integración del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extraño. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm
Es curioso, porque los farbicantes que ofrecemos NUMA desde hace muchos años (y somos unos cuantos fabricantes y NUMA no es nada nuevo) llevamos haciendo esto con Itanium desde que, por ejemplo, salió el Itanium (que NO tiene el controlador de memoria en la CPU). SGI, HP, Bull, Fujitsu usan Itanium, otros fabricantes (IBM) usan otros procesadores. Antes de Itanium, por ejemplo, SGI utilizaba MIPS en los sistemas NUMA.
En el caso de SGI, te podemos montar un NUMA con una placa que tiene dos sockets Itanium dual-core cada uno y ninguno de ellos tiene controlador de memoria en la CPU. Y, en nuestro caso, tampoco añadimos "hardware extraño", como pones en tu correo.
Es más, el tener el controlador de memoria en la propia CPU puede ser un inconveniente en determinados modelos de NUMA ya que te obliga a meter un blade (o MoBo) _CON_ la CPU aunque sólo quieras ampliar memoria. Ya que es la CPU la que tiene el controlador de memoria.
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? 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. Salu2 --------------------------------------------------------------------- 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
Hola :) El Wednesday 17 September 2008, Juan Erbes escribió:
2008/9/17 Rafa Grim�n <rafagriman@gmail.com>:
Hola :)
El Wednesday 17 September 2008, Juan Erbes escribi�:
[...]
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el art�culo sea incorrecto, s�lo aclaraba un poco (resumiendo) para los que no hablan/leen ingl�s o no quieren leer el art�culo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricaci�n.
NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU. Es m�s, en el documento, dice esto mismo:
"A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks."
Que es precisamente lo que yo he puesto en el correo anterior.
Como he dicho antes, hemos estado hacinedo esto durante a�os sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria est� en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA.
Que NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en d�a, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extra�o. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm
Es curioso, porque los farbicantes que ofrecemos NUMA desde hace muchos a�os (y somos unos cuantos fabricantes y NUMA no es nada nuevo) llevamos haciendo esto con Itanium desde que, por ejemplo, sali� el Itanium (que NO tiene el controlador de memoria en la CPU). SGI, HP, Bull, Fujitsu usan Itanium, otros fabricantes (IBM) usan otros procesadores. Antes de Itanium, por ejemplo, SGI utilizaba MIPS en los sistemas NUMA.
En el caso de SGI, te podemos montar un NUMA con una placa que tiene dos sockets Itanium dual-core cada uno y ninguno de ellos tiene controlador de memoria en la CPU. Y, en nuestro caso, tampoco a�adimos "hardware extra�o", como pones en tu correo.
Es m�s, el tener el controlador de memoria en la propia CPU puede ser un inconveniente en determinados modelos de NUMA ya que te obliga a meter un blade (o MoBo) _CON_ la CPU aunque s�lo quieras ampliar memoria. Ya que es la CPU la que tiene el controlador de memoria.
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. 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
El día 18 de septiembre de 2008 4:27, Rafa Grimán <rafagriman@gmail.com> escribió:
Hola :)
El Wednesday 17 September 2008, Juan Erbes escribió:
2008/9/17 Rafa Grimán <rafagriman@gmail.com>:
Hola :)
El Wednesday 17 September 2008, Juan Erbes escribió:
[...]
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el artículo sea incorrecto, sólo aclaraba un poco (resumiendo) para los que no hablan/leen inglés o no quieren leer el artículo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricación.
NUMA no tiene nada que ver con integración del controlador memoria en la CPU. Es más, en el documento, dice esto mismo:
"A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks."
Que es precisamente lo que yo he puesto en el correo anterior.
Como he dicho antes, hemos estado hacinedo esto durante años sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria esté en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA.
Que NUMA no tiene nada que ver con integración del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extraño. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm
Es curioso, porque los farbicantes que ofrecemos NUMA desde hace muchos años (y somos unos cuantos fabricantes y NUMA no es nada nuevo) llevamos haciendo esto con Itanium desde que, por ejemplo, salió el Itanium (que NO tiene el controlador de memoria en la CPU). SGI, HP, Bull, Fujitsu usan Itanium, otros fabricantes (IBM) usan otros procesadores. Antes de Itanium, por ejemplo, SGI utilizaba MIPS en los sistemas NUMA.
En el caso de SGI, te podemos montar un NUMA con una placa que tiene dos sockets Itanium dual-core cada uno y ninguno de ellos tiene controlador de memoria en la CPU. Y, en nuestro caso, tampoco añadimos "hardware extraño", como pones en tu correo.
Es más, el tener el controlador de memoria en la propia CPU puede ser un inconveniente en determinados modelos de NUMA ya que te obliga a meter un blade (o MoBo) _CON_ la CPU aunque sólo quieras ampliar memoria. Ya que es la CPU la que tiene el controlador de memoria.
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. 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. 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/4323... Salu2 --------------------------------------------------------------------- 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
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
El día 18 de septiembre de 2008 11:13, Rafa Grimán <rafagriman@gmail.com> escribió:
Hola :)
El Thursday 18 September 2008, Juan Erbes escribió:
[...]
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".
El dato de AMD, que corresponde a la primer serie de Opteron es de 6.4 GB/seg, con socket 940. El dato de la capacidad maxima de direccionamiento, no la he encontrado y ademas, no sirve de mucho, si el fabricante del mobo, no equipa a nivel de hardware esa capacidad maxima de direccionamiento. Los actuales, comparados con los intel los tenes en: http://www2.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_15225...
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
No estan nada mal esos valores. Por si te interesa leer algo sobre ccNUMA: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/4055... Salu2 --------------------------------------------------------------------- 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
Hola :) El Friday 19 September 2008, Juan Erbes escribió:
El d�a 18 de septiembre de 2008 11:13, Rafa Grim�n
<rafagriman@gmail.com> escribi�:
Hola :)
El Thursday 18 September 2008, Juan Erbes escribi�:
[...]
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".
El dato de AMD, que corresponde a la primer serie de Opteron es de 6.4 GB/seg, con socket 940.
Como dicen los anglosajones: "I stand corrected". Es decir, gracias por corregirme :)
El dato de la capacidad maxima de direccionamiento, no la he encontrado y ademas, no sirve de mucho, si el fabricante del mobo, no equipa a nivel de hardware esa capacidad maxima de direccionamiento.
¿Cómo que no sirve de mucho? Nuestros clientes no dicen eso. Por ejemplo, tenemos un cliente en el mundo enterprise que tiene un ORacle Times Ten (IMDB) cuyo servidor tiene 128 cores Itanium y 2 TB de RAM. En el mundo HPC, nuestros clientes requieren mucho más que eso. Todo esto en sistemas NUMA, claro está (SSI), no hablamos de cluster (aka memoria distribuida). De hecho, lo "bonito" de NUMA es que aunque tu MoBo (blade) NO acepte tanta RAM ... se la puedes añadir porque puedes añadir MoBos (blades) adicionales con memoria.
Los actuales, comparados con los intel los tenes en: http://www2.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_1522 5,00.html
Gracias :)
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
No estan nada mal esos valores.
Por si te interesa leer algo sobre ccNUMA: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/405 55.pdf
Para los curiosos, el ccNUMA significa "cache coherency NUMA", es decir que las cachés de los cores (CPUs) es coherente en un sistema NUMA. Esto significa que en tiempo real, las cachés de todas las CPUs tienen que estar de acuerdo que el valor que contienen son los correctos y que son coherentes los unos con los otros. Esto de NUMA salió en un post anterior, en el que ponía el ejemplo de una fábrica de panes. Creo que expliqué en ese hilo algo de esto también. La verdad es que nuestras máquinas llevan siendo ccNUMA desde hace mucho. No te quiero desanimar, pero muchos de estos links ya los he leído: - porque tengo curiosidad y busco - porque internamente hay mucho loco que también se los lee y te los pasa - porque los de marketing nos los pasan - porque las grandes consultoras los referencian (IDC, Gartner, ...) - porque te los pasan los de AMD - porque te los pasan los de Intel Aunque no te lo creas (y eso que te lo he escrito MUCHAS veces en MUCHOS correos, aún así te lo vuelvo a repetir): NO ESTOY EN CONTRA DE AMD. Mira Juan, ya no sé si es que me explico mal, si no me entiendes o si no te lees mis correos. Deja de darle vueltas al bien y al mal, olvídate de si me gusta o no AMD o Intel, olvídate de si uno es mejor que el otro, ... Yo NO estoy entrando en eso, eso son opiniones personales de cada uno y ya te he dado muchas veces mi opinión: tengo AMD en casa y estoy muy contento, al igual que tengo Intel y también estoy contento. A nivel de trabajo: SGI ha trabajado con MIPS, trabaja con Intel y ha tenido acercamientos por parte de AMD. No rechazamos (como empresa) el analizar o tener en cuenta otras tecnologías para nuestros productos, es más: hace un año certificamos algunas de nuestras máquinas para MS-Windows 2k3 !!! Dios santo, somos peor que el diablo: nuestros procesadores son Intel (y encima Itanium) y hemos certificado algunos servidores con MS-Windows !!! Oid todos !!! Marcadme como SPAMMER, id a vuestra parroquia y cazadme y quemadme por hereje !!! Christian, diles a los de Nuremberg que no me permitan postear en las listas jamás y que me tachen como persona, que me quiten la posibilidad de utilizar cualquier variante de SUSE y que transmitan todo esto a Red Hat, Debian, Slackware, Gentoo, ... Que lo sepan todos los vientos y todos los linuxeros, además de los amantes de BSD !!!! Sinceramente Juan, en el momento que detectas que algo o alguien parece estar en contra de AMD ... lanzas miles de enlaces (que muchas veces ya he leído) para intentar demostrar que estamos equivocados cuando realmente NADIE ha dicho NADA en contra de AMD ni tampoco a favor de Intel (el eje del mal). No te paras a leer y comprender el correo para saber si están hablando de otra cosa, en el momento que ves AMD ya es que estamos en contra y hay que contraatacar y demostrar que vivimos en las sombras. En este thread, lo que estamos hablando es de si hace o no falta tener el controlador de memoria en la CPU o no para hacer NUMA. Esto no tiene nada que ver con AMD, Intel, PowerPC, MIPS, ARM, SPARC, ... el bien, el mal, Mickey Mouse o la Pantera Rosa. Te guste o no, el tema es sencillo: ¿hace falta que el controlador de memoria esté en la CPU para hacer un sistema (cc)NUMA? La respuetsa es sencilla: no Si no fuera así, muchos fabricantes (con y sin procesadores INTEL y/o AMD) no habríamos hecho sistemas NUMA desde hace años. O bien hace años que se habría "impuesto" lo del controlador de memoria en la CPU. Por cierto, te recuerdo que hay sistemas NUMA _SIN_ procesadores Intel NI AMD ... No puede ser, ¿hay otros procesadores que no son Intel ni AMD? Pues sí. Si no te crees lo que te estoy diciendo: habla con IBM, HP, Fujitsu, Bull, Cray, ... y pregúntales si es necesario que un sistema (cc)NUMA tenga el controlador de memoria en la CPU. 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
El día 19 de septiembre de 2008 5:20, Rafa Grimán <rafagriman@gmail.com> escribió:
Hola :)
El Friday 19 September 2008, Juan Erbes escribió:
El día 18 de septiembre de 2008 11:13, Rafa Grimán
<rafagriman@gmail.com> escribió:
Hola :)
El Thursday 18 September 2008, Juan Erbes escribió:
[...]
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".
El dato de AMD, que corresponde a la primer serie de Opteron es de 6.4 GB/seg, con socket 940.
Como dicen los anglosajones: "I stand corrected". Es decir, gracias por corregirme :)
El dato de la capacidad maxima de direccionamiento, no la he encontrado y ademas, no sirve de mucho, si el fabricante del mobo, no equipa a nivel de hardware esa capacidad maxima de direccionamiento.
¿Cómo que no sirve de mucho? Nuestros clientes no dicen eso. Por ejemplo, tenemos un cliente en el mundo enterprise que tiene un ORacle Times Ten (IMDB) cuyo servidor tiene 128 cores Itanium y 2 TB de RAM. En el mundo HPC, nuestros clientes requieren mucho más que eso. Todo esto en sistemas NUMA, claro está (SSI), no hablamos de cluster (aka memoria distribuida).
De hecho, lo "bonito" de NUMA es que aunque tu MoBo (blade) NO acepte tanta RAM ... se la puedes añadir porque puedes añadir MoBos (blades) adicionales con memoria.
Los actuales, comparados con los intel los tenes en: http://www2.amd.com/us-en/Processors/ProductInformation/0,,30_118_8796_1522 5,00.html
Gracias :)
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
No estan nada mal esos valores.
Por si te interesa leer algo sobre ccNUMA: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/405 55.pdf
Para los curiosos, el ccNUMA significa "cache coherency NUMA", es decir que las cachés de los cores (CPUs) es coherente en un sistema NUMA. Esto significa que en tiempo real, las cachés de todas las CPUs tienen que estar de acuerdo que el valor que contienen son los correctos y que son coherentes los unos con los otros.
Esto de NUMA salió en un post anterior, en el que ponía el ejemplo de una fábrica de panes. Creo que expliqué en ese hilo algo de esto también.
La verdad es que nuestras máquinas llevan siendo ccNUMA desde hace mucho. No te quiero desanimar, pero muchos de estos links ya los he leído: - porque tengo curiosidad y busco - porque internamente hay mucho loco que también se los lee y te los pasa - porque los de marketing nos los pasan - porque las grandes consultoras los referencian (IDC, Gartner, ...) - porque te los pasan los de AMD - porque te los pasan los de Intel
Aunque no te lo creas (y eso que te lo he escrito MUCHAS veces en MUCHOS correos, aún así te lo vuelvo a repetir): NO ESTOY EN CONTRA DE AMD. Mira Juan, ya no sé si es que me explico mal, si no me entiendes o si no te lees mis correos.
Deja de darle vueltas al bien y al mal, olvídate de si me gusta o no AMD o Intel, olvídate de si uno es mejor que el otro, ... Yo NO estoy entrando en eso, eso son opiniones personales de cada uno y ya te he dado muchas veces mi opinión: tengo AMD en casa y estoy muy contento, al igual que tengo Intel y también estoy contento.
A nivel de trabajo: SGI ha trabajado con MIPS, trabaja con Intel y ha tenido acercamientos por parte de AMD. No rechazamos (como empresa) el analizar o tener en cuenta otras tecnologías para nuestros productos, es más: hace un año certificamos algunas de nuestras máquinas para MS-Windows 2k3 !!! Dios santo, somos peor que el diablo: nuestros procesadores son Intel (y encima Itanium) y hemos certificado algunos servidores con MS-Windows !!!
Oid todos !!! Marcadme como SPAMMER, id a vuestra parroquia y cazadme y quemadme por hereje !!!
Christian, diles a los de Nuremberg que no me permitan postear en las listas jamás y que me tachen como persona, que me quiten la posibilidad de utilizar cualquier variante de SUSE y que transmitan todo esto a Red Hat, Debian, Slackware, Gentoo, ... Que lo sepan todos los vientos y todos los linuxeros, además de los amantes de BSD !!!!
Sinceramente Juan, en el momento que detectas que algo o alguien parece estar en contra de AMD ... lanzas miles de enlaces (que muchas veces ya he leído) para intentar demostrar que estamos equivocados cuando realmente NADIE ha dicho NADA en contra de AMD ni tampoco a favor de Intel (el eje del mal). No te paras a leer y comprender el correo para saber si están hablando de otra cosa, en el momento que ves AMD ya es que estamos en contra y hay que contraatacar y demostrar que vivimos en las sombras.
En este thread, lo que estamos hablando es de si hace o no falta tener el controlador de memoria en la CPU o no para hacer NUMA. Esto no tiene nada que ver con AMD, Intel, PowerPC, MIPS, ARM, SPARC, ... el bien, el mal, Mickey Mouse o la Pantera Rosa. Te guste o no, el tema es sencillo:
¿hace falta que el controlador de memoria esté en la CPU para hacer un sistema (cc)NUMA?
La respuetsa es sencilla:
no
Tienes razón, no hace falta. Pero si los micros tienen el controlador integrado, como decía el artículo de Tony Luck, en equipos pequeños con un solo mobo, es mas facil de implementar, ya que no necesita de chips y placas adicionales. De hecho, hoy en dia un equipo con 1 micro de 4 cores intel, forzosamente debe implementar UMA, mientras que un equipo con 1 micro de 4 cores AMD, forzosamente debe implementar NUMA (ccNUMA). O me equivoco? Basado en http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/4055... Salu2. --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-17 a las 09:30 -0300, Juan Erbes escribió: ...
Que NUMA no tiene nada que ver con integración del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Pues eso precisamente, que no tiene que ver. Que la definición de NUMA no implica la inclusión del controlador de memoria en el procesador. El párrafo dice que "aunque sea una computadora de una sola placa puede ser NUMA, cuando los procesadores tienen contrladores de memoria integrados", lo que implica que antes de existir esos procesadores ya se estaba usando NUMA. Puedes tener NUMA independientemente de donde está el controlador de memoria, es algo independiente. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjRJlgACgkQtTMYHG2NR9WesQCeNRso4XR+6/O43AdeZIeKORko 3DcAnj1DWl3R5ZmIhIpDZS8akuHag3CR =sH4x -----END PGP SIGNATURE-----
El día 17 de septiembre de 2008 12:46, Carlos E. R. <robin.listas@telefonica.net> escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-09-17 a las 09:30 -0300, Juan Erbes escribió:
...
Que NUMA no tiene nada que ver con integración del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en día, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Pues eso precisamente, que no tiene que ver. Que la definición de NUMA no implica la inclusión del controlador de memoria en el procesador.
El párrafo dice que "aunque sea una computadora de una sola placa puede ser NUMA, cuando los procesadores tienen contrladores de memoria integrados", lo que implica que antes de existir esos procesadores ya se estaba usando NUMA. Puedes tener NUMA independientemente de donde está el controlador de memoria, es algo independiente.
Parece que no viste lo que le dije a Rafa: "No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extraño. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm" Dudo mucho de que encuentres un mobo estandar para 2 micros intel que implemente NUMA. Algo que se ha tocado hace un tiempo, relacionado con NUMA y las supercomputadoras: http://www-03.ibm.com/press/us/en/pressrelease/20210.wss http://www.idg.es/computerworld/articulo.asp?id=179042 Salu2 --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-17 a las 14:02 -0300, Juan Erbes escribió:
Pues eso precisamente, que no tiene que ver. Que la definición de NUMA no implica la inclusión del controlador de memoria en el procesador.
El párrafo dice que "aunque sea una computadora de una sola placa puede ser NUMA, cuando los procesadores tienen contrladores de memoria integrados", lo que implica que antes de existir esos procesadores ya se estaba usando NUMA. Puedes tener NUMA independientemente de donde está el controlador de memoria, es algo independiente.
Parece que no viste lo que le dije a Rafa:
Claro que lo vi. Pero eso no afecta al hecho de que NUMA es anterior y que no depende de que haya procesadores que la integren. Y eso puede ser bueno en algunos casos y malo en otros. Abarata los precios, lo mismo que es más barato un PC con una placa que integra el video y el sonido. Pero no necesariamente es mejor, si por ejemplo necesitas las prestaciones de... no se, una soundblaster 32. La definición de mejor dependerá del uso que se le pretenda dar. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjRSZkACgkQtTMYHG2NR9UxKgCgmS27mpAM6zgt0hdz8ygnCiOX 7XMAn1yhfaj63HOmYM1D0BsHLyXF8hpG =uSaS -----END PGP SIGNATURE-----
Hola :) El Wednesday 17 September 2008, Juan Erbes escribió:
El d�a 17 de septiembre de 2008 12:46, Carlos E. R.
<robin.listas@telefonica.net> escribi�:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-09-17 a las 09:30 -0300, Juan Erbes escribi�:
...
Que NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en d�a, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
Pues eso precisamente, que no tiene que ver. Que la definici�n de NUMA no implica la inclusi�n del controlador de memoria en el procesador.
El p�rrafo dice que "aunque sea una computadora de una sola placa puede ser NUMA, cuando los procesadores tienen contrladores de memoria integrados", lo que implica que antes de existir esos procesadores ya se estaba usando NUMA. Puedes tener NUMA independientemente de donde est� el controlador de memoria, es algo independiente.
Parece que no viste lo que le dije a Rafa:
Y parece que no has leído mi respuesta ...
"No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extra�o. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm"
Dudo mucho de que encuentres un mobo estandar para 2 micros intel que implemente NUMA.
Los fabricantes que tenemos máquinas con Itanium, hace tiempo que llevamos ofreciendo sistemas NUMA con procesadores de Intel (concretamente Itanium) y que se pueden hacer con una única MoBo. Voy a hablar, otra vez, de nuestro caso que es el que mejor conozco. Nosotros tenemos blades de 2 sockets Itanium que son NUMA.
Algo que se ha tocado hace un tiempo, relacionado con NUMA y las supercomputadoras: http://www-03.ibm.com/press/us/en/pressrelease/20210.wss http://www.idg.es/computerworld/articulo.asp?id=179042
¿Y? 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
El 18/09/08, Rafa Grimán escribió:
El Wednesday 17 September 2008, Juan Erbes escribió:
Dudo mucho de que encuentres un mobo estandar para 2 micros intel que implemente NUMA.
Los fabricantes que tenemos máquinas con Itanium, hace tiempo que llevamos ofreciendo sistemas NUMA con procesadores de Intel (concretamente Itanium) y que se pueden hacer con una única MoBo.
Si no recuerdo mal, Supermicro tenía placas base con procesadores Itanium 2 (chipset e8870 y socket dual) que soportaban NUMA. Pero de esto hace ya unos años, no sé qué habrá pasado con estas placas... ahora mismo no me carga su página web :-? Saludos, -- Camaleón --------------------------------------------------------------------- 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
Hola :) El Thursday 18 September 2008, Camaleón escribió:
El 18/09/08, Rafa Grim�n escribi�:
El Wednesday 17 September 2008, Juan Erbes escribi�:
Dudo mucho de que encuentres un mobo estandar para 2 micros intel que implemente NUMA.
Los fabricantes que tenemos m�quinas con Itanium, hace tiempo que llevamos ofreciendo sistemas NUMA con procesadores de Intel (concretamente Itanium) y que se pueden hacer con una �nica MoBo.
Si no recuerdo mal, Supermicro ten�a placas base con procesadores Itanium 2 (chipset e8870 y socket dual) que soportaban NUMA. Pero de esto hace ya unos a�os, no s� qu� habr� pasado con estas placas... ahora mismo no me carga su p�gina web :-?
No lo sé. Sé que Fujitsu, Bull y HP sí lo tienen con Itanium, además de SGI (claro ;) De SuperMicro no lo sé seguro. 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
El 18/09/08, Rafa Grimán escribió:
No lo sé. Sé que Fujitsu, Bull y HP sí lo tienen con Itanium, además de SGI (claro ;) De SuperMicro no lo sé seguro.
O:-) Ah, mira, ya carga la página... A ver, yo tenía en mente estas placas: i2DML-8G2 <http://www.supermicro.com/products/motherboard/Itanium/E8870/i2DML-8G2.cfm> ¿Crees que tiene soporte para NUMA? :-? Saludos, -- Camaleón --------------------------------------------------------------------- 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
Hola :) El Thursday 18 September 2008, Camaleón escribió:
El 18/09/08, Rafa Grim�n escribi�:
No lo s�. S� que Fujitsu, Bull y HP s� lo tienen con Itanium, adem�s de SGI (claro ;) De SuperMicro no lo s� seguro.
O:-)
Ah, mira, ya carga la p�gina... A ver, yo ten�a en mente estas placas:
i2DML-8G2 <http://www.supermicro.com/products/motherboard/Itanium/E8870/i2DML-8G2.cfm
�Crees que tiene soporte para NUMA? :-?
IMHO, no, pero no te lo aseguro ni te digo un NO rotundo. Generalmente, sabrás que es un sistema NUMA porque: - te pone que es NUMA - escala mucho más en memoria (no necesariamente) - te hablan de un chip o de una tecnología de interconexión que permite escalar De todas maneras, hay que tener cuidado, el NUMA se puede implementar: - a nivel hardware: lo que hacemos los fabricantes de hardware - a nivel software, como es el caso de OpenSSI y DragonBSD ¿Cuál es mejor? Depende: - si tu aplicación es muy sensible a la latencia: es mejor por hardware - si tu aplicación no es sensible a latencias: es mejor por software porque es más barato ya que puedes usar COTS hw 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
Hola :D Gracias a tod@s por esta maravillosa lección de hardware, ni siquiera sabia que significaba el concepto de escalabilidad, me pensaba que era algo así como " si me compras una 2ª maquina te regalo un par de módulos de memoria..." :P y resulta que es la posibilidad de ampliar las propias capacidades limites del hardware. Habláis de gigas de memoria como si de rosquilletas se tratara, y yo peleando con 256 MB de ram y 1 GB de swap. Tengo una duda, las Baldes son tarjetas pinchadas o conectadas con cables... claro pongo blades en el google y me aparecen herramientas de corte :) -- "El cielo es para los dragones lo que el agua es para las ninfas" --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-19 a las 11:36 +0200, David Moreno escribió:
Hola :D
Gracias a tod@s por esta maravillosa lección de hardware, ni siquiera sabia que significaba el concepto de escalabilidad, me pensaba que era algo así como " si me compras una 2ª maquina te regalo un par de módulos de memoria..." :P y resulta que es la posibilidad de ampliar las propias capacidades limites del hardware.
O del software. Por ejemplo, pones una base de datos para controlar un almacén, y que pasa si el almacén triplica su stock, ¿puede ese modelo de base de datos con todo eso? A lo mejor se vuelve muy lenta o simplemente no admite tantos datos. O en sistemas de ficheros, se comenta que reiserfs no es muy escalable, porque funciona muy bien con nuestros sistemas normale pero mal con los gigantes.
Habláis de gigas de memoria como si de rosquilletas se tratara, y yo peleando con 256 MB de ram y 1 GB de swap.
Pa' caerse la baba a chorros. :-)
Tengo una duda, las Baldes son tarjetas pinchadas o conectadas con cables... claro pongo blades en el google y me aparecen herramientas de corte :)
http://en.wikipedia.org/wiki/Blade_server http://en.wikipedia.org/wiki/Blade_PC - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjTeHAACgkQtTMYHG2NR9UO/gCfZ9A4u676MO+kkdOMgwZNHbr5 I3AAniZT7kUcHhSgA27VpoEhUwhm8HSK =RtXf -----END PGP SIGNATURE-----
El 19/09/08, Carlos E. R. <robin.listas@telefonica.net> escribió:
Pa' caerse la baba a chorros. :-)
Tranquilo he puesto unas servilletas encima del teclado para que no se moje mucho. Debe ser un gozo ver un "bicho tan grande". :D -- "El cielo es para los dragones lo que el agua es para las ninfas" --------------------------------------------------------------------- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-19 a las 12:18 +0200, David Moreno escribió:
El 19/09/08, Carlos E. R. <robin.listas@telefonica.net> escribió:
Pa' caerse la baba a chorros. :-)
Tranquilo he puesto unas servilletas encima del teclado para que no se moje mucho. Debe ser un gozo ver un "bicho tan grande". :D
Pues si. Yo los he visto físicamente mayores, pero computacionalmente débiles: una central telefónica. Basicamente es un ordenador... pero muy especializado. Yo el que conozco es el de Lucent, conocido como "la cinco" en el mundillo. Un ordenador doble, de tal forma que puedes usar, por ejemplo, un ordenador con el disco duro del otro ordenador, porque tienen los buses duplicados y cruzados, de manera que puedes reparar una de las mitades mientras la otra sigue trabajando. Normalmente un lado está en standby y pasa a activo si falla el otro. Y es un armario grandote. Antiguo, no tiene red como la entendemos nosotros. No puedes hacerle un mísero telnet siquiera, usa terminales tontos via rs232. Unix RTR. (discos scsi con montones de particiones, por cierto) Y luego tiene una serie de armarios, pueden llegar a cientos, controlados desde el ordenador administrativo. Y cuando te cuentan que los armarios de conmutación que usa trabajan con un "simple" 68000... Es una arquitectura de propósito unico, especializada en enrutar llamadas, y eso lo hace muy rápido. Todo lo demas es escundario y lento. Tiempos de caída que se miden en segundos por año. Y anticuada. Pero carísima, y más cara de substituir.... así que seguirán. En Gran Bretaña están cambiando toda la red telefonica de BT. Es el primer país que se ha lanzado a hacerlo. Voip y servicios del nuevo milenio. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjTnOkACgkQtTMYHG2NR9XK/QCbBDMa/RIE7zKzMw2YfmmbM2qO 448An1yS52uF2AqgMXDKw9dDV5h3DgwV =qLcj -----END PGP SIGNATURE-----
Hola :) El Friday 19 September 2008, Carlos E. R. escribió:
El 2008-09-19 a las 11:36 +0200, David Moreno escribió:
Hola :D
Gracias a tod@s por esta maravillosa lección de hardware, ni siquiera sabia que significaba el concepto de escalabilidad, me pensaba que era algo así como " si me compras una 2ª maquina te regalo un par de módulos de memoria..." :P y resulta que es la posibilidad de ampliar las propias capacidades limites del hardware.
O del software. Por ejemplo, pones una base de datos para controlar un almacén, y que pasa si el almacén triplica su stock, ¿puede ese modelo de base de datos con todo eso? A lo mejor se vuelve muy lenta o simplemente no admite tantos datos.
Efectivamente. Si la aplicación no está paralelizada ... de nada te sirve tener tantos cores.
O en sistemas de ficheros, se comenta que reiserfs no es muy escalable, porque funciona muy bien con nuestros sistemas normale pero mal con los gigantes.
Habláis de gigas de memoria como si de rosquilletas se tratara, y yo peleando con 256 MB de ram y 1 GB de swap.
Pa' caerse la baba a chorros. :-)
Si alguien tiene curiosidad, puede ver fotos de lo que hemos montado en el LRZ de Alemania: http://www.sgi.com/global/de/newsroom/2006/0607-images-lrz-1.html Es una lástima porque hay una con las luces apagadas y sólo se ven los leds del almacenamiento ... pero no encuentro la foto.
Tengo una duda, las Baldes son tarjetas pinchadas o conectadas con cables... claro pongo blades en el google y me aparecen herramientas de corte :)
http://en.wikipedia.org/wiki/Blade_server http://en.wikipedia.org/wiki/Blade_PC
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
Solo tengo una palabra : ¡GUAUU! Es como ver la foto de ferrari para el apasionado de los coches. :) -- "El cielo es para los dragones lo que el agua es para las ninfas" --------------------------------------------------------------------- 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
Hola :) El Friday 19 September 2008, David Moreno escribió:
Hola :D
Gracias a tod@s por esta maravillosa lecci�n de hardware, ni siquiera sabia que significaba el concepto de escalabilidad, me pensaba que era algo as� como " si me compras una 2� maquina te regalo un par de m�dulos de memoria..." :P y resulta que es la posibilidad de ampliar las propias capacidades limites del hardware.
Escalabilidad es que el sistema crezca ... hasta donde te dé el bolsillo ;)
Habl�is de gigas de memoria como si de rosquilletas se tratara, y yo peleando con 256 MB de ram y 1 GB de swap.
La verdad es que las cosas han cambiado mucho. Hoy en día le precio de la memoria RAM ha bajado de forma espectacular. Me acuerdo cuando tenía Un Pentium I con 16 MB de RAM (escalable a 32 MB) y un disco duro de 1 GB ... pensaba que eso era inmenso. Luego empecé a trabajar y a ver máquinas grandes: 2 procesadores y 512 MB de RAM, ... Y luego entré en SGI y ... no me lo podía imaginar. Hemos hablado de GB de RAM, pero es que tenemos clientes con 40 PB (PetaBytes) de datos en disco, tenemos a clientes con más de 230 millones de ficheros de audio, vídeo, render, ... en disco (2 PB). En el primer caso, hay 3 administradores, en el segundo hay 1. En cuanto a clusters, tenemos uno con 14 mil cores. En cuanto a SSI: tenemos máquinas de 2048 cores, pero los clientes han dicho que los usuarios no saben qué hacer con tanto core en una máquina ... las hemos dividido en máquinas de 1024 ... seguían diciendo que era mucho ... así que se han conformado con máquinas de 512 cores ... Anda que no le daba yo uso a tanto core ... Estos tienen entre 2 y 4 GB de RAM por core.
Tengo una duda, las Baldes son tarjetas pinchadas o conectadas con cables... claro pongo blades en el google y me aparecen herramientas de corte :)
Imagínate que tu equipo tuviera una caja más grande (mucho más grande) en la que pudieras ir conectando placas base (hasta 10, imagínate). Ese es el concepto de blade: poder conectar las placas base a solas sin que tenga que ir cada una con su carcasa. Esto te permite ahorrar mucho espacio. 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
participants (5)
-
Camaleón -
Carlos E. R. -
David Moreno -
Juan Erbes -
Rafa Grimán