Message-ID: <CAHFNz9JUV6wabQxsvrxPRX6q41sWNMDy8DJcOpNTecNTbL=XaQ@mail.gmail.com>
Date:	Thu, 13 Oct 2011 09:33:21 +0530
From:	Manu Abraham <abraham.manu@...il.com>
To:	Markus Rechberger <mrechberger@...il.com>
Cc:	Greg KH <gregkh@...e.de>, Alan Stern <stern@...land.harvard.edu>,
	USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

Hello Markus,

On Thu, Oct 13, 2011 at 3:39 AM, Markus Rechberger
<mrechberger@...il.com> wrote:
> On Wed, Oct 12, 2011 at 11:48 PM, Markus Rechberger
> <mrechberger@...il.com> wrote:
>> On Wed, Oct 12, 2011 at 10:33 PM, Greg KH <gregkh@...e.de> wrote:
>>> On Wed, Oct 12, 2011 at 06:59:01PM +0200, Markus Rechberger wrote:
>>>> On Wed, Oct 12, 2011 at 4:17 PM, Greg KH <gregkh@...e.de> wrote:
>>>> > On Wed, Oct 12, 2011 at 02:36:59PM +0200, Markus Rechberger wrote:
>>>> >> We have 2 products which can perform better with increased Bulk transfers
>>>> >
>>>> > I don't believe you :)
>>>> >
>>>> > As stated before, this patch is not acceptable.  Please work to figure
>>>> > out the real reason for your device problems here, this is not the
>>>> > correct solution at all.
>>>> >
>>>>
>>>> OK no device support for linux then. Windows and MacOSX are fine.
>>>
>>> That is your choice, not ours, as you are the one writing the closed
>>> source code.  Without usbmon dumps, showing that the problem really is
>>> in the kernel code, we can't do anything for you here.
>>>
>>
>>
>> here take your usbmon logs:
>> http://sundtek.de/support/working.log
>> http://sundtek.de/support/notworking.log (this is with your proposed
>> split up of 22k).
>>
>> Isochronous already supports up to 190kb buffers which cause no
>> trouble anywhere.
>> Bulk is castrated to 15kb buffers and 50kb should be such a big issue
>> while applications
>> which do not request it are not affected at all.
>>
>> I'm very angry that you do not really focus on what I write and just
>> try to write stories about
>> bogus things like my patch might break other applications while I
>> pointed out that this is not
>> possible with legacy applications which use this interface. It is not
>> even possible to read the
>> maximum buffer value from the kernelspace.
>>
>> Your bogus message about 1Gig ram you can put it elsewhere, I checked
>> multiple windows drivers
>> in the past the buffer size varies between small and something around
>> 50k usually.
>> I would fully like to avoid to patch this kernel to get those things
>> work because I don't want to
>> deal with people who just write around the actual issues.
>>
>> Alsi the fact that bigger buffers are already being used plus the HW
>> specifications of our main device also points out to a certain
>> buffersize near 50k. But of course you are the smart knowitall without
>> the need of explanation why
>> those things can be affected by HW and some HW chips have options to
>> influence that buffer size.
>
> And for those who are curious about the logfiles:
> Not working one as proposed by Alan that the full buffer size should
> be split into 2 requests:
>
> ffff8800b38d9f00 1231540351 S Bi:2:013:1 -115 12288 <
> ffff8800b38d96c0 1231540404 S Bi:2:013:1 -115 11776 <
> ffff8800b38d9cc0 1231540440 S Bi:2:013:1 -115 12288 <
> ffff880002ede600 1231540496 S Bi:2:013:1 -115 11776 <
> ffff8800b38d9f00 1231545491 C Bi:2:013:1 0 12288 = 7a1a0840 1ca8353c
> 004b80ec 4de08401 2f0227f8 34005e7e 80181dfd 1a8f700a
> ffff88007d51fb40 1231545875 S Bi:2:013:1 -115 12288 <
> ffff8800b38d96c0 1231551861 C Bi:2:013:1 0 11776 = 5244e386 a7800000
> 010642ea 35bfbba5 373e738b cc035a73 c328a1ff 4da728ce
> ffff880002ede0c0 1231556173 S Bi:2:013:1 -115 11776 <
> ffff8800b38d9cc0 1231558618 C Bi:2:013:1 0 12288 = db91aae9 2d2532f3
> 2e37448a fb36c213 55dda2ad 243122b2 261edb06 875848ac
>
>
> 12288 = 7a1a0840 every Line with 12288 should start with 47 (MPEG-TS Sync byte)
>
> The working one which allocate 7000 bytes more (oh really big memory
> pressure now!)  than this castrated USBFS interface allows.
>
> ffff88003ac37240 992178919 S Bi:2:013:1 -115 24064 <
> ffff88003ac37000 992178953 S Bi:2:013:1 -115 24064 <
> ffff88003ac37c00 992178980 S Bi:2:013:1 -115 24064 <
> ffff88003ac37e40 992179003 S Bi:2:013:1 -115 24064 <
> ffff88003ac37240 992190198 C Bi:2:013:1 0 24064 = 471fff10 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000
> ffff88000601f480 992194368 S Bi:2:013:1 -115 24064 <
> ffff88003ac37000 992203209 C Bi:2:013:1 0 24064 = 4701b114 43867ee6
> 40790660 e898681c 9b1c7dca 08980d43 73181369 9be1bc67
> ffff880067e38a80 992204642 S Bi:2:013:1 -115 24064 <
> ffff88003ac37c00 992216318 C Bi:2:013:1 0 24064 = 4740001c 0000b01d
> 0305d500 000000e0 104015e1 504016e1 60401be1 b04022e2
> ffff880067e383c0 992219978 S Bi:2:013:1 -115 24064 <
> ffff88003ac37e40 992229340 C Bi:2:013:1 0 24064 = 471fff10 00000000
> 00000000 00000000 00000000 00000000 00000000 00000000
>
> everything starts nicely with 0x47

Is the transfer size a multiple of 188 bytes in both cases ? In the
working case, it looks so, but in the broken case ? Many DTV bridges
have fixed DMA apertures and not variable really much, even though the
device specifications do state that it might support different block
sizes, some modes could be broken. I guess most likely, you would have
handled this situation.

Other issues that could possibly happen (wrt your jitter) is a high
latency (in the particular case of failures) where the received data
have unusable relative timestamps wrt DTS and or PTS.

The only areas where you can have a corrupted stream as you mentioned
"jitter" is either lost frames or the above two cases. I don't know
what's the issue in your case, but might help to track down the issue
altogether.

Regards,
Manu
--
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/

Powered by blists - more mailing lists