It seems like this conversation is somewhat at cross-purposes. Martin discusses the general case of multicast from an arbitrary client through an access point serving many clients with a mixture of multicast and unicast traffic. Well known performance problems result. However, Geza proposes a special case (perhaps). In a classroom, it would be nice to be able to have a "projector" to send a stream of video to the stations within that classroom. Now, not every school could have extra hardware for this purpose, but I think many could, just as our schools of yore had that funky projector that got rolled into the classroom on the morning when our teacher wanted us to see (or sleep through :-) a movie about something or other. What might be interesting is to consider the possibiliity of connecting the projector client via a USB ethernet connector to a separate "multicast" access point, that the receiving clients associated with for the time of the "movie". This allows the originator of the stream to use a wired connection to the AP, the AP to be chosen and configured to optimize multicasting, and the whole thing to be somewhat isolated from the unicast traffic happening elsewhere. Not sure if this is workable, but some reading of the papers about multicast performance issues on the Intertubes suggest it might be promising. <div class="gmail_quote">On Sat, Apr 11, 2009 at 3:07 PM, Geza Kovacs <<a href="mailto:gkovacs@mit.edu">gkovacs@mit.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Since you apparently have more experience with multicasting over wireless I'll assume it's not a realistic option in this context (though it might nevertheless be an interesting experiment to try if have spare time over the course of GSoC after finishing a unicast-based implementation). Returning to unicasting and simply limiting net bandwidth usage, as I understand the "slowest client sets the speed" issue with the access node switching to Mode1 for broadcast applies only to multicasting. If I have the XO send the video in a single UDP stream to the central XS server (which as I understand has a wired connection to the AP), then have those streams be individually relayed by the XS over the AP to each designated viewer in over unicast UDP, then as I understand the AP will be able to operate near its 56 Mbps net throughput limit, which, factoring in the fact that the effective throughput will be decreased due to noise and that my application of course can't hog all the bandwidth and airtime, means that I will have around 20 Mbps available for unicasting to all clients. Rather than limiting the number of viewers as I originally proposed, I believe that automatically limiting the framerate of the broadcast based on the number of viewers will be a better way to scale for larger numbers of viewers - that is, once the broadcaster gets to the "broadcast" stage and selects the intended viewers, then based on the available bandwidth and network congestion, then an ideal framerate is calculated out and the stream is encoded and broadcast to all of the viewers at that framerate. Given that the most interest has been expressed over the remote desktop broadcasting feature, and given that there's rather little motion overall on a desktop broadcast, the desktop activity should still be easily viewed at very low framerates. >From my personal experience, I don't really miss any features of my own typical desktop activity even at around 3-4 fps (except for gaming, but presumably this will be used primarily for relatively low-motion educational software). At 4 fps, the MJPEG video stream, with a 96 Kbps audio stream, comes out at around 0.5 Mbps. Using 20 Mbps, this stream could be broadcast to 40 users, which I assume is around the upper limit of the number of students in the classroom. Assuming fewer viewers, then higher framerates could be used. Would this be a reasonable approach to limiting airtime usage with unicast streams? On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff <div class="im"><<a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a>> wrote: </div><div><div></div><div class="h5">> On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs <<a href="mailto:gkovacs@mit.edu">gkovacs@mit.edu</a>> wrote: >> According to <a href="http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735" target="_blank">http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735</a> >> then the slowest transmission speed, Mode1 (6 Mbps) is only beneficial >> for multicasting over very large distances; in the case of the AWGN > > I am sure they did their tests in quiet RF environments. In crowded > environments nodes can tell the AP that they're having trouble hearing > the frames, please transmit slower. > > You've calculated 1.6Mbps but that's only the stream. You need to get > each to the AP, and _then_ it'll be broadcast. The frame to the AP may > be transmittedfast if the XO is close to the AP. The datarate for the > broadcast frame from the AP to all the nodes is set by the AP based on > the nodes it has registered... > >> In terms of airtime consumption, this of course depends on the >> airtime-fairness mechanisms used by the wireless network. However, > > Which just don't exist (not in the QoS sense that you seem to be > picturing at least), and deal rather badly with dense networks. There > is a backoff mechanism that avoids collisions (rather than detect > them) ... in very dense environment this means that the available > bandwidth is significantly reduced. > > The tools that you want to reuse work well in a switched network with > ample capacity. The workload of video streaming -- however "light" you > might thing 1.6Mbps is -- in a saturated shared medium with "slowest > client sets the speed" broadcast and conservative backoff strategies > is AFAIK an unsolved problem. > > There's surely a complex research project there -- can it be made to > work? What strategies can work on that complex problem? But if you > start by assuming you can reuse existing high level tools, it'll be a > disaster. It might work in a test environment. But it will never ever > work in a real life school. > > cheers, > > > > m > -- > <a href="mailto:martin.langhoff@gmail.com">martin.langhoff@gmail.com</a> > <a href="mailto:martin@laptop.org">martin@laptop.org</a> -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - <a href="http://wiki.laptop.org/go/User:Martinlanghoff" target="_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a> > _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div></div></blockquote></div> -- "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair