When I user the ieee1394 subsystem to transmit data from a camcorder to an
IDE disk and the IDE driver is not using DMA, then there will be some data
lost in the ieee1394 driver. If I turn on DMA in the IDE driver (hdparm -d1
/dev/hda), I do not have any data loss in the ieee1394 driver. Also, on a
system that is using a SCSI disk instead of an IDE disk everything is ok
This behavior has been observed on several different systems. I can
reproduce it on my system with kernel 2.2.16 and 2.4.0 test10 with several
versions of the ieee1394 driver.
My guess is that using the non-DMA mode in the IDE driver is somehow more
demanding compared to the DMA mode. Since both IDE and ieee1394 chips are
accessed via the PCI bus, perhaps the traffic is so high that the ieee1394
data doesn't make it through. But this is just a guess.
The data rate from the camcorder is about 3.6 MByte/sec, the hdparm -Tt
benchmark show 4.5 MByte/sec transfer speed when not using DMA and 19
MByte/sec when using DMA. (However even the slow disk speed is fast enough
to store the video data. The video packets get lost at the ieee1394 driver
side, not when attempting writing them to a disk file).
Another thing is that there is no handshake available between camcorder and
ieee1394 interface (it wouldn't make sense for a video appplication). If
the interface is not listening, the dropped packet can't be retransmitted.
Any insights into the nature of this problem would be very appreciated.
(I am not the developer of the ieee1394 driver, just a (currently unhappy)
user of both ieee1394 and IDE driver)
AS> When I user the ieee1394 subsystem to transmit data from a camcorder to an
AS> IDE disk and the IDE driver is not using DMA, then there will be some data
AS> lost in the ieee1394 driver. If I turn on DMA in the IDE driver (hdparm -d1
AS> /dev/hda), I do not have any data loss in the ieee1394 driver. Also, on a
IDE is blocking interrupts for too long in non-DMA mode? Try hdparm -u 1
in non-dma mode - this may help if interrupt latency is the issue.
Meelis Roos ([email protected])