<html>
<head>
</head>
<body>
Jonathan,<br>
<br>
We currently have custom-built rack-mounted machines that we are about to
upgrade. We ran into the same problem - only being able to find rack-mountable
servers. Our solution is to buy regular workstations (in our case, Dell Precision
530's and 340's) and place them on rack-mountable shelves purchased through
racksolutions.com.<br>
<br>
Darin<br>
<br>
<br>
Jonathan C. Humfrey wrote:<br>
<blockquote type="cite" cite="mid:Pine.GSO.4.21.0208290859160.1817-100000@calvin">
<pre wrap=""><br>Jay,<br><br>Can you tell me what the exact setup of your display machine is? Are they<br>rackmount? I have had a real problem with our display machine which uses<br>a SuperMicro motherboard made for a server and we end up getting a lot of<br>loss in the rendering process... we're looking for a rackmount dual<br>processor machine that will render much more effectively. Any<br>suggestions?<br><br>Jonathan<br><br>On Thu, 29 Aug 2002, Jay Beavers wrote:<br><br></pre>
<blockquote type="cite">
<pre wrap="">We're using 1394 cameras in addition to analog PCI based capture cards.<br>1394 cameras have many advantages (integrated power, control, and data<br>cables; higher quality all-digital signal; lower CPU utilization) and<br>one of them is that realistically you can fit 3 cameras per PCI slot.<br>In other work at MSResearch that involve camera arrays, they use 5+ 1394<br>cameras running at 640x480 and software to create one very large, highly<br>detailed image that appears as one virtual large video source. You can<br>see this in the papers on the 'Ring Camera'. This isn't ready for<br>AG-like scenario trials yet, as it's still in early prototype stage.<br><br>With the continuing march upwards in PC capacity, I don't foresee<br>multi-node computers as being required by number or quality of video<br>streams. We're quite happy doing multiple capture and multiple render<br>streams on our dual P-IV workstations today, and we could easily go up<br>in capacity ove
r 50% by moving from our 1.7 GHz CPUs to 2.8 GHz CPUs<br>that are now available (and go from 400 MHz dual channel RD-RAM to 533<br>MHz dual channel RD-RAM at the same time). We take advantage of the CPU<br>assist provided by cards like the NVIDIA GeForce and the DirectX Video<br>Acceleration architecture that is part of DirectShow which allows the<br>graphics card to offload significant portions of the decoding and<br>rendering.<br><br>We are using multiple computers per node now for pure logistical<br>reasons. We're using one computer to handle all the A/V traffic, a<br>wireless Tablet PC to drive PowerPoint with ink, and a laptop as the<br>administrative/diagnostic console. Our hope is to make the<br>administrative console needed only for occasional onsite diagnostics<br>(like adjusting the microphone gain/gating settings for the room) as<br>operations continues to get simpler. Our admin console used to be on<br>the A/V node, but we found it is too disruptive to use to
have the<br>operator run over to the A/V node whenever any adjustments need to be<br>made ;-) We're looking at other solutions, like moving the A/V node to<br>an operations closet or using Mira devices (LCD monitors with Remote<br>Desktop logic built in) or providing a web-based admin interface<br>directly on the A/V node to keep the Admin functions integrated on the<br>A/V node.<br><br>We can make signals from multiple computers 'appear' to be from one<br>logical place by sending signals from the same CName, at least until we<br>start using SSM and then the IP address becomes important. I don't have<br>a clear concept of whether we would ever use the same CName among more<br>than one computer. In our scenario, education, we generally give a<br>'room' CName to the A/V workstation (E.G. <a class="moz-txt-link-abbreviated" href="mailto:MSR-113-1021@Microsoft.Com">MSR-113-1021@Microsoft.Com</a>)<br>and use a 'professor' CName (E.G. <a class="moz-txt-link-abbreviated" href="ma
ilto:DrBob@Washington.Edu">DrBob@Washington.Edu</a>) for the Tablet<br>PC and an 'operator' CName (E.G. <a class="moz-txt-link-abbreviated" href="mailto:JBeavers@Microsoft.Com">JBeavers@Microsoft.Com</a>) for the<br>operator's console. Strictly speaking, what's a "node" in that design<br>and what are just "personal" devices?<br><br> - jcb<br><br>-----Original Message-----<br>From: Osland, CD (Chris) [<a class="moz-txt-link-freetext" href="mailto:C.D.Osland@rl.ac.uk">mailto:C.D.Osland@rl.ac.uk</a>] <br>Sent: Thursday, August 29, 2002 7:21 AM<br>To: Jay Beavers; <a class="moz-txt-link-abbreviated" href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a><br>Subject: RE: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>multicast environment <br><br>It may not be relevant (I'm not in any sense a network type person)<br>but I foresee a requirement for more than one capture computer to<br>be regarded as part of a single node. There are already times when<br>I would like
to put out more than 4 video streams, and I also want<br>to start to use higher bandwidth links (e.g. 640x480, 800x600 and<br>1024x768 off computers). There aren't many motherboards with more<br>than 6 PCI slots, and with one gone on networking, a second video<br>capture computer that appeared seamlessly in the venue would be a<br>bonus.<br><br>I don't know whether this requires what you are discussing; if it<br>doesn't, please ignore!<br><br>Cheers<br><br>Chris Osland<br><br>____________________________________________________________________<br>Chris Osland Office tel: +44 (0) 1235 446565<br>Digital Media and Access Grid Medialab tel: +44 (0) 1235 446459<br>BIT Department Access Grid room tel: +44 (0) 1235 445666<br>e-mail: <a class="moz-txt-link-abbreviated" href="mailto:C.D.Osland@rl.ac.uk">C.D.Osland@rl.ac.uk</a> Fax: +44 (0) 1235 445597<br><br>CLRC Rutherford Appleton Laboratory (Bldg. R18)<br>Chilton, DIDCOT, Ox
on OX11 0QX, UK<br><br>[The contents of this email are confidential and <br>are for the use of the intended recipient only.<br>If you are not the intended recipient do not take <br>any action on it or show it to anyone else,<br>but return this email to the sender and delete your copy of it.]<br><br><br><br><br><br>-----Original Message-----<br>From: Jay Beavers [<a class="moz-txt-link-freetext" href="mailto:jbeavers@microsoft.com">mailto:jbeavers@microsoft.com</a>]<br>Sent: 29 August 2002 06:19<br>To: <a class="moz-txt-link-abbreviated" href="mailto:ag-tech@mcs.anl.gov">ag-tech@mcs.anl.gov</a><br>Subject: [AG-TECH] FW: [AVT] Multiple IP address scenarios in a<br>multicast environment <br><br><br>FYI, thought I would forward over this discussion I started on the IETF<br>AVT mailing list (AVT owns RTP, the transport of AG).<br><br>We're looking into enabling browsing of active participants in Venues<br>that you're interested in but not joined to, as well as thinking about<br>ti
ering multicast traffic between 'important' and 'less important'<br>streams.<br><br>If anyone on AG-Tech has thoughts in this area, I'd love to hear them.<br><br> - jcb<br><br>-----Original Message-----<br>From: Colin Perkins [<a class="moz-txt-link-freetext" href="mailto:csp@isi.edu">mailto:csp@isi.edu</a>] <br>Sent: Tuesday, August 27, 2002 12:10 PM<br>To: Jay Beavers<br>Cc: <a class="moz-txt-link-abbreviated" href="mailto:avt@ietf.org">avt@ietf.org</a><br>Subject: Re: [AVT] Multiple IP address scenarios in a multicast<br>environment <br><br>Comments inline...<br><br>--> "Jay Beavers" writes:<br></pre>
<blockquote type="cite">
<pre wrap="">Scenario 1, Who's Talking?<br><br>An application is using RTP over multicast UDP on an IPv4, IGMPv2<br>network. When a client subscribes to a multicast group address using<br>IGMPv2, the client receives all traffic on that multicast group<br></pre>
</blockquote>
<pre wrap="">address,<br></pre>
<blockquote type="cite">
<pre wrap="">including all RTP and RTCP traffic, regardless of sender or port.<br><br>The client application can join any one of 30 available multicast group<br>addresses. The list of possible multicast group addresses and their<br>associated details is obtained via a unicast query once at the start of<br>the client application. The client wants to get some information about<br>who is in each multicast group, preferably by receiving the RTCP SDES<br>traffic from each multicast group on port 5005.<br><br>For discussion sake, there are five clients in each multicast group,<br>each client sending 1 Mb/s of RTP traffic. Each client is assumed to<br>have at least 10 Mb/s of quality connectivity to an unloaded network<br>backbone.<br><br>Problem 1:<br><br>If the client application sends a multicast group address join request<br>for all 30 multicast group addresses, they will receive the RTCP SDES<br>traffic, but also the RTP traffic from each multicast group. This<br><
/pre>
</blockquote>
<pre wrap="">works<br></pre>
<blockquote type="cite">
<pre wrap="">out to 30 * 5 * 1 Mb/s = 150 Mb/s of aggregate traffic, vastly<br></pre>
</blockquote>
<pre wrap="">exceeding<br></pre>
<blockquote type="cite">
<pre wrap="">the 10 Mb/s client network capacity.<br><br>Potential Solution 1:<br><br>Are there any thoughts about how to approach this? I hesitate to load<br>group membership state on a server due to scalability, reliability, and<br>stale data concerns.<br></pre>
</blockquote>
<pre wrap="">Valid concerns. If you did choose this approach, a well connected group<br>member could listen to the RTCP and allow SNMP queries (the RTP MIB can<br>provide SDES information).<br><br></pre>
<blockquote type="cite">
<pre wrap="">Source Specific Multicast wouldn't solve this, as I would need to<br>subscribe to all sources to receive their RTCP traffic which would also<br>bring down their RTP traffic unless RTP and RTCP were separated onto<br>separate IP addresses. I've also wondered if RTCP SDES traffic could<br></pre>
</blockquote>
<pre wrap="">be<br></pre>
<blockquote type="cite">
<pre wrap="">duplicated to one shared multicast group address, the problem being<br>knowing which SSRCs are associated with which multicast group addresses<br>(associated by a RTCP APP packet perhaps?)<br></pre>
</blockquote>
<pre wrap="">Or use two multicast groups per session, one for the data and one for<br>the<br>RTCP? <br><br></pre>
<blockquote type="cite">
<pre wrap="">---<br><br>Scenario 2, We're All Equal, But Some Are More Equal Than Others:<br><br>The same application is running, but the number of participants has<br>increased, perhaps because the conversations are using a lecture or<br>panel discussion model. Now we have a few (5?) important clients and<br></pre>
</blockquote>
<pre wrap="">50<br></pre>
<blockquote type="cite">
<pre wrap="">less important clients.<br><br>It's decided that the important clients should continue sending the 1<br>Mb/s of data. Less important clients can send an occasional (every 30<br>seconds) high resolution snapshot as well as 100 kb/s of A/V streams.<br><br>If all data is sent over one multicast group address, the aggregate<br>network bandwidth is 5 * 1 Mb/s + 50 * 100 kb/s = 10 Mb/s, severely<br>stretching the network capacity of the clients. The clients would<br>prefer to receive the streams for important clients and the snapshots<br>for less important clients. Optionally, the 100 kb/s streams from the<br>less important clients would be enabled on a stream by stream basis.<br><br>Problem 2:<br><br>Source Specific Multicast has some relevance here, as it could be used<br>to subscribe to a subset of the less important client A/V streams.<br>However, the client would still want to receive RTCP and snapshot<br>information from all clients.<br><b
r>Potential Solution 2:<br><br>Traffic could be broken into two multicast group addresses again, with<br>unfiltered traffic (RTCP, RTP snapshots) being on one address and<br></pre>
</blockquote>
<pre wrap="">source<br></pre>
<blockquote type="cite">
<pre wrap="">filtered traffic (RTP A/V streams) being on a separate address. This<br>would also allow IGMPv2 networks to work, as clients on that network<br>could subscribe to only the traffic on the unfiltered multicast group<br>address and lose only the capacity to see A/V streams from the less<br>important clients.<br></pre>
</blockquote>
<pre wrap="">You could also run two RTP sessions, one for the "important" clients,<br>and<br>one for the rest, each with their own RTCP. The CNAME fields would let<br>you<br>relate participants between the sessions.<br><br></pre>
<blockquote type="cite">
<pre wrap="">---<br><br>In both these cases, the solution involves sending RTCP on a separate<br></pre>
</blockquote>
<pre wrap="">IP<br></pre>
<blockquote type="cite">
<pre wrap="">address from its associated RTP streams, which certainly isn't<br></pre>
</blockquote>
<pre wrap="">mentioned<br></pre>
<blockquote type="cite">
<pre wrap="">in RFC 1889 anywhere. Any other thoughts on how to approach these<br>scenarios?<br></pre>
</blockquote>
<pre wrap="">See above. I don't have strong objections to sending RTCP on a separate<br>multicast group to the associated RTP, in the first example.<br><br>Colin<br><br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
</body>
</html>