No subject

Sat Mar 14 20:08:29 EDT 2009

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

On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff
<martin.langhoff at> wrote:
> On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs <gkovacs at> wrote:
>> According to
>> 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
>  martin at -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  -

More information about the Sugar-devel mailing list