Hi,<br><br><div><span class="gmail_quote">2008/3/8, Marshall Eubanks <<a href="mailto:tme@multicasttech.com">tme@multicasttech.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The first question I ask in any 802.11 multicast debugging is :<br> <br> Are you sure that none of your Access points have multicast rate<br> limits set ?<br> <br> (These are in my experience pretty common and generally turned on by<br>
default.)</blockquote><div><br>I have checked my problem with 4 different devices: an AP Cisco Aironet 1200, a wifi router Zyxel Prestige 600, a Conceptronic wifi router and an AP Linksys DWL700, having in these similar loss rates. I have searched for multicast parameters (multicast packets per second rate limit included) to change but I have found nothing. Should this parameter be available? It seems strange to me that the Cisco one has only a multicast parameter but regarded only to bridges (anyway, it was changed just to see if it took any effect, but it didn't).<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The second is a two part question :<br> <br> Are you aware that all multicasts on your wired LAN will be flooded<br>
to your wireless LAN, even if there are no recipients for them<br> there ? Are<br> you sure that there are no high bandwidth multicasts on your wired<br> LAN ? (This, AFAICT, is the reason for the multicast rate limit<br>
defaults.)</blockquote><div><br>I have monitored the radio channel of the APs and the routers to see how loaded it was with and without the multicast service and they were less than 1 Mbps.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have gotten decent multicast throughput at 1 Mbps even for 802.11b,<br> so it sounds like you have a problem here.<br> <br><br> On Mar 8, 2008, at 5:01 AM, Javier Gálvez Guerrero wrote:<br> <br> > Hi,<br> ><br> > I think I understood the difference between upstream and<br>
> downstream. What I wanted to point out is that, although the<br> > maximum numerical available bandwidth of 802.11g is 54 Mbps, due to<br> > issues like listening the channel, overhead data and dividing the<br>
> channel in downstream and upstream (the AP is receiving for a while<br> > and transmitting for another while, isnt'it? Please, let me know if<br> > I am confused in this point.), the real data rate that clients can<br>
> receive is not 54 Mbps, so it is quite lower. But anyway, what I<br> > wondered is why should appear such an amount of packet losses if<br> > the available bandwidth was high enough to support the stream.<br> ><br>
<br> <br>There shouldn't be.<br> <br><br> <br> > It's true that wireless links are much less reliable than wired<br> > ones, but I thought that this loss rate being quite near the AP was<br> > quite high.<br>
<br> <br>If the loss rate is high even when you are near the AP, you may have<br> RFI issues (i.e., other WLANs, computer to computer networks, etc.).<br> These of course would be more or less the same for unicast and<br>
multicast.</blockquote><div><br>I have checked in three different environments and with different WiFi channels and always the same results: unicast working pretty well but multicast (the same video tested in unicast) losing many packets.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > The other thing that seemed strange to me was why MPEG-4<br> > transcoding but even increasing the needed multicast streaming<br>
> bitrate had less error rate.<br> <br> <br>I don't understand this sentence. Please provide some more detail here.</blockquote><div><br>Sorry, I got confused and this had no sense. If I transcode the streamed file to lower video and audio bitrates the loss rate is decreased as well (obviously).<br>
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Regards<br> <br>Marshall</blockquote><div><br>Please, let me know if exists any tool that can configure any wifi multicast performance parameter. <br>
<br>Thank you,<br>Javi<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> ><br> ><br> > Anyway, thanks for the links and the info; it is much appreciated.<br>
> Hope VLC can add reliable multicast streaming over wireless links<br> > in a near future.<br> ><br> > Regards,<br> > Javi<br> ><br> > 2008/3/8, Sebastien Chaumontet <<a href="mailto:sebastien@chaumontet.net">sebastien@chaumontet.net</a>>: Wireless<br>
> is not a wire: on wireless it is normal to get errors/loss.<br> ><br> > Have you really understood the difference between upstream and<br> > downstream behavior in multicast over wireless?<br> ><br> > <a href="http://www.sydneywireless.com/?p=736">http://www.sydneywireless.com/?p=736</a><br>
> ------------------<br> > The 802.11 (Wi-Fi) standards specify support for multicasting as part<br> > of asynchronous services. An 802.11 client station, such as a wireless<br> > laptop or PDA (not an access point), begins a multicast delivery by<br>
> sending multicast packets in 802.11 unicast data frames directed to<br> > only the access point. The access point responds with an 802.11<br> > acknowledgement frame sent to the source station if no errors are<br>
> found in the data frame.<br> ><br> > If the client sending the frame doesn t receive an acknowledgement,<br> > then the client will retransmit the frame. With multicasting, the leg<br> > of the data path from the wireless client to the access point includes<br>
> transmission error recovery. The 802.11 protocols ensure reliability<br> > between stations in both infrastructure and ad hoc configurations when<br> > using unicast data frame transmissions.<br> ><br> > After receiving the unicast data frame from the client, the access<br>
> point transmits the data (that the originating client wants to<br> > multicast) as a multicast frame, which contains a group address as the<br> > destination for the intended recipients. Each of the destination<br>
> stations can receive the frame; however, they do not respond with<br> > acknowledgements. As a result, multicasting doesn t ensure a complete,<br> > reliable flow of data.<br> ><br> > The lack of acknowledgments with multicasting means that some of the<br>
> data your application is sending may not make it to all of the<br> > destinations, and there s no indication of a successful reception.<br> > This may be okay, though, for some applications, especially ones where<br>
> it s okay to have gaps in data. For instance, the continual streaming<br> > of telemetry from a control valve monitor can likely miss status<br> > updates from time-to-time.<br> > ------------------<br> ><br>
> Some solutions are already in TODO list for VLC :<br> > <a href="https://trac.videolan.org/vlc/ticket/820">https://trac.videolan.org/vlc/ticket/820</a><br> ><br> > ---<br> > Seb<br> ><br> ><br> > On 3/8/08, Javier Gálvez Guerrero <<a href="mailto:dulceangustia@gmail.com">dulceangustia@gmail.com</a>> wrote:<br>
> > Hi again,<br> > ><br> > > I know some multicast wifi behaviour issues that make multicast<br> > streaming<br> > > less reliable than unicast but what I can not understand is why,<br> > if I have<br>
> > made sure that every network device is working at 54 Mbps in a<br> > mandatory<br> > > way, with no power save mode but even with the DTIM wifi<br> > parameter set at<br> > > the minimum (1) and loading the wifi channel with less than 2<br>
> Mbps of data<br> > > (monitored with Wireshark), I have heavy packet losses (1/10<br> > packets are<br> > > lost in the wifi channel). I know how huge is the wifi overhead,<br> > but even<br> > > having an effective rate of 36 or 24 Mbps and having the half for<br>
> upstream<br> > > and the other half for downstream, 12 Mbps (let's say 10 Mbps)<br> > should be<br> > > more than enough to cope with ONE multicast streaming video (less<br> > than 400<br> > > kbps) with not such errors.<br>
> ><br> > > I have checked it with the client device at less of one meter<br> > from the AP<br> > > and there are many lost packets, tested in different<br> > environments, networks<br> > > and with different client devices. If I transcode the streamed<br>
> files to mp4<br> > > 256 kbps video and 128 kbps audio it works pretty well but the<br> > whole bitrate<br> > > ( 256 + 128 ) is bigger than the original one (333 kbps), what<br> > still gets me<br>
> > more confused. It has something to do that the original video can<br> > be encoded<br> > > with MPEG-1 or 2? Anyway, how can be possible that I have this<br> > amount of<br> > > lost packets if I have the radio channel almost "dedicated" with<br>
> such a<br> > > higher available rate than needed?<br> > ><br> > ><br> > > Thank you all,<br> > > Javi<br> > ><br> > > 2008/3/3, Sebastien Chaumontet <<a href="mailto:sebastien@chaumontet.net">sebastien@chaumontet.net</a>>:<br>
> > > Hi,<br> > > ><br> > > > Problem with multicast (as broadcast) over wireless is that it<br> > is not<br> > > reliable:<br> > > > In the unicast world, wireless is retransmitting lost packets.<br>
> > > With broadcast or multicast on wireless (downstream way: from<br> > AP to<br> > > > clients) if packets are lost they are not retransmitted.<br> > > ><br> > > > An other behavior is that multicast is used as the rate of the<br>
> lowest<br> > > > client associated with the AP. ie: if all your clients on the<br> > AP are<br> > > > using 11Mb/s except one at 1Mb/s, multicast and broadcast will<br> > be sent<br> > > > at 1Mb/s.<br>
> > ><br> > > > Regards<br> > > > Seb<br> > > ><br> > > ><br> > > > On Mon, Mar 3, 2008 at 2:53 PM, Javier Gálvez Guerrero<br> > > > <<a href="mailto:dulceangustia@gmail.com">dulceangustia@gmail.com</a>> wrote:<br>
> > > > Hi,<br> > > > ><br> > > > > I am trying to stream multicast videos through a hybrid<br> > wireless-wired<br> > > > > network and I am having some problems at wireless clients. I<br>
> have<br> > > checked<br> > > > > with differents devices and even with different networks<br> > (laboratory and<br> > > > > home), but the results are the same: "ts warning:<br>
> discontinuity received<br> > > 0xX<br> > > > > instead of 0xX (pid = 68 or 69)" messages, so having some<br> > video and<br> > > audio<br> > > > > interruptions and poor frame decoding results.<br>
> > > ><br> > > > > I stream from a VLC server (through VLM, VLC 0.8.6d), Ubuntu<br> > Linux 32<br> > > bits<br> > > > > based, running in a laptop. It serves RTSP VOD videos and UDP<br>
> multicast,<br> > > > > both configured with VLM telnet interface. It streams via<br> > 802.11g at 54<br> > > Mbps<br> > > > > to a Cisco Aironet 1200 series access point, connected to a<br>
> switch with<br> > > many<br> > > > > other computers. Then I have two clients: a desktop and a<br> > laptop. The<br> > > > > desktop is wired and it receives both VOD and the multicast<br>
> streams<br> > > > > perfectly, but the laptop, connected to the network with 802.11g<br> > > receives<br> > > > > VOD with no problems but the multicast stream with many<br> > discontinuity<br>
> > > > errors. If I connect the laptop to the wired network the<br> > multicast<br> > > streams<br> > > > > are received with no problems.<br> > > > ><br> > > > > I configure the scheduled multicast streaming:<br>
> > > ><br> > > > > > new test broadcast enabled<br> > > > > > setup test input<br> > > /media/sda2/diptv/server/contents/test.mpg<br> > > > > > setup test output<br>
> > #standard{mux=ts,access=udp,dst=<a href="http://239.255.1.5:60101">239.255.1.5:60101</a>}<br> > > > > > new test_tv schedule enabled<br> > > > > > setup test_tv date 2008/02/28-14:50:00<br>
> > > > > setup test_tv append control test play<br> > > > ><br> > > > > I have tried with different videos, different wireless<br> > receivers,<br> > > different<br> > > > > 802.11g channels and transmission rates (and many other<br>
> access point<br> > > > > features), streaming from a wired and wireless server, with a<br> > WIFI<br> > > > > Conceptronic router or a D-Link DWL700 access point instead<br> > the Cisco<br>
> > > > Aironet 1200 and receiving in a Linux or WinXP client with<br> > the same<br> > > results,<br> > > > > the raw of discontinuity errors at receiver. I have also tried<br> > > increasing<br>
> > > > the buffer size of VLC for UDP muxer with no effect.<br> > > > ><br> > > > > I have launched Wireshark protocol analyzer to track the udp<br> > packets on<br> > > the<br>
> > > > wired desktop and on the wireless laptop and the difference<br> > are some<br> > > random<br> > > > > missing packets on the wireless laptop network interface,<br> > obvious<br>
> > losses.<br> > > > ><br> > > > > So what I would like to know is if somebody has faced this<br> > problem with<br> > > > > multicast streaming in a wireless environment and, if it has<br>
> been<br> > > finally<br> > > > > solved, how to do it. If the solution is a different access<br> > point I<br> > > would<br> > > > > like to know which ones have worked properly with this issue.<br>
> > > ><br> > > > ><br> > > > > Thanks a lot.<br> > > ><br> > > > > _______________________________________________<br> > > > > streaming mailing list<br>
> > > > To unsubscribe or modify your subscription options:<br> > > > > <a href="http://mailman.videolan.org/listinfo/streaming">http://mailman.videolan.org/listinfo/streaming</a><br> > > > ><br>
> > > ><br> > > ><br> > ><br> > ><br> > > _______________________________________________<br> > > streaming mailing list<br> > > To unsubscribe or modify your subscription options:<br>
> > <a href="http://mailman.videolan.org/listinfo/streaming">http://mailman.videolan.org/listinfo/streaming</a><br> > ><br> > ><br> ><br> > _______________________________________________<br> > streaming mailing list<br>
> To unsubscribe or modify your subscription options:<br> > <a href="http://mailman.videolan.org/listinfo/streaming">http://mailman.videolan.org/listinfo/streaming</a><br> <br> </blockquote></div><br>