No subject
Sat Mar 14 20:08:29 EDT 2009
own typical desktop activity even at around 3-4 fps (except for<br>
gaming, but presumably this will be used primarily for relatively<br>
low-motion educational software). At 4 fps, the MJPEG video stream,<br>
with a 96 Kbps audio stream, comes out at around 0.5 Mbps. Using 20<br>
Mbps, this stream could be broadcast to 40 users, which I assume is<br>
around the upper limit of the number of students in the classroom.<br>
Assuming fewer viewers, then higher framerates could be used. Would<br>
this be a reasonable approach to limiting airtime usage with unicast<br>
streams?<br>
<br>
On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff<br>
<div class=3D"im"><<a href=3D"mailto:martin.langhoff at gmail.com">martin.l=
anghoff at gmail.com</a>> wrote:<br>
</div><div><div></div><div class=3D"h5">> On Sat, Apr 11, 2009 at 1:37 A=
M, Geza Kovacs <<a href=3D"mailto:gkovacs at mit.edu">gkovacs at mit.edu</a>&g=
t; wrote:<br>
>> According to <a href=3D"http://ieeexplore.ieee.org/search/wrapper.=
jsp?arnumber=3D4292735" target=3D"_blank">http://ieeexplore.ieee.org/search=
/wrapper.jsp?arnumber=3D4292735</a><br>
>> then the slowest transmission speed, Mode1 (6 Mbps) is only benefi=
cial<br>
>> for multicasting over very large distances; in the case of the AWG=
N<br>
><br>
> I am sure they did their tests in quiet RF environments. In crowded<br=
>
> environments nodes can tell the AP that they're having trouble hea=
ring<br>
> the frames, please transmit slower.<br>
><br>
> You've calculated 1.6Mbps but that's only the stream. You need=
to get<br>
> each to the AP, and _then_ it'll be broadcast. The frame to the AP=
may<br>
> be transmittedfast if the XO is close to the AP. The datarate for the<=
br>
> broadcast frame from the AP to all the nodes is set by the AP based on=
<br>
> the nodes it has registered...<br>
><br>
>> In terms of airtime consumption, this of course depends on the<br>
>> airtime-fairness mechanisms used by the wireless network. However,=
<br>
><br>
> Which just don't exist (not in the QoS sense that you seem to be<b=
r>
> picturing at least), and deal rather badly with dense networks. There<=
br>
> is a backoff mechanism that avoids collisions (rather than detect<br>
> them) ... in very dense environment this means that the available<br>
> bandwidth is significantly reduced.<br>
><br>
> The tools that you want to reuse work well in a switched network with<=
br>
> ample capacity. The workload of video streaming -- however "light=
" you<br>
> might thing 1.6Mbps is -- in a saturated shared medium with "slow=
est<br>
> client sets the speed" broadcast and conservative backoff strateg=
ies<br>
> is AFAIK an unsolved problem.<br>
><br>
> There's surely a complex research project there -- can it be made =
to<br>
> work? What strategies can work on that complex problem? But if you<br>
> start by assuming you can reuse existing high level tools, it'll b=
e a<br>
> disaster. It might work in a test environment. But it will never ever<=
br>
> work in a real life school.<br>
><br>
> cheers,<br>
><br>
><br>
><br>
> m<br>
> --<br>
> =A0<a href=3D"mailto:martin.langhoff at gmail.com">martin.langhoff at gmail.=
com</a><br>
> =A0<a href=3D"mailto:martin at laptop.org">martin at laptop.org</a> -- Schoo=
l Server Architect<br>
> =A0- ask interesting questions<br>
> =A0- don't get distracted with shiny stuff =A0- working code first=
<br>
> =A0- <a href=3D"http://wiki.laptop.org/go/User:Martinlanghoff" target=
=3D"_blank">http://wiki.laptop.org/go/User:Martinlanghoff</a><br>
><br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href=3D"mailto:Sugar-devel at lists.sugarlabs.org">Sugar-devel at lists.sugarl=
abs.org</a><br>
<a href=3D"http://lists.sugarlabs.org/listinfo/sugar-devel" target=3D"_blan=
k">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>"It is=
difficult to get a man to understand something, when his salary depends up=
on his not understanding it." -- Upton Sinclair<br>
--000e0cd20d86c5bb2b04674f8bc5--
More information about the Sugar-devel
mailing list