On Sat, Apr 11, 2009 at 1:37 AM, Geza Kovacs <gkov...@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.langh...@gmail.com mar...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel