[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reception Report: Multimedia Seminar 10/18/2000
On Fri, 20 Oct 2000, Lawrence A. Rowe wrote:
> Hi -
>
> So let me ask some questions of Greg and Denis about the webcast.
>
> 1. Did you both have troubles with the single-stream RN webcast? Denis,
> I know you said you did. Greg, did you too? Can you both run a
> traceroute from the host you were viewing the webcast on to
> media2.bmrc.berkeley.edu? We don't see any problem here viewing the
> single stream webcast.
It would seem the problems seem to happen with the "live" broadcast...
that's what happened last wednesday... earlier in the morning I had tried
both the LB and single-stream archived session of the "Future of
TV" lecture and both worked fine.
Here's the traceroute to media2 [from denis.cts.ucla.edu]... I am
convinced we have the requisite bandwith in our path. Earlier in the week,
with Matthew we did sone NETperfs between your lab and here and at least
for short runs plenty of bandwidth was available.
denis% traceroute media2.bmrc.berkeley.edu
traceroute to media2.bmrc.berkeley.edu (169.229.12.59), 30 hops max, 38
byte packets
1 149.142.36.1 (149.142.36.1) 1.108 ms 0.952 ms 1.512 ms
2 host-958E2101 (149.142.33.1) 1.120 ms 1.007 ms 0.977 ms
3 cbn5-ci7200-1chs.cbn.ucla.edu (169.232.3.25) 1.248 ms 1.535 ms
1.111 ms
4 gsr-cbn5.calren2.ucla.edu (169.232.1.17) 1.447 ms 9.315 ms 1.614 ms
5 ISI--UCLA.POS.calren2.net (198.32.248.29) 1.779 ms 1.800 ms 2.039
ms
6 USC--ISI.POS.calren2.net (198.32.248.25) 2.288 ms 2.326 ms 2.331 ms
7 abilene--USC.ATM.calren2.net (198.32.248.86) 2.772 ms 3.321 ms
2.379 ms
8 scrm-losa.abilene.ucaid.edu (198.32.8.17) 18.295 ms 10.115 ms
10.229 ms
9 QSV--abilene.POS.calren2.net (198.32.249.61) 13.073 ms 13.995 ms
18.483 ms
10 BERK--SUNV.POS.calren2.net (198.32.249.13) 14.568 ms 17.659 ms
41.219 ms
11 pos1-0.inr-000-eva.Berkeley.EDU (128.32.0.89) 14.282 ms 14.296 ms
14.933 ms
12 pos5-0-0.inr-002-eva.Berkeley.EDU (128.32.0.74) 14.625 ms 14.857 ms
14.670 ms
13 vlan202.inr-004-eva.Berkeley.EDU (128.32.0.36) 16.369 ms 15.523 ms
15.338 ms
14 media2.BMRC.Berkeley.EDU (169.229.12.59) 15.202 ms 16.466 ms 14.887
ms
denis%
> 2. We've had regular, but sporadic, trouble with the dual-stream
> webcast. It fails maybe 50-60% of the time, but we haven't gotten it to
> fail regularly.
>
> Peter, we should send the bug report to RN with cc to Tim's contact
> about the dual stream problem. Given that the problem happens pretty
> regularly with remote viewers, send them the URL for one of the dual
> stream MIG Seminar replays. They should be able to replicate the
> problem.
>
> I have some suspicions about what might be happening. I think the dual
> stream problem is that the Real Player confuses the response messages
> from the two streams so it takes exaggerated action when packets are
> delayed/dropped. Sadly, it looks like the do not report statistics
> correctly in their stats panel. We've run the streams and watch the
> video delay and then catch up, but their panel reports no losses.
>
> I'm also concerned that we're seeing bursty behavior from particular
> routers/links (Gigabit Ethernet?) and possibly some policy dropping by a
> commercial ISP. Denis, I really need to know your route. The fact that
> the single stream didn't play for you is very troubling. I also need to
> know what settings you use for network connection and protocol. You
> should use UDP/unicast with connection on T1 or LAN.
Connection setting is "T!/LAN." As for the transport setting, it is set to
"autoconfigure"... using RealPlayer v7.0 under RedHat Linux 6.2.
Right after receiving your message, I launched RealPlayer with the
single-stream session of the "Future of TV" lecture... it's playing
without a hitch so far. You probably can see me in your server right now.
Last week, however, I wasn't able to secure any hi-bitrate (200-Kbit/s)
sessions for replays from the archive -- so something seems to have
cleared on your end of the network that this works now. But in regards,
the "live" session last wednesday that seems to involve more to the
problem...
-- Denis