ProSoundWeb Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 [2]  All   Go Down

Author Topic: Yamaha CL series  (Read 13645 times)

Josh Millward

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 705
  • Meridian, MS
Re: Yamaha CL series
« Reply #10 on: July 11, 2014, 06:59:53 pm »

I'm curious if there is a way to actually monitor that load.
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.
Logged
Josh Millward
Danley Sound Labs

Riley Casey

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1046
Yamaha QL Port to Port feature is not ready for primetime
« Reply #11 on: July 11, 2014, 07:02:47 pm »

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

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 705
  • Meridian, MS
Re: Yamaha CL series
« Reply #12 on: July 11, 2014, 07:04:40 pm »

I think a cheap flashlight style fiber illuminator is a good thing to have as well. $40-$80 gets you a good one.
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.
Logged
Josh Millward
Danley Sound Labs

Kieran Walsh

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 88
    • Audinate
Re: Yamaha CL series
« Reply #13 on: July 12, 2014, 12:22:26 pm »

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!
Logged
Senior Technical Solutions Manager, Audinate EMEA.

Jim Wilkens

  • Newbie
  • *
  • Offline Offline
  • Posts: 35
  • Marblehead MA
Re: Yamaha CL series
« Reply #14 on: July 12, 2014, 03:32:45 pm »

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.

Logged

Mac Kerr

  • Old enough to know better
  • Administrator
  • Hero Member
  • *****
  • Offline Offline
  • Posts: 5689
  • Audio Plumber
Re: Yamaha CL series
« Reply #15 on: July 12, 2014, 04:05:21 pm »

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

No trick involved. The sensors in digital cameras as sensitive in the infra-red range, the lasers that illuminate fiber are in the IR range. Just look into the end of an illuminated fiber with a digital camera and you will see the light if it's there. You can try this out with the IR remote for your TV.

Mac
Logged

Jim Wilkens

  • Newbie
  • *
  • Offline Offline
  • Posts: 35
  • Marblehead MA
Re: Yamaha CL series
« Reply #16 on: July 12, 2014, 04:09:09 pm »

No trick involved. The sensors in digital cameras as sensitive in the infra-red range, the lasers that illuminate fiber are in the IR range. Just look into the end of an illuminated fiber with a digital camera and you will see the light if it's there. You can try this out with the IR remote for your TV.

Mac

Got it.I think the "trick" I needed is to just unplug the LC connector from the transceiver and point it at the camera.
Logged

Kieran Walsh

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 88
    • Audinate
Re: Yamaha CL series
« Reply #17 on: July 13, 2014, 11:23:20 am »

For the purposes of completeness for the switch torture bit...

The last tranche covered "how do I tell if I have QoS setup ad working... and more importantly... do I even need it?"

The other major consideration is Multicast.

In the interests of "doing it backwards" - good multicast management is more important than QoS... the reason for doing this backwards is that often times good multicast management will mask bad QoS setup, so in testing, always stress the system to the maximum extent of the least significant action first.

Now Multicast pruning is achieved on a Dante network using the IGMP standard. We have found that some switches just don't have the horsepower to deal with a lot of real-time multicast packets. The tricky part of this is that if you look on the datasheet it will say IGMP snooping... and a nice tick... It is of course a fair claim... the switch will have this feature if it says so...

Most lower cost switches manage IGMP functions in a microcontroller inside the switch... this is a fair approach, as its a lower cost processing platform, and in 99% of cases it is perfectly adequate.

So - once again... smash as much multicast as you can into the switch... get the system so that it is stable (no pops and cracks for at least 15 minutes)... then if your switch has it... press the IGMP snooping enable button.

You should hear absolutely no difference. NB you should allow the system to run for at least double the IGMP lease time to ensure something funny is not going on... also at present this experiment should not be conducted with Apple computers sending multicast - Part of Apples IGMP implementation at present can be misinterpreted by some switches, and lead to blame being wrongly apportioned - Windows (or Dante-Enabled Hardware) does not suffer from this at the moment.

Again, if there is a drop-out, or some other undesirable operation... try reducing the bandwidth (channel count) that you are hitting the switch with to establish a SWL.

The case I mentioned before had us in the situation that at no channel count was the performance acceptable for IGMP snooping to be enabled. We still "passed" the switch for the desired application because the only reason we wanted to filter multicast was to stop the wireless access point from being flooded (this would render the Wifi controller useless). As it so happened the Cisco Aironet AP had an ingress multicast filter, so filtering in the switch (whilst the "best" method) was unnecessary as the overall system application was still fulfilled.

In this circumstance relaxing the constraints of the project saved in the order of $15,000-$20,000 whilst still actually delivering what was really required.
Logged
Senior Technical Solutions Manager, Audinate EMEA.
Pages: 1 [2]  All   Go Up
 


Page created in 0.085 seconds with 20 queries.