Re: LinuxTV firmware blocks all wireless connections / traffic

[Antti Palosaari <crope@iki.fi>]

On 09/10/2009 08:17 PM, Devin Heitmueller wrote:
> On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaari<crope@iki.fi>  wrote:
>> Yes thats just what I tried to say for. Look my previous thread where all
>> currently sizes are listed. We need to define suitable values that are used.
>> For example USB2.0 DVB-C, DVB-T, ATSC and same values for USB1.1 too. And
>> stream size can vary much depending used transmission parameters too but I
>> think such kind resolution logic is not needed.
>>
>> Currently there is almost everything between 512 to 65k used for DVB-T that
>> makes huge difference to load device causing.
>>
>> Does anyone know if there is some table which says what are good USB
>> transmission parameters for each bandwidth needed?
>
> The problem is that there cannot be any single set of rules that apply
> to all devices.  For each chip, the rules are different and either
> need to be reverse engineered by the maintainer or someone has to
> refer to the datasheet if available.

Eh, not all needed, but we need some kind of rule of thumb which URB 
size is suitable for bandwidth used. 512, 8k, 16k etc. It is not wise at 
all set it to only 512 bytes when streaming whole TS example 22Mbit/sec. 
I have tested Anysee (Cypress FX2), AF9015, CE6230, RTL2831U and all 
those allowed to set URB rather freely. I haven't seen yet device which 
forces to use just one size - though it is possible there is. And no 
datasheet even needed, you can see from debug log or error code if URB 
is not suitable.
Why not set it some good value when possible? And also adding module 
parameter which overrides driver default is not hard to add, just look 
value user gives as param and round it to nearest suitable one.

> It comes as no surprise that there is a huge variation on the URB
> sizes chosen, and there is almost certainly an opportunity for
> improvement on most bridges.  I suspect the logic applied by most of
> the people who wrote the bridge drivers was to find the first value
> that "works" and then not do any subsequent tuning/optimization.  Like
> the situation with power management or tuning time, this just doesn't
> seem to have been a priority.  And given how few developers we have
> actually fixing bugs, adding support for new boards, and writing new
> drivers, I can hardly blame them.

Of course it is easiest to set as small as possible, 512 or 188 usually 
and it is working. wakeups are then very high but not much buffers needed.

> Unfortunately, with limited resources, we have to pick our battles -
> which is more important:  having a slightly more optimal allocation
> that produces fewer wakeups?  Or getting new product XYZ to work and
> fixing bugs that are highly visible to end-users?
>
> Devin
>

Antti
-- 
http://palosaari.fi/