public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: "Aleksandr V. Piskunov" <aleksandr.v.piskunov@gmail.com>,
	Markus Rechberger <mrechberger@gmail.com>,
	Clinton Meyer <clintonmeyer22@gmail.com>,
	Linux Media <linux-media@vger.kernel.org>
Subject: Re: LinuxTV firmware blocks all wireless connections / traffic
Date: Thu, 10 Sep 2009 19:48:54 +0300	[thread overview]
Message-ID: <4AA92DF6.80107@iki.fi> (raw)
In-Reply-To: <829197380909100912xdb34da0s55587f6fe9c0f1d5@mail.gmail.com>

Devin Heitmueller wrote:
> On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaari<crope@iki.fi> wrote:
>> Devin Heitmueller wrote:
>>> The URB size is something that varies on a device-by-device basis,
>>> depending on the bridge chipset.   There really is no
>>> "one-size-fits-all" value you can assume.
>> I doubt no. I tested last week rather many USB chips and all I tested
>> allowed to set it as x188 or x512 bytes. If it is set something than chip
>> does not like it will give errors or packets that are not as large as
>> requested. You can test that easily, look dvb-usb module debug uxfer and use
>> powertop.
>>
>>> I usually take a look at a USB trace of the device under Windows, and
>>> then use the same value.
>> I have seen logs where different sizes of urbs used even same chip.
> 
> Yes, the URB size can change depending on who wrote the driver, or
> what the required throughput is.  For example, the em28xx has a
> different URB size depending on whether the target application is
> 19Mbps ATSC or 38Mbps QAM.  That just reinforces what I'm saying - the
> size selected in many cases is determined by the requirements of the
> chipset.

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?

> Making it some multiple of 188 for DVB is logical since that's the
> MPEG packet size.  That seems pretty common in the bridges I have
> worked with.
> 
> Devin


Antti
-- 
http://palosaari.fi/

  reply	other threads:[~2009-09-10 16:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-09 21:43 LinuxTV firmware blocks all wireless connections / traffic Clinton Meyer
2009-09-09 21:59 ` Devin Heitmueller
2009-09-10  9:14   ` Aleksandr V. Piskunov
2009-09-10 10:58     ` Markus Rechberger
2009-09-10 12:45       ` Aleksandr V. Piskunov
2009-09-10 12:48         ` Aleksandr V. Piskunov
2009-09-10 13:12           ` Antti Palosaari
2009-09-10 13:41             ` Aleksandr V. Piskunov
2009-09-10 13:47               ` Antti Palosaari
2009-09-10 14:48                 ` Antti Palosaari
2009-09-10 15:26                   ` Devin Heitmueller
2009-09-10 15:55                     ` Antti Palosaari
2009-09-10 16:12                       ` Devin Heitmueller
2009-09-10 16:48                         ` Antti Palosaari [this message]
2009-09-10 17:17                           ` Devin Heitmueller
2009-09-10 20:29                             ` Antti Palosaari
2009-09-10 20:45                               ` Devin Heitmueller
2009-09-10 17:16                   ` Aleksandr V. Piskunov
2009-09-10 19:39                     ` Aleksandr V. Piskunov
2009-09-11 14:38                       ` Antti Palosaari
2009-09-11 17:50                         ` Aleksandr V. Piskunov
2009-09-11 18:01                           ` Devin Heitmueller
2009-09-11 19:47                           ` Antti Palosaari
2009-09-12 15:46                           ` CityK

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AA92DF6.80107@iki.fi \
    --to=crope@iki.fi \
    --cc=aleksandr.v.piskunov@gmail.com \
    --cc=clintonmeyer22@gmail.com \
    --cc=dheitmueller@kernellabs.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mrechberger@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox