On 04/02/2011, at 13:26, Daniel O'Connor wrote:
> I am writing a program which reads from a data acquisition chassis connected
> to a radar via USB. The interface is a Cypress FX2 and I am communicating via
> libusb.
I ended up writing a kernel driver (thank you hps for usb_fifo_*!) and it has
On 04/02/2011, at 13:26, Daniel O'Connor wrote:
> I only have about 10 milliseconds of buffering (96kbyte FIFO, 8Mbyte/sec) in
> the hardware, however I have about 128Mb of USB requests queued up to libusb.
> hps@ informed me that libusb will only queue 16kbyte (2msec) in the kernel at
> one ti
On 11/02/2011, at 6:58, Matthew Dillon wrote:
> It sounds like there are at least two issues involved.
>
> The first could be a buffer cache starvation issue due to the load on
> the filesystem from the tar. If the usb program is doing any filesystem
> operation at all, even at low bandw
It sounds like there are at least two issues involved.
The first could be a buffer cache starvation issue due to the load on
the filesystem from the tar. If the usb program is doing any filesystem
operation at all, even at low bandwidths, it could be hitting blockages
due to the di
On 07/02/2011, at 23:36, Ivan Voras wrote:
>> OK, I wrote the data to /dev/null from USB and ran diskutil in a loop and it
>> doesn't drop out.
>
> Maybe I misunderstood you and it's a different problem than what I was
> experiencing; is this a better description of your problem:
>
> 1) you hav
On 7 February 2011 13:38, Daniel O'Connor wrote:
>>> I am writing directly to /dev/ad10 but stressing /dev/ad14 (sudo tar -cf
>>> /dev/null /local0)
>>
>> Can you do only one of those things? I.e. leave all the file systems
>> alone and just do something like 'diskinfo -vt /dev/ad14'?
>
> OK, I
On 07/02/2011, at 21:07, Ivan Voras wrote:
>>> I'm also interested in raw device vs file system access!
>>
>> Oops, sorry.. I just tried that now but it doesn't improve things :(
>
> Meaning: you still get jitter?
Yes, well I didn't measure the read frequency but it dropped out (stopped
stream
On 07/02/2011 04:12, Daniel O'Connor wrote:
>
> On 07/02/2011, at 13:02, Ivan Voras wrote:
I'll be looking at it on Monday, I will let you know :)
>>>
>>> No luck with mlock() so it wouldn't appear to be paging is the issue :(
>>
>> I'm also interested in raw device vs file system access!
>
>
On 07/02/2011, at 13:02, Ivan Voras wrote:
>>> I'll be looking at it on Monday, I will let you know :)
>>
>> No luck with mlock() so it wouldn't appear to be paging is the issue :(
>
> I'm also interested in raw device vs file system access!
Oops, sorry.. I just tried that now but it doesn't im
On 7 February 2011 02:41, Daniel O'Connor wrote:
>
> On 05/02/2011, at 12:43, Daniel O'Connor wrote:
>> On 05/02/2011, at 11:09, Ivan Voras wrote:
It doesn't allocate memory once it's going, everything is preallocated
before the data transfer starts.
I'll have a go with mlock(
On 05/02/2011, at 12:43, Daniel O'Connor wrote:
> On 05/02/2011, at 11:09, Ivan Voras wrote:
>>> It doesn't allocate memory once it's going, everything is preallocated
>>> before the data transfer starts.
>>>
>>> I'll have a go with mlock() and see what happens.
>>
>> Did you find anything inte
On 05/02/2011, at 11:09, Ivan Voras wrote:
>> It doesn't allocate memory once it's going, everything is preallocated
>> before the data transfer starts.
>>
>> I'll have a go with mlock() and see what happens.
>
> Did you find anything interesting?
I'll be looking at it on Monday, I will let yo
On 04/02/2011 12:45, Daniel O'Connor wrote:
On 04/02/2011, at 21:48, Ivan Voras wrote:
I am wondering if this is a scheduler problem (or I am expecting too much :) in
that it is not running my libusb thread reliably under load. The other
possibility is that it is a USB issue, although I am lo
On 04/02/2011, at 21:48, Ivan Voras wrote:
>> I am wondering if this is a scheduler problem (or I am expecting too much :)
>> in that it is not running my libusb thread reliably under load. The other
>> possibility is that it is a USB issue, although I am looking at using
>> isochronous transfe
On 04/02/2011 03:56, Daniel O'Connor wrote:
I hooked up a logic analyser and I can see most of the time it's fairly
regularly transferring 16k of data every 2msec.
If I load up the disk by, eg, tar -cf /dev/null /local0 I find it drops out and
I can see gaps in the transfers until eventually
On Sat, Oct 9, 2010 at 4:46 PM, Eknath Venkataramani
wrote:
> D&I of the FreeBSD Operating System says it's gonna refer to the BSD default
> scheduler, the 'time share scheduler' does this mean sched_4BSD.c(In the
> introduction section of Chapter 4) handles only time-share process?
> If so, then
16 matches
Mail list logo
