El 18/05/06, Horst von Brand<[EMAIL PROTECTED]> escribió: > Victor Hugo dos Santos <[EMAIL PROTECTED]> wrote:
[...] > > mmmm... se enchufas varios dispositivos en un PC estes comparten el > > BUS y cuanto mas dispositivos, menor sera el desempeno.. > > En teoria. Que pueda medirse en la practica es otro cuento... si el bus da > mas que la suma de las Eth, no hay drama. Si quieres maximo rendimiento, > piensa en una tarjeta multi-Eth, y/o tarjetas de red mas sofisticadas > (filtros por MAC mas complejos, CRC en hardware, mayor memoria para frames > recibidos/por enviar, ...). En teoria, con las 4/5 tarjetas mencionadas + disco (esto sin considerar otros dispositivos que comparten el BUS)... ya deberian de ser suficientes para superar los 133MB/s del BUS pci !!! mmmm... por cierto. estamos suponiendo que las tarjetas son de 100Mb/s... se son tarjetas de red de 1G en barramentos PCI de 32bits... olvidalo...bastaria una sola para saturar el BUS !!! > > a no ser que estes utilizes un sistema NUMA y que associes diferentes > > BUS/CPUs a los dispositivos... > > Urgh. alguna mala experiencia que queira compartir ??? > > > o existe algun mastering que encola peticiones irq para placas de red y > > > les da la misma prioridad de uso de cpu? > > > En el lado SW, tenemos básicamente dos cosas: > > - scheduler > > Nada tiene que ver con el manejo de IRQs, administra procesos (tasks). por esto agregar las iniciales de software (SW) a mi frase !! :-D pero tienes razon... nada que ver scheduler con el tema de IRQ... sorry . > > - un comando (creo que era tasksel) > > No esta por aca. Hay taskset(8), que asocia un proceso con una CPU, pero > eso es otro tema. mmm... si..creo que era taskset !!!! > > El scheduler distribuye cargas y con el comando puedes asociar tu > > mismo los procesos. > > Con que? puedes asociar los procesos con las CPUs. salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
