On Fri, May 23, 2014 at 3:08 AM, Micah Dombrowski <mpdwibble@xxxxxxxxx> wrote: > On May 22, 2014, at 12:34 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > >> Does the T530 have enough oomph to do all this? >> ... >> Can the T530 keep up if you drop the >> processing and output side of the equation? > > It should have plenty of bandwidth for the 4020 side, as we returned one of these to Lenovo for them to test, and they were able to get well over 100 MBps through the Expresscard slot under Windows. We found similar results with a USB 3.0 Expresscard under Linux. Different types of cards will get different throughput depending on how much they transfer per interrupt and how much work the interrupt handler does. It takes the 4020 about 16K interrupts to transfer 500MB of data. At 80MBps, that's about 2500 interrupts per second, which doesn't sound completely unreasonable. One interesting thing is that on the PC, almost all of the interrupts go to cpu1, while on the T530, they're more scattered. I don't know how much sharing of caches and so on there is between the CPUs, but I don't think there's parallelization benefit for the driver and there might be a cost. You could experiment with the "nosmp" kernel option. (Of course, parallelization probably *does* help with running the processing and output side.) I wonder if you could learn anything about the system load with "perf". I haven't used it myself, so I'm afraid I can't give any useful advice about it. >> I don't understand how the "apci=off noapic" thing would make a >> difference here, so maybe that's a good clue. Can you collect the >> same sort of info (dmesg, lspci -vv, /proc/interrupts info) with that >> configuration? > > I’ve attached these to the report, but after much more fiddling with it in this mode (looking closely at the incoming data), I now don’t believe this is actually fixing anything. It makes some of the timing _appear_ better, sometimes, but I think that’s just due to random slowdowns or something. OK, that's good, because it would be quite strange if it made a difference. > The most strange thing in the data is shown in the .jpeg file I’ve attached to the report: https://bugzilla.kernel.org/show_bug.cgi?id=76641#c11 …I have no idea. > > One more thing: I made one change to the comedi driver that I knew about, which is to change the size of the ‘DMA buffer’ that the card uses. The driver comes with this set to 0x1000, but I was advised years ago to set this to 0x8000 for our continuous high-speed stuff, and that’s what all of the prior testing has been at. I tried changing this to 0x2000 and 0x1000—neither made any difference to the sane sample lengths above. I really don't see a PCI or interrupt configuration issue yet, so I'm not sure how much more I can contribute here. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
