Hola :) El Viernes, 12 de Mayo de 2006 17:08, Victor Hugo dos Santos escribió:
2006/5/12, Rafa Grim�n
: Hola :)
[...]
Pues resulta que al final la culpa fue m�a 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga.
como lo haces ??? por el kernel ?? o la BIOS ??? por algun hechizo ??? la verdad es que nunca lo tenia escuchado !!!
Bueno, esto tiene dos formas ... que además van juntas ;) Por un lado tienes un sistema que por hardware (generalmente un chip) te asocia los dispositivos físicos, los interconecta. Esto suelen ser los chipsets, en nuestro caso se llama SHUB. Este chip tiene la misión de interconectar los diferentes dispositivos. En nuestro caso (SGI), no tenemos "ordenadores" sino que lo que tenemos son placas base que tiene "algo": CPUs, memoria, I/O, el SHUB este y un conector llamado NUMALink. Estas placas base van metidas en un "enclosure" que parece un ordenador, a todo esto es lo que llamamos brick. El NUMALink lo que permite es conectar todos estos bricks y el SHUB lo que hace es conectar o establecer rutas entre los diferentes dispositivos que hay en cada brick. El SHUB lo que hace es que si tienes un brick que tiene todo (CPU, memoria, I/O), asocia estos dispositivos I/O a las CPUs y memorias más cercanas. Bueno, como hablamos de chips, también hay que tener en cuenta que hay un firmware ;) En el lado SW, tenemos básicamente dos cosas: - scheduler - un comando (creo que era tasksel) El scheduler distribuye cargas y con el comando puedes asociar tu mismo los procesos. En nuestro caso, como son drivers, hacerlo a mano no es lógico por lo que nos basaríamos en el scheduler y en el SHUB+NUMALink.
El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que m�s cercana est�. En mi caso hab�a 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego hab�a un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI
mmm.. algo imaginaba referente a esto !!! ya que como comente, los buses PCIs eram compartidos, al menos para la maquinas que nosotros simples mortales usamos, no se las tuyas ya que nunca contestaste sobre esto.
Bueno, en nuestro caso, tenemos 2 buses PCI en cada placa, con dos ranuras cada bus. Según esto, podemos pinchar 4 dispositivos PCI. Esto lo hacemos rara vez debido a lo que dices. En el caso que me pasó, sí compartí 1 bus entre 2 dispositivos PCI porque ambos eran tarjetas de red y pensé, "Bueno, como una de ellas no se usa (no tiene cable de red y no está configurada), pues nop habrá pérdida de rendimiento" ... Eso me pasa por pensar ;)
- las 2 CPUs estaban al 100% y el restante no hac�a gran cosa
mm. me extrana ya que imaginaba que se compartian la carga !!!! y es como la primera vez que escucho que una tarjeta PCI sartura toda una CPU.
El problema en este caso es que en lo que se está gastando CPU es en interrupciones y (como comenta Carlos en el correo anterior) el tema de TCP/IP-Ethernet. Hasta donde yo sé, esto no se puede distribuir ya que la latencia sería mayor de lo que debería ser y se perdería rendimiento. Hablándolo con otras personas, me han comentado que también influye el scheduler de Linux y que son cosas en las que se está trabajando :)
Pues eso, muchas gracias a todos por las ideas ;)
Gracias a usted por compartir conozco estas configuraciones "utopicas", que posiblemente nos demorara mucho en conocer personalmente.
:) Rafa -- 50% of all statistics are inaccurate. OpenWengo: rgriman