linux-kernel - Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110623141137.GB4403@tugrik.mns.mnsspb.ru>
Date:	Thu, 23 Jun 2011 18:11:37 +0400
From:	Kirill Smelkov <kirr@....spb.ru>
To:	matt mooney <mfm@...eddisk.com>
Cc:	linux-usb@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	linux-uvc-devel@...ts.berlios.de, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max
	periodic bandwidth

On Wed, Jun 22, 2011 at 10:35:44AM -0700, matt mooney wrote:
> On 10:30 Wed 22 Jun     , matt mooney wrote:
> > On 20:02 Wed 22 Jun     , Kirill Smelkov wrote:
> > > There are cases, when 80% max isochronous bandwidth is too limiting.
> > > 
> > > For example I have two USB video capture cards which stream uncompressed
> > > video, and to stream full NTSC + PAL videos we'd need
> > > 
> > >     NTSC 640x480 YUV422 @30fps      ~17.6 MB/s
> > >     PAL  720x576 YUV422 @25fps      ~19.7 MB/s
> > > 
> > > isoc bandwidth.
> > > 
> > > Now, due to limited alt settings in capture devices NTSC one ends up
> > > streaming with max_pkt_size=2688  and  PAL with max_pkt_size=2892, both
> > > with interval=1. In terms of microframe time allocation this gives
> > > 
> > >     NTSC    ~53us
> > >     PAL     ~57us
> > > 
> > > and together
> > > 
> > >     ~110us  >  100us == 80% of 125us uframe time.
> > > 
> > > So those two devices can't work together simultaneously because the'd
> > > over allocate isochronous bandwidth.
> > > 
> > > 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
> > > both devices started to work together, so I though sometimes it would be
> > > a good idea for users to override hardcoded default of max 80% isoc
> > > bandwidth.
> > 
> > There is nothing arbitrary about 80%. The USB 2.0 Specification constrains
> > periodic transfers for high-speed endpoints to 80% of the microframe. See
> > section 5.6.4.
> > 
> 
> Looking at the patch, I see that you probably already knew that.
> 
> So I digress and defer to the USB experts ;)

Yes, it was meant as 80% being arbitrary chosen by USB 2.0
specification. Notes taken - I'll clarify patch description.


Thanks for commenting,
Kirill
--
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/