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 <[EMAIL PROTECTED]> 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@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
violence is the last refuge of the incompetent
--isaac asimov
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
