I saw you mentioning this before, but my knowledge
of usb-management (let alone asynchronous urbs is
small); where can I find info on this?
Plus the fact, that I promised to try the kernel-mode
progs...
Ah yes, it keeps me from regular work..
Ciao too,
Ok
Duncan Sands wrote:
>>What
> What I do at the moment is:
> get from usb
> write into pipe
> get from usb
> write into pipe
> etc.
> I can't get any faster that that (prio is -20)
Yes you can: submit urbs asynchronously.
Then the processor can get on with the write
into the pipe business while the USB hu
It looks like glued together frames, I remember seeing
a filler-cell with a normal pti of 0.
According to what I find on internet, this should be
negotiable with the isp, when a connection is up.
I read something about the qos and the setting of
a Maximum Burst Size...does that ring 1 or
more
On Wed, 28 May 2003, Ok Overbeek (mz) wrote:
>
> Don't look at the CRC-stuff; it could never interfere...
> It is the size of the block I get (straight from the incoming
> urb)!!
>
>
Ok. I've got an idea - no guarantees though.
Given the size of your reads, multiple frames are being sent over
Don't look at the CRC-stuff; it could never interfere...
It is the size of the block I get (straight from the incoming
urb)!!
Tim Woodall wrote:
>On Wed, 28 May 2003, Ok Overbeek (mz) wrote:
>
>
>
>>Still hacking along, guys; I made a simple
>>pipe-version for the usb-read-part, but
>>that
On Wed, 28 May 2003, Ok Overbeek (mz) wrote:
>
> Still hacking along, guys; I made a simple
> pipe-version for the usb-read-part, but
> that gave no difference.
> In the meantime I found something else though:
> I always get a CRC-error, when the amount of
> data as read from the modem is abnor
Still hacking along, guys; I made a simple
pipe-version for the usb-read-part, but
that gave no difference.
In the meantime I found something else though:
I always get a CRC-error, when the amount of
data as read from the modem is abnormally (??)
large, i.e. larger than 1696..
The regular s
