AEnema escribió:Vamos a ver. Con respecto a tus tasas de transferencia, has de saber que serial ata tiene una tasa de transferencia de 150 mega BYTES por segundo, mientras que Gigabit tiene una tasa de transferencia de 1 Giga BIT por segundo = 125 mega BYTES por segundo.
Ya que veo que te gusta utilizar las mayúsculas creo que en mi comentario quedaba bien claro:
rumbera escribió:..... 150MB/s, un SCSI(UW) de 160MB/s y ahora mismo tenemos tarjetas de red de 1 GBit/sg...
MB corresponde a megabyte, por lo menos en mis libros de la “Ingenieria”. Por eso después al hablar de la tarjeta de red expecifiqué G”bit”. Para poder diferenciarlos. También compruebo que sabes dividir entre 8. ¡ Enhorabuena!.
AEnema escribió:
Lo segundo, permiteme comentarte que las comunicaciones por red necesitan protocolos, y que esos protocolos consumen ancho de banda. Ni que decir tiene que un protocolo orientado a conexión (es decir que no falle, porque por si no lo sabías hay un porcentaje MUUUUY elevado de paquetes que se pierden) tiene un coste en reenvíos de paquetes aún más elevado.
¿ De verdad que las comunicaciones de red necesitan protocolos y que consumen ancho de banda ? De aquí te nominan para el Novel. Los disco duros ¿ no consumen ancho de banda ? .
Veo que alguna vez te has estudiado el TCP/IP y te han demonizado el TCP. Según tu teoría Internet es una mierda de red porque se pierden MUUUCHHHOOS paquetes. Vamos haz tu tesis sobre lo malo que es TCP. Se lo contamos a los ingenieros que llevan años desarrollando aplicaciones sobre TCP o protocolos superiores que son lo peor. Sus paquetes se pierden. Es más voy a escribir una carta a los señores de Cisco para decirles que sus routers no valen para nada. Si no que se pasen por hispasonic y se lo cuentas.
Ya si en vez de internet uso un Switch para unir mi cluster en mi miniLAN se perderan tambien paquetes. Es más, se perderan muchos más debido a la ley de Aenema. Es más si cogo 2 tarjetas de gigabit(para que no nos confundamos) y hago bounce en el nodo maestro para optimizar ancho de banda, no optimizo sino !!!! pesimizo !!!!. Joder, joder esto se pone feo. Voy a hacer un anuncio como el de las fotos perdidas pero para los paquetes.
AEnema escribió:
...... creo que con los datos que he dado antes queda claro que aún estamos muy lejos de conseguir unas tasas de transferencia mantenidas como para correr 32 pistas.
Según parece tu teoría de cluster es pasar todo el audio a las nodos. ¿ einnn ?. El nodo principal puede realizar gran parte del trabajo y trasladar a los restantes nodos el trabajo que su “procesador” no puede realizar. Lo que creo es que no acabas de entender es como se estructura la programación de este tipo de sistemas. Si el desarrollador es capaz de que su software migre procesos a otros nodos del cluster de manera preventiva, como por ejemplo adelantarse al tratamiento de una reverb en 2 segundos a su salida por el interface de audio, el sistema podrá procesar más información por lo que nuestra potencia de cálculo aumentará. Pero esto no me lo invento yo, es pura teoría que se pone en práctica con programación paralela.
Por un lado está el disco duro que se encuentra el “nodo maestro” con su lectura y escritura a través de este y por otro lado el calculo realizado por el procesador que puede ser realizado en el nodo maestro o en otros. Lo que trasferimos a los nodos no es audio en si sino procesos de cálculo. No confundamos churros con meninas.
AEnema escribió:
En la informática hay un tipo de sistemas denominados "sistemas de tiempo real" que se caracterizan por tener que cumplir unos plazos de tiempo. Pues bien. Una mezcla en un cluster podríamos considerarla algo parecido: cada nodo del cluster tiene que tener lista su pista con sus efectos procesados etc. en un tiempo suficiente para que no se produzcan saltos en el audio.
Te remito a lo que comentábamos anteriormente sobre migración de procesos preventiva. Insistes en pensar que un proceso debe saber lo que es una pista o un efecto.
La latencia con tarjetas ethernet y un switch no deben de superar los 5 ms.
AEnema escribió:
Permiteme decirte que hoy por hoy un cluster TAN rápido supondría utilizar conexiones con tecnologías como mirinet o similares, con lo cual nos gastamos más en comunicaciones que en comprar hardware real.
Seguimos. Evidentemente si usamos “myrinet” sería un sistema casi perfecto. Pero la lógica que yo quería exponer es que montar un cluster con un nodo maestro con buen procesador y memoria y montar 4 nodos con por ejemplo P-III comprados de segunda mano te sale muy barato en comparación a un sistema multiprocesador. Evidentemente hoy en día no hay software que pueda utilizar un cluster para el audio pero mola teorizar.
AEnema escribió:
Por otra parte, en los sistemas paralelos siempre existe una parte secuencial, que es lo que nos impide obtener mayor rendimiento al aumentar el número de nodos, es decir, por tener más ordenadores no vamos a ir más rápido, porque hay cosas que tienen que hacerse en un determinado orden, de manera que hasta que uno no termina el otro no puede seguir.
Bueno, lo dicho.
Mira, en esto estamos absolutamente de acuerdo. ¿ Pero en que procesador del cluster se van a realizar ?
Bueno, a ver si seguimos discutiendo sobre el tema que es muy interesante.
Saludos cordiales
Creamware parece estar de acuerdo con esto, con sus módulos externos).
No he tenido tampoco oportunidad de comprar ningún equipo relacionado ni he hecho crecer mi 'estudio' como para renovar equipos... Pero me ofrezco voluntario para hacer el I+D si alguien me regala el equipo 
