Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kent Clasen]

Jason Lavoie wrote on Sat, 28 July 2007 23:00

Kent Clasen wrote on Sat, 28 July 2007 14:27 Jason, yes it has a wall wart. As far as Multicast bundle limits, what I have been told is that all units (if they are all on the same network) receive the multicast bundles, regardless of if they have the been programmed to receive it, then they look at it and ignore it if not, but this is what eats up your bandwidth.  I believe all of the specs for Cobranet can be found at www.cobranet.info I guess it would be good to know if I have a network with 4 devices and a signal that has to get to two of the 4, am I better off with one multicast bundle, or two unicast bundles with only one channel each? I'm using more channels but fewer bundles. it seems like duplication, but if it keeps the data flow to only the 2 boxes that require it then it may be better right? I understand how bundles work, but I don't understand why it is important to bundle signals together other than keeping track.

See below from Yamaha:

Note: Unicast bundles are only transmitted to single devices which have been set to the same
bundle number as the transmitting device. Multicast bundles are transmitted to all devices on the
network regardless of their settings, but only bundles with the specified bundle number(s) are
processed. For this reason, multicast bundles make heavy use of network bandwidth and it is
recommended that the maximum number of multicast bundles be limited to 4 (32 channels).
Multi-unicast bundles are only transmitted to up to four devices simultaneously, saving network
bandwidth compared to multicast bundles.

[Jason Lavoie]

That still doesn't really answer my question.
are two single-channel multicast bundles any different (traffic wise) than one two-channel multicast bundle?

am I wrong in assuming that since 4 multicast bundles (@32 channels) is a good limit, then my 4 multicast bundles with only 9 channels should be 1/3 as much traffic. leaving me with lots of network headroom?

here is my network:
Box1: Sending 1 multicast bundle (4ch)
Box2: Sending 1 multicast bundle (1ch), 1 unicast bundle (3ch, and 2 unicast bundles (1ch each)
Box3: Sending 1 unicast bundle (2ch)
Box4: Sending 2 multicast bundles (2ch each), 1 unicast bundle (1ch), and 1 unicast bundle (2ch)

There are some places where I could combine a few things together into one bundle, but I had them separated to make it easier to keep track of what is what.


As for receiving:
Box1: receives 12 channels
Box2: receives 8 channels
Box3: receives 7 channels
Box4: receives 6 channels
(not counting the unwanted channels that arrive as a result of multi-cast bundles)

Jason

[Jason Lavoie]

... or does a bundle take up the same amount of network traffic even if it's not full?

Jason

[Jason Lavoie]

Through some searching I may have found my own answer:

from http://www.cirrus.com/en/pubs/appNote/CobraNet_BundleAssignm ents.pdf

"For most efficient utilization of network bandwidth, use of maximum size Bundles is suggested when possible."

so it does sound like X channels spread out over multiple bundles is worse than X channels grouped together into larger bundles whenever possible (it doesn't say by how much though)
I'm assuming this is due to overhead, which may be really high if they are expecting people to be using bundles for more than one or two channels most of the time.


"This entire document was based on the use of full Bundles. If Bundles containing less than the maximum number of audio channels are used, it is possible in some cases to exceed the limit of 8 Bundles on Fast Ethernet."

they are refering to each port on a switch being able to handle a max of 8 (full) bundles in each direction.


Sorry if I'm answering my own questions and supplying info that may not be new to you, but I figure someone else may be searching later and find it useful.

Jason

[Josh Millward]

While you are over at http://www.cobranet.info/, download CobraCad and draw up your configuration. Look at the bandwidth utilization and rework your configuration. Now look at the bandwidth utilization. It does provide some useful information.

Basically, looking at the few number of channels you are looking at moving from one point to another, you will be fine with pretty much whatever you do.

Keep this one detail in mind... the bandwidth utilization is dependent on the total number of audio channels on the link, regardless to the number of bundles they are broken into. So, by multicasting bundles around you are needlessly increasing the network load IF all those channels are not needed by all the receivers.

Multi-Unicast is an interesting thing, it is a great way to have a unicast bundle go to up to 4 devices without wasting network bandwidth by multicasting unnecessary crap everywhere.

I am not certain what configurations are available in the Symnet boxes. I'm just familiar with Cobranet since I work at MediaMatrix. For more fun and exciting reading, if you REALLY want to know all the details about how Cobranet works, download the "Cobranet Programmer's Reference Guide" from the Cobranet website. You will also need Cobranet Discovery (aka Disco - yes, it comes with a virtual mirror-ball!) to really look at how your devices are operating on the Cobranet network.

Oh yeah, one last thing, you aren't doing something silly like using one of the "low latency" modes, right???

[Jason Lavoie]

Josh Millward wrote on Fri, 03 August 2007 00:45

Oh yeah, one last thing, you aren't doing something silly like using one of the "low latency" modes, right???

WELL! that statement just begs more explanation.. (you knew that was coming didn't you?)

certain people at an undisclosed company told me that the higher latency modes were only really for compatibility with other equipment and that unless there's a reason not to, that I should set it to the lowest (1-1/3ms)

in my application the extra 4ms to up it to higher latency  likely won't negatively affect anything but I'm curious now..


Jason

[Josh Millward]

Jason Lavoie wrote on Fri, 03 August 2007 08:08

WELL! that statement just begs more explanation.. (you knew that was coming didn't you?)

I suppose I should have seen that coming...  

Jason Lavoie wrote on Fri, 03 August 2007 08:08

certain people at an undisclosed company told me that the higher latency modes were only really for compatibility with other equipment and that unless there's a reason not to, that I should set it to the lowest (1-1/3ms) in my application the extra 4ms to up it to higher latency  likely won't negatively affect anything but I'm curious now.. Jason

This has to do with how many channels of audio you can move. The standard latency is 5.33 milliseconds (mS). Using this latency you can move 32x32 channels on Cobranet. If you switch to the next lowest latency which is half that, you also halve the number of channels you can move to 16x16. You can again halve the latency, but it will again halve the channel count down to 8x8.

So, I would again suggest that you download CobraCAD and draw up your configuration to see if it will work or not and to see what the utilization of the links is.

I can understand why a low latency mode would be required for personal in the ear type monitoring situations, however, even the higher latency mode of 5.33 mS is about the equivalent of the loudspeaker being an additional 5.87 feet away.

The biggest problem is when you start running the signal across more than one link of Cobranet is that you incur the latency penalty each time you run your signal across a Cobranet link. So, if you were to send the signal down the Cobranet to FoH and process it, THEN send it down the Cobranet again to get it back to FoH, you have incurred 10.66 mS of latency, which could be too much for critical monitoring situations. However, if you were able to do your processing at the stage you could then use the Cobranet to feed lobby, backstage, and other zones around the facility. These zones would not be critical of the latency.

There are some Cobranet devices out there that will not do lower latencies and can only do the 5.33mS speed, but whoever mentioned that latency on Cobranet has to do with interoperability isn't really on the right track. It has more to do with channel count.

[Jason Lavoie]

Quote:

This has to do with how many channels of audio you can move. The standard latency is 5.33 milliseconds (mS). Using this latency you can move 32x32 channels on Cobranet. If you switch to the next lowest latency which is half that, you also halve the number of channels you can move to 16x16. You can again halve the latency, but it will again halve the channel count down to 8x8.

thanks for the info. it is definitely not in any of the documentation I have come across.

I'm confused though because we're still moving the same quantity of data, just encoding and decoding faster right?
maybe I'm missing something here..

I have tried my design in Cobracad and it does seem like a useful exercise, however I can't find any settings for latency, and a search through the help file generates zero hits on the word latency.

Jason

[Josh Millward]

I haven't tried setting to lower latency settings in CobraCAD either, but I figured it would be in there somewhere. If it isn't, have a look at the network utilization. If you are under 50% utilization, I would guess you would be okay with the middle latency and if it is under 25% utiliziation, you should probably be okay with the lowest latency.

Again, this is just a guess on my part since I haven't personally ever set up a low latency Cobranet network. I might have to try that this week, if I can eek out some time.

Good luck!

[Jason Lavoie]

Josh Millward wrote on Mon, 06 August 2007 01:55

I haven't tried setting to lower latency settings in CobraCAD either, but I figured it would be in there somewhere. If it isn't, have a look at the network utilization. If you are under 50% utilization, I would guess you would be okay with the middle latency and if it is under 25% utiliziation, you should probably be okay with the lowest latency.

that sounds reasonable. although I would hate to push data transfer to the max and risk audible problems just for the sake of a few miliseconds. I think giving up some latency to gain bandwidth headroom is a good trade.

Jason