[Sugar-devel] GSoC Proposal: Multimedia Broadcasting

[Geza Kovacs]

On Fri, Apr 10, 2009 at 2:34 PM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Fri, Apr 10, 2009 at 6:47 PM, Geza Kovacs <gkovacs at mit.edu> wrote:
>> Assuming I'm using Farsight2 to broadcast MJPEG video over multicast UDP,
>
> As I've posted earlier, for multicast frames you'll see the AP
> switching to the slowest transmission speed to increase the chances
> that all the nodes will get the frame reliably, which hogs airtime.
>

According to http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=4292735
then the slowest transmission speed, Mode1 (6 Mbps) is only beneficial
for multicasting over very large distances; in the case of the AWGN
channel as shown in figures 1 and 2 (the Rayleigh fading channel
measurements are irrelevant since the laptops and WAP are presumably
within the line of sight of the broadcaster), then Mode1 is necessary
only at above 120m, which is much larger than the typical classroom.
At 40 meters, a reasonable radius for a classroom, Mode6 (36 Mbit/s)
could be used to achieve 25 Mbit/s throughput. Therefore the access
point need not automatically switch to Mode1 for multicast, assuming
it's possible to override this default behavior.

> And airtime is what really matters in wireless networking.
>
> So, if one session of your proposed application is the *only* thing
> running on the whole network, you can do some rough math. You'll need
> to
>
>  - Send the stream to the AP. If the 'broadcasting' node is close to
> the AP, and sees no interference, it may be able to transmit
> relatively fast (let's assume 36Mbps).
>
>  - Broadcast the framesfrom the AP at 1Mbps.
>
> What's the bits-per-second of your stream? What % of the airtime do
> you thing it will consume?
>

As for the bandwidth required for the video stream, for a 1-minute 15
FPS VGA-resolution MJPEG video stream (presumably this will be roughly
the compression level and bitrate that can be expected to be encoded
live from XOs, since the user might have other applications running)
the filesize turned out to be roughly 12 MB, therefore this video
stream would be 1.6 Mbit/s. Presumably since the main usage of this
would be for mostly static content with little motion, such as a
computer desktop or lecture slides, rather than full-motion video,
then perhaps the framerate could be reduced slightly further if
necessary.

As you mentioned a few mails ago, the broadcaster's proximity and
network link to the access point could also affect the performance of
the network. Since the main bottleneck is at the multicasting stage,
then since the XS would be optimally situated in the classroom and
would likely have a high-quality, perhaps wired, connection to the
access point, then perhaps rather than multicasting directly from the
XO then the XS could be running a multicast-capable streaming server
such as Helix, and it would simply multicast to the rest of the class
the incoming unicast signal that was sent to it from the recording XO
(this would of course require additional bandwidth due to having both
unicast and multicast stages but the multicast-distance optimization
should be able to compensate for this).

In terms of airtime consumption, this of course depends on the
airtime-fairness mechanisms used by the wireless network. However,
given that students' online activities in the classroom occurring
while the teacher is broadcasting a video stream will likely be
unicast, TCP-based standard HTTP traffic for web browsing and the
like, rather than live streams like say VoIP over UDP, then presumably
the multicasting could safely occupy up to a third of the airtime
without degrading the online experience of others. I of course can't
determine the actual airtime usage without implementing this, but I
would assume, based on the relatively low per-stream bandwidth usage,
that it shouldn't occupy any more than a third of the airtime.
Presumably, since this is primarily targeted towards teachers' usage
for presenting to the classroom, then there should only be one video
stream being multicast on a single same network at once.

> This of course assumes 802.11abg. With 802.11s, sending a stream over
> broadcast will mess up the network completely because of the funny
> rebroadcasting rules in the 's' standard.
>

I unfortunately don't know much about 802.11s, but I would assume that
since many (or most) deployments have a standard 802.11g network
on-site and accessible within the desired broadcasting range (the
classroom) then using the mesh network for multicasting wouldn't be
crucial for this to be used in most deployments.

> All OLPC deployments are a very busy wifi environment. If you build
> tools that assume that they are the only thing in the air, or that it
> can take a significant portion of the RF airtime... would be just like
> assuming that your program is the only thing in the hard disk.
>
> cheers,
>
>
>
> m
> --
>  martin.langhoff at gmail.com
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff
>