Sound Reinforcement - Forums for Live Sound Professionals - Your Displayed Name Must Be Your Real Full Name To Post In The Live Sound Forums > Console Connectivity Solutions

Yamaha CL series

<< < (3/4) > >>

Josh Millward:

--- Quote from: Jim Wilkens on July 11, 2014, 05:36:35 PM ---I'm curious if there is a way to actually monitor that load.
--- End quote ---
Jim, I assume you intended to say Cisco SG300 network switches in your original post.

I believe you can monitor the traffic on the network by looking at the web interface for the network switch. I assume you know how to get into it since you are setting up VLANs and the like. While you are in there, look around for something that informs you how much traffic the ports are moving. As Mac indicated, if you are running a Gigabit network between your switches, you will have the capacity to run hundreds upon hundreds of channels with no issues. Your couple RIO racks and console will cause relatively inconsequential volumes of data in this situation considering the capacity that is available.

Riley Casey:
For the tiny universe of people planning to interface a Yamaha QL console to a CL console with the expectation that the analog i/o's on the QL can be made available to the CL using the Port to Port feature via Dante its not there yet.  Seems that advertised feature is a firmware update or two away from reality.    Also got a pretty firm recommendation to clear the Dante patch on start up then mounting via the dante mount screen when ever changing to a new configuration of RIOs, consoles, whatever.  Just an small FYI after a couple days of playing with it and calls to the mothership.

Josh Millward:

--- Quote from: Mac Kerr on September 29, 2013, 08:21:39 PM ---I think a cheap flashlight style fiber illuminator is a good thing to have as well. $40-$80 gets you a good one.

--- End quote ---
Hi Mac,

While this is very true, in a pinch your basic flashlight will work just fine too as long as you have access to the ends of the fibers.

I was shining my old 4Sevens Quark 1232 Tactical flashlight in the ends of some fiber the other day to verify that the strands were patched and showing up where they were expected. There was one strand where the light wasn't as bright as the others. Sure enough, when the dirt was found and removed at one of the connection points, all was good again.

Kieran Walsh:
A couple of quick points... i'll do it in reverse ;)

Flashlights are good for testing fiber - spent many a night in a damp field doing that... just one funky trick... most everyone has a smart phone nowadays... use the camera on your smart phone to check that there is a clean connection all the way through from the fibre tranceiver in the switch... the CCD cameras will show the "light" from an SFP module as a saturated white light... this is great for showing up if there is a speck of dust caught on the SFP lens, or something on the fiber itself... just an idea.

As for the question on capacity/bandwidth.

If you have physically separate primary and secondary networks I would not bother with VLANs at all... you are just running the risk of getting into more trouble.

My suggestion with this is now, use features as tools... I don't use a wrench in my car as a daily tool (actually... ever really) I certainly don't pop the hood everyday before I start her up to drive to an appointment (modern cars... like modern networks are a bit more reliable than the used to be to say the least!). Putting things in separate VLANs in a layer 3 paradigm is really just creating a false sense of security. All you are doing with VLANing up a network is placing a number in the dot1q header... like that is going to save your show, or magically create bandwidth, or have any real effect on anything (oh yeah... Voodoo LANs... they are magic of course... silly me).

DSCP QoS actually does something about traffic shaping (be warned using the blunt instrument of VLAN traffic shaping is really going to cause issues in a real-time network if you haven't got a lot of time to simulate all circumstances).

Having said all that - lets deal with some real numbers and make it more like the real world...

I am assuming that you are working on an audio centric network, and that you are not dealing with any services that are concerned with anything other than smooth running of the audio media and control systems (just providing a definition... not excluding other applications... but I am just trying to avoid going skiing in my Speedos.)

so my little torture test to see whether I 'like' a switch or not goes as follows...

I first take the thing out of the box and throw as much Dante Audio through a single port as I can - the easy way to do this is to generate as much Multicast audio as I can (as it will go absolutely everywhere if there is no management). I can generate over 1Gbps of multicast traffic using the various pieces of Dante equipment in my office (there are a lot of them... and a battery of 128x128 PCIe cards can make a big noise!).

Unsurprisingly if I smash out over 1Gbps of multicast audio over a gigabit port.. absolutely everything breaks spectacularly... to the extent that things have to be physically unplugged to regain enough control to turn off some channels!).

I use nothing more complicated than Dante Controller to measure how much multicast there is going on (to hit 1Gbps you are looking at somewhere like 640 or so channels.. which is why we say 512 as a rule of thumb).

I am measuring an entire system... not a component. My component is one of the controlled variables in the experiment, the observed effect is the performance of the system as a whole. It is pointless analysing the performance of a variable, when the concern is the performance of the system.

It would be easy at this stage to point out that not many people have enough equipment to make that much multicast bandwidth... in which case... if you don't have enough equipment to actually cause a problem... then you probably don't have a problem... so as a compromise... take all your gear... and see if you can cause a problem...

so my next stage is to remove multicast channels until I get a stable enough system running that I get decent audio through (typically I will have spotify playing some tunes through virtual soundcard to the hifi that is connected to a one of the breakout boxes I have... if the neighbours are in ... i'll even put headphones on.) The great things about using multicast for this test are:
1. I don't need to patch channels together... the devices when told to send multicast just hammer it out there like a TV transmitter
2. it causes a lot more stress to the switches in terms of actually switching data than unicast (which on the whole is fairly easy to handle).
3. The default mode of Dante is unicast... so testing a system under greater stress circumstances is more confidence inspiring.

once I am happy that I have the system "stable"... I tend to define that as at least 15 minutes operation without a crackle or a pop or anything I take a note of how much bandwidth I am using, and how many channels this is.

Next I add some channels to get the old popping and cracking back... again I note how much bandwidth I am using and how many channels that is.

Now I go into the switch and set up QoS.
Theoretically... if I have set it up "right" I should get my 15 minutes of perfect performance back... this would indicate that QoS is actually doing "something"

If I don't get my required 15 minutes of good performance back... I reduce the channel count until I do.

If the channel count I achieve with this QoS setting is in fact lower than without... then I have to ask... Did I set up QoS "wrong"... after all I just used a tool and make things worse (and yes I have used a wrench on some poor unsuspecting mechanical system that was minding its own business in the past... and yes I did make it a whole lot worse... anyone who has never made a system deteriorate by using a "tool" probably is either lying... or has never really tried it). If the QoS is "right" then its time for a sanity check... turn off QoS again, and go back to your carefully set earlier benchmark... was that right?

Once you have tweaked and played with a system and got some results... ask yourself this one question... am I EVER going to use that much resource?

I recently went through this process with a company that had some switches... these switches spectacularly failed the multicast torture test... but they did hold up to doing 256x256 channels of audio on a port. The requirement for these switches was for a 20 channel speaker distribution system... they cost a few 10s of $ each... so they failed at unrealistic counts, but exceeded the requirement by 10x... they were judged to be good... in the same way I wouldn't try to lift a 1.5ton PA hang with a 1ton motor... I might do it with a pair of 2-ton motors. Would I lift a single 400lb cabinet with a pair of 2-ton motors... no.. that would be silly... I could use a 1/2ton motor for the job. Is it better to use the pair of 2-tons... well... no... its irrelevant really... except for the obvious waste ;)

To the point of creating torture for networks... you could "try this at home" using a battery of Virtual Soundcards... anyone who is interested in doing this... get in touch and we'll work out how!

Jim Wilkens:
Wow. Kieran, Mac, Riley, thank you so much. This is gold! I am reminded what a tremendous resource this forum has been for me over the past 15 or so years.

Kieran, when I get back to the office I plan to undo the VLANs and leave the QoS set to the recommended settings. The VLANs did seem to me to add unnecessary complexity since many of the key ports were trunks anyway. I also started running into the issue of Dante Controller showing all the devices but not the patch points.

Riley, we just got a QL5 and while I'm not sure we would ever need the port to port feature it seems that you could accomplish it by using direct outs. For example if you had a QL for monitors and CL for FOH and no RIO boxes. I suppose the gain sharing feature would not work in that case.

Yesterday I set up everything in the shop in our standard configuration only with the QL5 in place of the CL. I loaded my old configuration file and Dante Controller automatically made all the patches to the QL that were intended for the CL.

Kieran, how exactly do you do that camera phone trick?

Jim W.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version