Re: [libdc] Dual- & Quad-Core problems
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
Menu
▾
▴
Re: [libdc] Dual- & Quad-Core problems
|
From: vagvoba <va...@ya...> - 2009-11-24 13:27:39
|
Hi guys,
I had a very similar setup with the same issues:
- 2 * Grasshoppers
- Dell precision 7500 8 core workstation
- 2 * TI TSB82AA2 controllers on PCIe
I fought the issue for a long while in software. I tried everything but nothing worked. Eventually it turned out that the TI chipset on the FireWire boards are pretty old PCI chips. In order to make them working on PCIe, the manufacturer put a PCI to PCIe bridge on each card so that the TI chip can communicate with the bus. Unfortunately this solution is flawed: the old TI FireWire chip paired with the questionable quality bridge creates a huge bottleneck.
So I looked up native PCIe IEEE1394b controllers online and bought one. The result is that all the image corruption is gone. Actually, I ended up buying the highest end Pointgrey interface board, which has dual controller on it ($200), so I now can drive both Grasshoppers with one card full speed (1600*1200, 30fps, color) without glitches.
Btw, I use Ubuntu 9.10 now but it worked on 9.04 too.
Hope it helps.
Balazs
On Nov 24, 2009, at 7:23 AM, Stefan Richter <st...@s5...> wrote:
Damir Anicic wrote:
Well, the same problem with the newer kernel!
Now I took your advice, Installed Fedora12 (kernel 2.6.31.5-127.fc12),
This is very appreciated because the 2.6.18 drivers which you used
before contained known DMA related bugs, as mentioned. At least these
bugs are out of the picture now.
[...]
My firewire card is (but same problem with other cards, too)
FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link
Layer Controller (rev 01)
My camera is:
Point Grey Research Grasshopper GRAS-20S4C
(I.e. FireWire 800 controller and camera.)
!!! THE SAME PROBLEM AS WITH ScientificLinux 5.1 !!!
Which is interesting since Fedora's FireWire drivers were rewritten from
scratch and are therefore completely different from those in SL.
firewire-ohci and video1394 even use different DMA modes of the OHCI
hardware.
DualCore system - BOTH cores active:
Format_2, Mode_4: 1600x1200 RGB 24bpp 1.875 fps -
10'800'000 bytes/sec - works fine
Format_2, Mode_4: 1600x1200 RGB 24bpp 3.75 fps -
21'600'000 bytes/sec - repeat {about 1 second OK, then 1 sec of
garbled images} - does not block PC
Format_2, Mode_4: 1600x1200 RGB 24bpp 7.5 fps -
42'300'000 bytes/sec - repeat {about 1 second OK, then 1 sec of
garbled images} - does not block PC
(43'200'000 B/s actually.)
So, the only improvement is that PC does not block (or maybe I did not
wait long enough)
I think a while ago there was another report about the old video1394
driver that it could lock up if programmed with unusual parameters.
Although this is a comparably serious issue which can presumably be
triggered by a crafted program and with access permission to
/dev/video1394* (usually granted to normal users, but video1394 is not
automatically loaded unless matching hardware is plugged in), it is
unlikely that anybody is going to fix this anymore. (Since video1394 is
superseded by the new firewire drivers --- which most definitely are
meant to be free of lock-up bugs...)
BUT
DualCore system - ONLY ONE core active (maxcpus=1):
Format_2, Mode_4: 1600x1200 RGB 24bpp 1.875 fps -
10'800'000 bytes/sec - works fine
Format_2, Mode_4: 1600x1200 RGB 24bpp 3.75 fps -
21'600'000 bytes/sec - works fine
Format_2, Mode_4: 1600x1200 RGB 24bpp 7.5 fps -
42'300'000 bytes/sec - works fine
Any comments/sugestions ?
PC I used has:
Intel(R) Core(TM)2 Duo E8400 @ 3.00 Ghz
2 GB RAM
The test was done with coriander (not with my application)
Very curious. Hopefully somebody more familiar with coriander's
implementation can comment on this factor, i.e. whether its FireWire
capturing component and its display or storage component are
appropriately serialized.
In the kernel, video reception events are handled by so-called tasklets
which are serial by nature, and buffer queuing by application software
(via libdc1394) is serialized by respective locks. Which doesn't mean
that there couldn't still be bugs lurking somewhere of course. But I
would be surprised if there were general SMP bugs in there because (a)
concurrency issues in the kernel are very well understood these days and
(b) certainly a majority of IIDC camera users on Linux use SMP boxes
these days (multicore CPUs, possibly HT enabled CPUs and kernels). I
for am not actually an IIDC user myself, I'm just receiving this mailing
list because of involvement with the firewire kernel drivers. I only
got a humble Unibrain Fire-i camera for my testing purposes, and that
one works perfectly fine in all its supported modes on various
controllers on an AMD based and an Intel based multicore PC, with
Coriander 2.0.0 (actually a CVS checkout from May or so).
One potential issue with FireWire 800 cameras which I still need to
investigate is that high-bandwidth streams require FireWire packet sizes
which are larger than the kernel's memory page size on x86 and x86-64 (4
kBytes). Also, I need to have a look at how libdc1394 aligns packets in
the DMA buffer. (This is also something which I still need to
investigate in conjunction with the Agere controller related patch which
was mentioned in Samuel Audet's response.) However, while the kernel
drivers could have an issue with large packets from high-bandwidth
streams, it's hard to see how SMP vs. uniprocessor could trigger such an
issue. (More precisely, SMP vs. SMP kernel which is limited to use one
core only.)
One more look at your video workload:
10'800'000 B/s = 1350 bytes payload per packet = requires S200 or more
21'600'000 B/s = 2700 bytes payload per packet = requires S400 or more
43'200'000 B/s = 5400 bytes payload per packet = requires S800 or more
Background: In case of isochronous data transfers like video streams,
FireWire packets are sent in intervals of 125 microseconds. IIDC
requires that a single packet per interval per video stream is used.
IEEE 1394 requires that isochronous packets do not carry payloads larger
than 4096 bytes at S400, 8192 bytes at S800, etc.
(The most demanding mode which my test camera supports seems to be
640x480x24 @15fps (format 0 mode 4), i.e. 13'824'000 B/s. Getting a
higher speed camera is on my mid-term plan.)
So, there is already one potential issue here but this is per se still
independent of SMP vs. uniprocessor: Make sure that you configure the
streams for a bus speed at least as high as listed above.
The other issue is that each packet of the 43'200'000 B/s stream will
land in two separate memory pages. This should work in theory because
(a) the buffer management code of the new firewire drivers are at least
intended to accept such large packets (need to check whether they really
live up to it), (b) the OHCI 1394 specification requires controllers to
support wrap-over of packets from on page to another physically disjunct
page, (c) the kernel's memory management subsystem presents those
physically disjunct pages as one contiguous memory region to userspace,
e.g. libdc1394 and Coriander.
However, some FireWire controllers might not live up to requirement (b).
This is something we still need to investigate, and such things are
typically not known from published errata. But again, I don't see how
SMP vs. uniprocessor could influence that issue, although it is not
impossible that there are obscure interactions. So, I'm puzzled where
to look next.
--
Stefan Richter
-=====-==--= =-== ==---
http://arcgraph.de/sr/
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mailing list for libdc1394-devel
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel
|