On Sun, 2008-11-23 at 10:49 -0500, Brandon Jenkins wrote: > On Nov 23, 2008, at 10:31 AM, Andy Walls wrote: > > All in all you're in good shape. Your system appears to have low > > enough > > interrupt service latency to meet the demands of the firmware. (At > > least one ivtv-users list user has a system that is having real > > trouble > > meeting the interrupt service latency timeline of the firmware. I may > > have to add a polled mailbox IO mode to the driver for these systems > > to > > use.) > > > > > > Again a lot of this was going on previously, it's just that the cx18 > > driver never bothered to look for it on incoming DMA done > > notifications, > > report the precise condition in the logs, or correct for it very well. > > > > Thanks for the testing and providing data! > > > > Regards, > > Andy > > > >> Brandon > > > > > Andy, > > A couple of points to note: > 1) cx18-2 was the only board making use of analog and hd recordings. > The other devices were only performing HD OTA captures. Brandon, With simlutaneous streams and that *few* warnings about the firmware self-acking mailboxes it sends, you really do have a responsive system. I should emphasize that the driver reading the firmware's self-acked mailbox can lead to dropped buffers because that the firmware may be in the process of modifying the mailbox. In practice, it's rare that the firmware has actually modified the mailbox by the time the IRQ handler gets to it - at least in multi-core or lightly loaded machines. That's why the cx18 driver has been working acceptably for most users since it's initial release. Simultaneous captures makes sense as to why the firmware would be found more frequently self-acking the mailboxes it sends. I do not know the firmware's real, minimum latency requirement for the host driver sending an ack response to a mailbox. I do know that having two streams going at once is going to have the firmware require the minimum latency of the host driver more frequently. I got the cx18 top half IRQ handler (cx18_irq_handler() and it's supporting routines in cx18-mailbox.c) down to around 46-50 usec execution time from start to finish on my dual core AMD64 machine. There's not much room for improvement, as most of that 46-50 usec is PCI MMIO accesses that can't be avoided or sped up. The kernel will necessarily serialize servicing of the interrupts from a particular CX23418. It is conceivable, that the two interrupts from the CX23418 may be coming in very close together, but that the needed serialization is putting some delay (e.g. ~ 46-50 usec under some scenarios) in the timeline of servicing the second one. > 2) cx18-2 shares irqs with: ls /proc/irq/18/ cx18-2 ehci_hcd:usb4 > smp_affinity spurious uhci_hcd:usb3 uhci_hcd:usb7. Can I use irq17? > nothing seems to be on this. If those particular USB host adapters aren't busy, then there is not much point in trying to avoid the sharing AFAIK. A USB IR dongle would not be a big deal; a USB disk or USB video capture device that is active would be a concern. The only *easy* ways I know to get a PCI card to use a different IRQ are a) move it to a different slot or b) try and configure it explicitly in the BIOS. I've only had success with moving to a physically different slot. > 3) This is actually a quad core cpu. Which is probably why you don't need to worry. The way to get determinism out of any shared resource, like capacity for processing interrupts, is to use a) over-provisioning (having more processors to process interrupts from various devices) b) QoS (some interrupts have priority over others with a deterministic priority scheme) Regards, Andy > Thanks, > > Brandon _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
