Let's compare 3coms and eepro100s. And the effects of MMIO versus PIO, and other stuff. 3c905C 3c905C 3c905C 3c905C 3c905C eepro100 eepro100 eepro100 CPU affine ints rx pps tx pps MMIO I/O ops ints 2
The Intel driver (e100.c) uploads special firmware and does it for RX and TX. eepro100 doesn't. Perhaps you could measure that driver too? It unfortunately doesn't support zc. iirc Ingo at some point
Sure. Anyone have a URL for intel's driver? mm... My cycle soaker is not aggressive enough in its generation of memory traffic. I think I need to tune it so when all CPUs are 'soaking', memory traffi
Hello! This was due to pushes made by 4K writes used by old sendfile(). Pretty silly feature, but it seems to be required. 25% of packets are better than full collapse in some cases. Sigh... In any c
Hello! Interesting. 0.9% is ridiculously small, but 2.5% is some big number. 8)8) Actually, I am not sure that mmio improves something in your case. Even these 0.9% can be random or systematic error.
Ingo or Don Becker (sorry don't remember if it was Ingo or Don) did some tests showing that the write speed to IO ports was about 10 times the slower and read about 5 times slower. There is also the
Ah. Thanks. It's good to have an explanation :) In my testing, in all cases, at all times, with all NICs, the link is 100% saturated. I don't need another dimension to deal with!
Interesting. Question: when the CPU reads from a PCI location, are the CPU <-> PCI bridge buses blocked for the duration of the read, or does the PCI bridge reconnect? I'm guessing that the major ben
My vague recollection is: 1) Any old style IO flushes fifos in both directions in the path on the PCI bus to the device before the transaction is even started. 2) As mentioned, writes cannot be poste
Hi, That's about RX mitigation, where a special hardware assistance is required. For TX interrupts, the current driver arbitrarily asks for a TX interrupt every forth packet (to do garbage collection