linux-kernel - Re: In-tree version of new FireWire drivers available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Jan 2007 06:07:29 -0700
From:	"Robert Crocombe" <rcrocomb@...il.com>
To:	linux1394-devel@...ts.sourceforge.net,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: In-tree version of new FireWire drivers available

On 1/25/07, Pieter Palmers <pieterp@...w.be> wrote:
> I'd like to make one note here:
> We should have a way to use smaller DMA buffers than one page size. If I
> remember correctly, the page size on my system is 4096 bytes, being 1024
> quadlets. If we assume a 4 channel audio stream, this corresponds to 256
> audio samples. This means that the controller generates an interrupt
> every 256 samples, making that we can achieve a latency of 512 samples
> at best. This is unacceptable in a pro-audio environment.
>
> The current stack exhibits this problem, and I solve it by recalculating
> the max packet size, based upon the stream composition (i.e. expected
> packet size) and the requested audio buffer size, such that the
> interrupts are generated at a high enough frequency.
>
> I'm not a kernel hacker, but when looking through the code I had the
> impression that smaller DMA buffers were possible (aren't smaller
> buffers used in packet-per-buffer mode?).

I am using isochronous receive in RAW1394_DMA_PACKET_PER_BUFFER mode
because I am closing a simulation loop around the data that is
received/transmitted.  Just for giggles I cranked up a test
isochronous stream from a bus analyzer at 1kB per packet at 8kHz at
the S400 rate (i.e., one packet on each cycle start: 8MBps ), set the
machine up to listen, and was able to maintain 8kHz interrupts at ~12%
CPU utilization on a 2.8GHz Opteron.

   1744719 interrupts int 218.112 seconds is 7999.193 ints/sec

I wasn't doing anything with the data for this test, but I have had
the aforementioned sim running steady at a somewhat lower rate.  This
test ran under 2.6.20-rc5-rt10, but the more "productiony" system is
on 2.6.16-rt29.

So hopefully you can get markedly lower latencies.  Myself, I'm
tickled pink by the performance that can be achieved.

-- 
Robert Crocombe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/