Your questions are quite broad, so I fear my answers may be proportionately vague... if you want more details, please specify:<br><br><div><span class="gmail_quote">On 6/26/07, <b class="gmail_sendername">Alfonso de la Guarda
</b> <<a href="mailto:alfonsodg@gmail.com">alfonsodg@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In reference to the message from Alexander
<span class="gmail_quote">, i will post the original request<br><br></span><div><span class="q" id="q_113683c249e5ee90_1">Hi.....<br><br>After EduKT and AmiGO, we are working on ITv which has been develop for any OS except XO because the usage of 2 very dynamic libraries: tubes and gst (for regular linux/windows we are using vlc/twisted).... the next week we will launch a video demo of ITv (Interactive Television), which allows 1 video channel and 3 real time data channel.... however i have to know about the performance of the network,
</span></div></blockquote><div><br> Are you planning on using 'raw multicast' or on accessing the multicast tubes in Salut? There is also a third option, that would be implementing/using some sort of reliable multicast (I worked on this a while ago). I will speak mainly about the 2 first possibilities, get back to me if you want to discuss the third one more in detail.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q" id="q_113683c249e5ee90_1"> bandwidth usage for multicast,
</span></div></blockquote><div><br> There are no particular limitations for multicast with respect to unicast traffic, but remember that (if you are using raw multicast) packages aren't acknowledged, so the more traffic you send, the more likely it is that some will get dropped.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q" id="q_113683c249e5ee90_1">dead times over a stream,</span>
</div></blockquote><div><br> you mean connection delays to a multicast channel? We haven't done testing of those, but while working with multicast it seemed to react similarly to 'wired multicast' scenarios: more flooding of packages at the beginning, and progressive path building
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q" id="q_113683c249e5ee90_1"> coverage (ideal range) </span>
</div></blockquote><div><br> Of the mesh? With one channel? various channels? I guess you have read about the range tests in Australia, but in a situation with heavy radio interference the workable range is heavily reduced. In most target cases you should count with some 100 mts per hop, and it seems that up to 3 hops video streaming has been conducted. 'Real world testing' of such heavy loads has started recently, though, so I have no data about the most current performance limit
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q" id="q_113683c249e5ee90_1">of the mesh... the goal is optimize the traffic consume and low latency issues.
</span></div></blockquote><div><br>I'd rather you try to limit the number of 'delay-sensitive' communication, and try to reduce the bandwith usage regardless of the total available data-rate. This way, you make sure that your application may work while other kinds of traffic are also being relayed
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q" id="q_113683c249e5ee90_1">Thanks,</span><br> </div></blockquote>
Cheers,<br>Miguel<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><span class="q" id="q_113683c249e5ee90_1">-- <br><br>--------------------------------
<br><span>Alfonso de la Guarda<br> ICTEC SAC<br> <a href="http://www.cosperu.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
www.cosperu.com</a><br><a href="http://www.delaguarda.info" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
www.delaguarda.info</a><br>Telef. 97550914<br> 4726906
</span><br clear="all"><br>-- <br><br>--------------------------------<br>Alfonso de la Guarda<br> ICTEC SAC<br> <a href="http://www.cosperu.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
www.cosperu.com</a><br><a href="http://www.delaguarda.info" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.delaguarda.info
</a><br>Telef. 97550914<br> 4726906
</span></div><br>_______________________________________________<br>Devel mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Devel@lists.laptop.org">Devel@lists.laptop.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.laptop.org/listinfo/devel" target="_blank">
http://lists.laptop.org/listinfo/devel</a><br><br></blockquote></div><br><br clear="all"><br>-- <br>violence is the last refuge of the incompetent<br>--isaac asimov