No subject

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
<martin.langhoff at gmail.com> wrote:
> On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs <gkovacs at mit.edu> wrote:
>> 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
>
> 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
> --
>  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
>