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>
On Sat, Apr 11, 2009 at 6:36 AM, Martin Langhoff<br>
<div class=3D"im">&lt;<a href=3D"mailto:martin.langhoff at">martin.l=
anghoff at</a>&gt; wrote:<br>
</div><div><div></div><div class=3D"h5">&gt; On Sat, Apr 11, 2009 at 1:37 A=
M, Geza Kovacs &lt;<a href=3D"mailto:gkovacs at">gkovacs at</a>&g=
t; wrote:<br>
&gt;&gt; According to <a href=3D"
jsp?arnumber=3D4292735" target=3D"_blank">
&gt;&gt; then the slowest transmission speed, Mode1 (6 Mbps) is only benefi=
&gt;&gt; for multicasting over very large distances; in the case of the AWG=
&gt; I am sure they did their tests in quiet RF environments. In crowded<br=
&gt; environments nodes can tell the AP that they&#39;re having trouble hea=
&gt; the frames, please transmit slower.<br>
&gt; You&#39;ve calculated 1.6Mbps but that&#39;s only the stream. You need=
 to get<br>
&gt; each to the AP, and _then_ it&#39;ll be broadcast. The frame to the AP=
&gt; be transmittedfast if the XO is close to the AP. The datarate for the<=
&gt; broadcast frame from the AP to all the nodes is set by the AP based on=
&gt; the nodes it has registered...<br>
&gt;&gt; In terms of airtime consumption, this of course depends on the<br>
&gt;&gt; airtime-fairness mechanisms used by the wireless network. However,=
&gt; Which just don&#39;t exist (not in the QoS sense that you seem to be<b=
&gt; picturing at least), and deal rather badly with dense networks. There<=
&gt; is a backoff mechanism that avoids collisions (rather than detect<br>
&gt; them) ... in very dense environment this means that the available<br>
&gt; bandwidth is significantly reduced.<br>
&gt; The tools that you want to reuse work well in a switched network with<=
&gt; ample capacity. The workload of video streaming -- however &quot;light=
&quot; you<br>
&gt; might thing 1.6Mbps is -- in a saturated shared medium with &quot;slow=
&gt; client sets the speed&quot; broadcast and conservative backoff strateg=
&gt; is AFAIK an unsolved problem.<br>
&gt; There&#39;s surely a complex research project there -- can it be made =
&gt; work? What strategies can work on that complex problem? But if you<br>
&gt; start by assuming you can reuse existing high level tools, it&#39;ll b=
e a<br>
&gt; disaster. It might work in a test environment. But it will never ever<=
&gt; work in a real life school.<br>
&gt; cheers,<br>
&gt; m<br>
&gt; --<br>
&gt; =A0<a href=3D"mailto:martin.langhoff at">martin.langhoff at gmail.=
&gt; =A0<a href=3D"mailto:martin at">martin at</a> -- Schoo=
l Server Architect<br>
&gt; =A0- ask interesting questions<br>
&gt; =A0- don&#39;t get distracted with shiny stuff =A0- working code first=
&gt; =A0- <a href=3D"" target=
Sugar-devel mailing list<br>
<a href=3D"mailto:Sugar-devel at">Sugar-devel at lists.sugarl=</a><br>
<a href=3D"" target=3D"_blan=
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>&quot;It is=
 difficult to get a man to understand something, when his salary depends up=
on his not understanding it.&quot; -- Upton Sinclair<br>


More information about the Sugar-devel mailing list