Network Traffic and Multicast
Miguel Álvarez
miguel at laptop.org
Tue Jun 26 10:27:48 EDT 2007
Your questions are quite broad, so I fear my answers may be proportionately
vague... if you want more details, please specify:
On 6/26/07, Alfonso de la Guarda <alfonsodg at gmail.com> wrote:
>
> In reference to the message from Alexander, i will post the original
> request
>
> Hi.....
>
> 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,
>
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.
bandwidth usage for multicast,
>
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.
dead times over a stream,
>
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
coverage (ideal range)
>
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
of the mesh... the goal is optimize the traffic consume and low latency
> issues.
>
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
Thanks,
>
>
Cheers,
Miguel
--
>
> --------------------------------
> Alfonso de la Guarda
> ICTEC SAC
> www.cosperu.com
> www.delaguarda.info
> Telef. 97550914
> 4726906
>
> --
>
> --------------------------------
> Alfonso de la Guarda
> ICTEC SAC
> www.cosperu.com
> www.delaguarda.info
> Telef. 97550914
> 4726906
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
--
violence is the last refuge of the incompetent
--isaac asimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070626/e89c7da9/attachment.html>
More information about the Devel
mailing list