Re: LinuxTV firmware blocks all wireless connections / traffic
Aleksandr V. Piskunov wrote: I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... If your googling didn't turn them up already, here's some more threads: http://www.mail-archive.com/search?q=SB700+l=linux-media%40vger.kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Thanks, Antti! Tested your branch on affected system. Load definitely went down, from ~7000 wakeups to ~250 for each tuner according to powertop. Both tuners still working ok if not used simultaneously or if used the same time on different USB controllers. Bad news are that original problem still persists: putting both tuners on same USB controller and zapping simultaneously corrupts stream. Interesting observation: no matter in what sequence tuners are connected (i.e. become adapter0 or adapter1), af9015 stream always gets heavily distorted, visually mplayer picture becomes like 80% corrupted with random color blocks and pixels, sound becomes a mess. At the same time ce6230 gets slight corruption, a few discolored blocks at the time and sound hickups. Anyway, will try to do a few more tests: 1) Two usb flash drives on same controller calculating md5sum of big .iso file, to check if it is/isn't dvb-usb problem. 2) Will see if same issue persists on another PC with same motherboard (slightly different revision) to rule out hardware issues. If I manage to wire antenna there, that is... Ok, two USB flash drives on same controller, no problem when bulk reading from both at the same time, no speed drops, no corruption. Now if I plug ce6230 tuner, zap to channel and then start reading from flash drive: * slightly corrupted TS stream * flash drive read getting starved on bandwidth, speed drops from 10 MB/s to ~7 MB/s If I plug af9015 tuner, zap and read from flash * heavy corruption of TS stream * flash drive read speed drops from 10 MB/s to 2(!) MB/s Now I don't really know the USB protocol under-the-hood details, all the different types of bandwidth, reservation and so on. But shouldn't one 480 Mbit/sec controller handle rather large number of digital tuners, each pushing 20-25 Mbit/sec max, even considering all the overhead? I have no any problems here, ce6230 and af9015 with dual tuners (3x DVB-T 22Mbit/sec TS streams) running same time on same bus. One possibility is that there is RF-noise looping from device to device disturbing USB transfer or RF-signal. I have seen such situation when I connect multiple DVB-C devices to same antenna cable using cheap splitter. Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and af9015 120 wakeups - due to remote polling. You can test if you wish, but results are most likely same as earlier. I cannot do much more. http://linuxtv.org/hg/~anttip/urb_size/ Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Fri, Sep 11, 2009 at 05:38:08PM +0300, Antti Palosaari wrote: On 09/10/2009 10:39 PM, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Thanks, Antti! Tested your branch on affected system. Load definitely went down, from ~7000 wakeups to ~250 for each tuner according to powertop. Both tuners still working ok if not used simultaneously or if used the same time on different USB controllers. Bad news are that original problem still persists: putting both tuners on same USB controller and zapping simultaneously corrupts stream. Interesting observation: no matter in what sequence tuners are connected (i.e. become adapter0 or adapter1), af9015 stream always gets heavily distorted, visually mplayer picture becomes like 80% corrupted with random color blocks and pixels, sound becomes a mess. At the same time ce6230 gets slight corruption, a few discolored blocks at the time and sound hickups. Anyway, will try to do a few more tests: 1) Two usb flash drives on same controller calculating md5sum of big .iso file, to check if it is/isn't dvb-usb problem. 2) Will see if same issue persists on another PC with same motherboard (slightly different revision) to rule out hardware issues. If I manage to wire antenna there, that is... Ok, two USB flash drives on same controller, no problem when bulk reading from both at the same time, no speed drops, no corruption. Now if I plug ce6230 tuner, zap to channel and then start reading from flash drive: * slightly corrupted TS stream * flash drive read getting starved on bandwidth, speed drops from 10 MB/s to ~7 MB/s If I plug af9015 tuner, zap and read from flash * heavy corruption of TS stream * flash drive read speed drops from 10 MB/s to 2(!) MB/s Now I don't really know the USB protocol under-the-hood details, all the different types of bandwidth, reservation and so on. But shouldn't one 480 Mbit/sec controller handle rather large number of digital tuners, each pushing 20-25 Mbit/sec max, even considering all the overhead? I have no any problems here, ce6230 and af9015 with dual tuners (3x DVB-T 22Mbit/sec TS streams) running same time on same bus. One possibility is that there is RF-noise looping from device to device disturbing USB transfer or RF-signal. I have seen such situation when I connect multiple DVB-C devices to same antenna cable using cheap splitter. Anyhow, I increased URB sizes to 65k. Now ce6230 gives 70 wakeups and af9015 120 wakeups - due to remote polling. You can test if you wish, but results are most likely same as earlier. I cannot do much more. http://linuxtv.org/hg/~anttip/urb_size/ Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs.. So using my fresh knowledge I went away and hacked ce6230 to use Isochronous transfer endpoint instead of Bulk one. And it helped, tuner works, no corruption with af9015 running on same controller at the same time. Of course it isn't a fix per se, af9015 still corrupts if I start bulk reading from a flash drive, etc. And there are no Isochronous endpoints on af9015, so no alternative to bulk transfers :) But at least I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... P.S. Rather unrelated question, what type of USB transfer is generally preferred for USB media stream devices, BULK or ISOC? Antti, why did you choose BULK for ce6230? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Fri, Sep 11, 2009 at 1:50 PM, Aleksandr V. Piskunov aleksandr.v.pisku...@gmail.com wrote: Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs.. So using my fresh knowledge I went away and hacked ce6230 to use Isochronous transfer endpoint instead of Bulk one. And it helped, tuner works, no corruption with af9015 running on same controller at the same time. Of course it isn't a fix per se, af9015 still corrupts if I start bulk reading from a flash drive, etc. And there are no Isochronous endpoints on af9015, so no alternative to bulk transfers :) But at least I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... P.S. Rather unrelated question, what type of USB transfer is generally preferred for USB media stream devices, BULK or ISOC? Antti, why did you choose BULK for ce6230? The core difference between bulk and isoc is that with bulk you use get reliable delivery, but there is no reservation of bandwidth (bulk uses all available bandwidth). With isoc, you have reserved the bandwidth up front, but don't have reliable delivery (no retry mechanism, etc). With something like a hard drive, you want to use all available bandwidth, and you can do retries to ensure delivery, making bulk an appropriate choice. However, for streaming video, you usually want the bandwidth reserved up front, because if two devices are using the bus then frames will get dropped (and in a realtime streaming video device, there is no retry capability for dropped packets). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/11/2009 08:50 PM, Aleksandr V. Piskunov wrote: Ok, I did read basics of USB 2.0 protocol, gotta love these 600 page specs.. So using my fresh knowledge I went away and hacked ce6230 to use Isochronous transfer endpoint instead of Bulk one. And it helped, tuner works, no corruption with af9015 running on same controller at the same time. Looks like chipset driver issue as you said. Of course it isn't a fix per se, af9015 still corrupts if I start bulk reading from a flash drive, etc. And there are no Isochronous endpoints on af9015, so no alternative to bulk transfers :) y, correct. Welcome to hacking DVB drivers. But at least I'm getting closer to pinpointing the real problem and so far everything points to AMD SB700 chipset driver. Google says it has quite some hardware bugs and several workarounds in linux drivers... P.S. Rather unrelated question, what type of USB transfer is generally preferred for USB media stream devices, BULK or ISOC? Antti, why did you choose BULK for ce6230? Because chipset Windows driver was using BULK. Very many, I think even most, DVB chipset offers both ISOC and BULK. BULK is still used commonly, only few drivers are using ISOC. Devin answered already why BULK is used generally for DVB streams. :) I read also USB bible book yesterday and it says it is better to use biggest BULK urb supported. I want to change it biggest possible one, but there is other side that limits it - memory needed for buffers. That's why I am thinking twice whether to increase it 8k or 16k or even more. I currently think 16k will be good compromise for most configurations / devices. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Wed, Sep 09, 2009 at 05:59:07PM -0400, Devin Heitmueller wrote: On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyerclintonmeye...@gmail.com wrote: Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV. Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE 3.5.10, kernel 2.6.27-1-mepis-smp All three machines now have wireless blocked, either do not connect or all packets dropped/blocked if a connection is made. Used the resources from LinuxTV (dot) org to get it working, they are referenced and posted as follows: linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware *** ** Quote: In order to use the LinuxTV driver, you need to download and install the firmware for the xc5000. Quote: wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh sh extract (dot) sh cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware :Unquote Note: Though the usual directory location in which the firmware file is placed is /lib/firmware, this may differ in the case of some distros; consult your distro's documentation for the appropriate location. The firmware will be added lazily (on-demand) when you first use the driver. Drivers The xc5000 driver needed for this WinTV-HVR-950Q is already part of the latest Linux kernel (part of v4l-dvb drivers). Analog support was merged into the mainline v4l-dvb tree on March 18, 2009. :Unquote *** ** *** ** So on Saturday I got this up and running... and Sunday morning recorded one show successfully that had set up on a timer. Then set up three consecutive shows for the afternoon. They were all part of a series on the same channel. Here are the results: * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. * Show C, supposed to be 2.0 hours long, result was 2.7gb file size, about the first hour is missing. At about this point, I lost wireless internet connectivity on TV recording laptop. Machine sees the access point, but won't connect. Went to my main desktop where i had first worked with this Hauppauge WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost internet, even though it was right next to AP and got a very good signal. Thought it was maybe the AP, so switched it out for a working spare. Same results. Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD and an 8.06 Live USB stick and hit the road to go to a reliable high speed wifi spot. Same results... changins ISPs resulted in the same issues. Also same ting happened with the spare laptop, an IBM T43 Thinkpad I had also done the wget ... steventoth (dot) net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip firmware thing to. Was able to get one machine, while running a LIVE USB session, to connect, but zero packets received.. ALL were blocked. The connection information said ALL packets were dropped. None of the two other machines connected to wireless on a LiveCD or LiveUSB thing too Three machines. All different brands (HP, Dell, and IBM) with different wifi cards. All three see the access point ESSID, but none connect. This does not *feel* good. What got flashed? Can this be resolved? Came home. No difference. Grabbed a laptop that i had NOT done the firmware thing to and that is what I am using to write this. Hooked right up to the AP. Please help... that is too much hardware disabled for me to think calmly. I'd really like to make the USB tv tuner work... what a great way to PVR / DVR, but I need wireless. Can provide any details requested to drive this towards a fix! Thank you, Clinton -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Clinton, That is indeed curious. It's hard to imagine how there could be interference between the V4L subsystem and the wireless subsystem, short of hitting some sort of timing condition on crappy wireless drivers. Here are a few questions: 1. You specified you followed the instructions for the firmware, but are you running the current v4l-dvb code, or are you just using whatever came with your Debian kernel? If you're actually using the 1.1 Xceive firmware, I'm assuming you're still using the old code. 2. How reproducible is this? Does it occur even if the device is connected but you do not attempt any capturing with the device? Does it always drop out while capturing? 3. What type of wireless cards are you using? Are they implemented over PCI, or USB? If the wireless cards are USB based, perhaps there is some sort of USB
Re: LinuxTV firmware blocks all wireless connections / traffic
Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. OK, I will make test version in couple of hours. Does USB subsystem provide any way to monitor current raw USB data transfer rate? I don't if there is tool for raw data analysis, but for DVB devices you can use dvbtraffic tool. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. Does USB subsystem provide any way to monitor current raw USB data transfer rate? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/10/2009 04:47 PM, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. OK, I will make test version in couple of hours. Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 10:48 AM, Antti Palosaaricr...@iki.fi wrote: Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Antti -- http://palosaari.fi/ Hello Antti, 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 usually take a look at a USB trace of the device under Windows, and then use the same value. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
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. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaaricr...@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. 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
Devin Heitmueller wrote: On Thu, Sep 10, 2009 at 11:55 AM, Antti Palosaaricr...@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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: On 09/10/2009 04:47 PM, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. OK, I will make test version in couple of hours. Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Thanks, Antti! Tested your branch on affected system. Load definitely went down, from ~7000 wakeups to ~250 for each tuner according to powertop. Both tuners still working ok if not used simultaneously or if used the same time on different USB controllers. Bad news are that original problem still persists: putting both tuners on same USB controller and zapping simultaneously corrupts stream. Interesting observation: no matter in what sequence tuners are connected (i.e. become adapter0 or adapter1), af9015 stream always gets heavily distorted, visually mplayer picture becomes like 80% corrupted with random color blocks and pixels, sound becomes a mess. At the same time ce6230 gets slight corruption, a few discolored blocks at the time and sound hickups. Anyway, will try to do a few more tests: 1) Two usb flash drives on same controller calculating md5sum of big .iso file, to check if it is/isn't dvb-usb problem. 2) Will see if same issue persists on another PC with same motherboard (slightly different revision) to rule out hardware issues. If I manage to wire antenna there, that is... -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaaricr...@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. 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. 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 08:16:31PM +0300, Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 05:48:22PM +0300, Antti Palosaari wrote: On 09/10/2009 04:47 PM, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: On Thu, Sep 10, 2009 at 04:12:15PM +0300, Antti Palosaari wrote: Aleksandr V. Piskunov wrote: Here is a test case: Two DVB-T USB adapters, dvb_usb_af9015 and dvb_usb_af9015. Different tuners, Err, make it: dvb_usb_af9015 and dvb_usb_ce6230 Those both uses currently too small bulk urbs, only 512 bytes. I have asked suitable bulk urb size for ~20mbit/sec usb2.0 stream, but no-one have answered yet (search ml back week or two). I think will increase those to the 8k to reduce load. Nice, I'm ready to test if such change helps. OK, I will make test version in couple of hours. Here it is, USB2.0 URB is now about 16k both af9015 and ce6230 devices. Now powertop shows only about 220 wakeups on my computer for the both sticks. Please test and tell what powertop says: http://linuxtv.org/hg/~anttip/urb_size/ I wonder if we can decide what URB size DVB USB drivers should follow and even add new module param for overriding driver default. Thanks, Antti! Tested your branch on affected system. Load definitely went down, from ~7000 wakeups to ~250 for each tuner according to powertop. Both tuners still working ok if not used simultaneously or if used the same time on different USB controllers. Bad news are that original problem still persists: putting both tuners on same USB controller and zapping simultaneously corrupts stream. Interesting observation: no matter in what sequence tuners are connected (i.e. become adapter0 or adapter1), af9015 stream always gets heavily distorted, visually mplayer picture becomes like 80% corrupted with random color blocks and pixels, sound becomes a mess. At the same time ce6230 gets slight corruption, a few discolored blocks at the time and sound hickups. Anyway, will try to do a few more tests: 1) Two usb flash drives on same controller calculating md5sum of big .iso file, to check if it is/isn't dvb-usb problem. 2) Will see if same issue persists on another PC with same motherboard (slightly different revision) to rule out hardware issues. If I manage to wire antenna there, that is... Ok, two USB flash drives on same controller, no problem when bulk reading from both at the same time, no speed drops, no corruption. Now if I plug ce6230 tuner, zap to channel and then start reading from flash drive: * slightly corrupted TS stream * flash drive read getting starved on bandwidth, speed drops from 10 MB/s to ~7 MB/s If I plug af9015 tuner, zap and read from flash * heavy corruption of TS stream * flash drive read speed drops from 10 MB/s to 2(!) MB/s Now I don't really know the USB protocol under-the-hood details, all the different types of bandwidth, reservation and so on. But shouldn't one 480 Mbit/sec controller handle rather large number of digital tuners, each pushing 20-25 Mbit/sec max, even considering all the overhead? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On 09/10/2009 08:17 PM, Devin Heitmueller wrote: On Thu, Sep 10, 2009 at 12:48 PM, Antti Palosaaricr...@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/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Thu, Sep 10, 2009 at 4:29 PM, Antti Palosaaricr...@iki.fi wrote: 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. If you want to pick bridges that are important to you and take the time to optimize them better, by all means be my guest. This is the sort of thing that would have to be discussed with the individual maintainers of those bridges, so you can understand what logic was used in making the original decision (ensuring the original logic was not done to work around some bug, etc). I haven't seen yet device which forces to use just one size - though it is possible there is. Well, it depends on the chip. Selecting too small a value can result in packets getting dropped (this was a problem on em28xx until I fixed it a few months ago). And no datasheet even needed, you can see from debug log or error code if URB is not suitable. Well, this assumes the bridge fails gracefully, returning a failure. Take Patrick's example, where the device returns success but then proceed to not send back any URBs. 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. Frankly, I'm not really confident this provides much value. End-users should not really be playing around with these sorts of settings. If the values are wrong, a patch should be submitted and the maintainer should fix the driver. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV firmware blocks all wireless connections / traffic
On Wed, Sep 9, 2009 at 5:43 PM, Clinton Meyerclintonmeye...@gmail.com wrote: Purchased a Hauppauge WinTV-HVR-950Q USB Hybrid TV stick to capture ATSC OTA TV. Am running MEPIS 8.06 on all three machines, Debian 5 Lenny based, KDE 3.5.10, kernel 2.6.27-1-mepis-smp All three machines now have wireless blocked, either do not connect or all packets dropped/blocked if a connection is made. Used the resources from LinuxTV (dot) org to get it working, they are referenced and posted as follows: linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-950Q#Firmware *** ** Quote: In order to use the LinuxTV driver, you need to download and install the firmware for the xc5000. Quote: wget ... steventoth (dot) net/linux/xc50...25271_WHQL (dot) zip wget ... steventoth (dot) net/linux/xc5000/extract (dot) sh sh extract (dot) sh cp dvb-fe-xc5000-1.1 (dot) fw /lib/firmware :Unquote Note: Though the usual directory location in which the firmware file is placed is /lib/firmware, this may differ in the case of some distros; consult your distro's documentation for the appropriate location. The firmware will be added lazily (on-demand) when you first use the driver. Drivers The xc5000 driver needed for this WinTV-HVR-950Q is already part of the latest Linux kernel (part of v4l-dvb drivers). Analog support was merged into the mainline v4l-dvb tree on March 18, 2009. :Unquote *** ** *** ** So on Saturday I got this up and running... and Sunday morning recorded one show successfully that had set up on a timer. Then set up three consecutive shows for the afternoon. They were all part of a series on the same channel. Here are the results: * Show A, 2.5 hours long, 13.2gb file size, appears to be OK. * Show B, 2.0 hours long, 3.7gb file size, appears to be OK. * Show C, supposed to be 2.0 hours long, result was 2.7gb file size, about the first hour is missing. At about this point, I lost wireless internet connectivity on TV recording laptop. Machine sees the access point, but won't connect. Went to my main desktop where i had first worked with this Hauppauge WinTV-HVR-950Q USB Hybrid TV stick and that machine also lost internet, even though it was right next to AP and got a very good signal. Thought it was maybe the AP, so switched it out for a working spare. Same results. Packed up laptop and a spare laptop, along with a MEPIS 8.06 LiveCD and an 8.06 Live USB stick and hit the road to go to a reliable high speed wifi spot. Same results... changins ISPs resulted in the same issues. Also same ting happened with the spare laptop, an IBM T43 Thinkpad I had also done the wget ... steventoth (dot) net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL (dot) zip firmware thing to. Was able to get one machine, while running a LIVE USB session, to connect, but zero packets received.. ALL were blocked. The connection information said ALL packets were dropped. None of the two other machines connected to wireless on a LiveCD or LiveUSB thing too Three machines. All different brands (HP, Dell, and IBM) with different wifi cards. All three see the access point ESSID, but none connect. This does not *feel* good. What got flashed? Can this be resolved? Came home. No difference. Grabbed a laptop that i had NOT done the firmware thing to and that is what I am using to write this. Hooked right up to the AP. Please help... that is too much hardware disabled for me to think calmly. I'd really like to make the USB tv tuner work... what a great way to PVR / DVR, but I need wireless. Can provide any details requested to drive this towards a fix! Thank you, Clinton -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello Clinton, That is indeed curious. It's hard to imagine how there could be interference between the V4L subsystem and the wireless subsystem, short of hitting some sort of timing condition on crappy wireless drivers. Here are a few questions: 1. You specified you followed the instructions for the firmware, but are you running the current v4l-dvb code, or are you just using whatever came with your Debian kernel? If you're actually using the 1.1 Xceive firmware, I'm assuming you're still using the old code. 2. How reproducible is this? Does it occur even if the device is connected but you do not attempt any capturing with the device? Does it always drop out while capturing? 3. What type of wireless cards are you using? Are they implemented over PCI, or USB? If the wireless cards are USB based, perhaps there is some sort of USB bandwidth issue. 4. Are you actively watching the programs you are capturing? Or are you just saving the content to disk? What application are you using to capture the ATSC video?
