<div dir="ltr"><div>Hi Harry,<br><br>Interesting thoughts. My only concern regarding the networking is that we should keep things nice and simple, doing routing and all those sort of things on the master makes things complicated and difficult to troubleshoot. The person on that station has their hands full as it is without worrying about the network. We should decide if the 4G network will work for us (also affordable for PLUG) and use a hardware box to do the routing or do our best with what's available on premises. Until the issues at the Hyatt, networking hasn't really been much of an issue as the wired network at space cubed "Just Works". Cables across the floor aren't ideal, but unless there are free ports we know good, that's what we should stick with.<br>
<br></div><div>As for puppet, that's an awful lot of work and infrastructure to address an issue in the stack that doesn't really exist. Most of our issues revolve around no longer developed software that is being rewritten (but not even close to complete from my understanding) and a connectivity standard that's being phased out. This is where we need to focus our efforts for LCA.<br>
<br></div><div>Our focus for the monthly meetings should be as you've noted getting solid kits together. Network Kit, Audio kit, Mixer kit, slave kits etc. Our speed of setup is usually greatly hampered by a missing key item or hunting through half a dozen boxes looking for an camera/adaptor/cable that is missing from whatever we're trying to setup.<br>
<br></div><div>Leon<br></div></div><div class="gmail_extra"><br clear="all"><div>--<br>DRM 'manages access' in the same way that jail 'manages freedom.'<br><br># cat /dev/mem | strings | grep -i cats<br>Damn, my RAM is full of cats... MEOW!!</div>

<br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 9:56 AM, Harry McNally <span dir="ltr"><<a href="mailto:harrymc@decisions-and-designs.com.au" target="_blank">harrymc@decisions-and-designs.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello AV list<br>
<br>
Nick gave an overview of the outcomes of the WAIA broadcast and I'm going to pre-empt him this time and explain my confusion about the setup last night.<br>
<br>
When Nick and I looked at the systems on Monday evening (UCC) I'd asked whether the network issues could be avoided by running an entirely separate (electrically isolated) local network for the AV system with a separate network connection to the interwebs so any disruption to internet broadcast did not impact on the rest of the local network; recording and communication could continue if uncontrolled network connections failed. I'd considered that the Puppet talk was the next test of what we were heading to for LCA.<br>

<br>
Some work was done to confirm this was possible and Network Manager on the master and one camera slave was setup (with wireless initially) to confirm that NM was capable of this local network configuration. The plan was to move to ethernet local network and run that isolated system at the Puppet talk. I intended to get down and help Nick with that setup but got there late.<br>

<br>
Here's how my brain (slowly) worked with the preconception of an isolated local network as I attempted to assist.<br>
<br>
The decision to use the Spacecubed network was on the basis that "PLUG put it in and we know that it works". Unfortunately this assumption was an important experience from the POV of the LCA implementation that is very near.<br>

<br>
AV = many other decision making voices<br>
<br>
AV: "We don't want to have cables across the floor, just use the wall ports"<br>
<br>
Me: "Hm. Ok so we can adjust patch cables on a panel somewhere to make our network ... ?"<br>
<br>
AV: "No. We know this network works we don't need anything special here"<br>
<br>
Me: <looks for wall ports and finds them fully occupied><br>
<br>
AV: "I think we can disconnect this black cable"<br>
<br>
<Spacedcubed loses it's SIP phone for a while until we agree it's probably best to restore the cable ...><br>
<br>
AV: "This other cable goes to this access point"<br>
<br>
Me: "Well, I'm not sure we can disconnect the wireless either ..."<br>
<br>
AV: "It's ok there is a daisy-chain connection on the AP. Everything has this these days. We'll just connect to that"<br>
<br>
Me: <thinks now> Oh. I'm really am behind the times but I don't understand how that is going to transparently manage our isolated traffic. I'm out of my depth here.<br>
<br>
Further guidance meant the other camera went avslave->1GB switch->some office wireless router (of completely unknown config)->wall port->spacecubed switch (somewhere)->wall port->another switch of our own in the directors room->avmaster ...<br>

<br>
My pondering of this later was that the network was installed (and like other homilies) "network use expands to consume all wall ports (and then people start adding their own switches for expansion ...)". I don't agree that the network was in a state that was predictable and I also roundly condemn everyone for not being able to read either Nick's or my mind and know what was expected (dammit)! ;-p <- Despite this emoticon, this was serious deficiency on my part of not articulating the decision we had made in isolation which other AV people needed to either accept/reject but at least understand what we were trying to achieve.<br>

<br>
My observation and tentative suggestion is that at LCA/UWA if internal wiring is to be used (or cable runs added as needed) there will/may be wall ports that AV needed dedicated access to. There will/may be ports on patch panels that will/may need patch cables marked as part of the LCA AV network and rooms secured to prevent changes to those patches. There will/may be switches and routers that form part of the LCA network that AV may be required to pass traffic through. I'm assuming too that this woring must co-exist alonside UWA network and that they will be required to have isolation. There is much to do.<br>

<br>
In addition, Luke Williams talk was prescient because I wonder if the configuration of these systems might be better managed with Puppet rather than imaging so they can be trimmed down from stock Ubuntu and any network failover config setup is well defined and reproducable. I'd made this suggestion to Jason last night and that perhaps Luke could provide some input. It was an off the cuff email comment but I think more than ever this morning that it is worth consideration.<br>

<br>
Either way, I was happy to volunteer to assist with LCA AV but I am completely out of my depth with the performance and security that the networks and AV will require. I'm also happy to take instructions from an AV  director (including get out of the way!) and there will be others too who can help but (I think) we will just flap around helplessly if the systems are not robust.<br>

<br>
Last night felt to me like a wake up call that some quiet urgency for acquiring components and adding to AV robustness prior to curtain call LCA2014. It is easy for me to say than contribute expertise so I apologise if I'm actually asking others for more.<br>

<br>
My suggestion for enforcing documented equipment management into single "packages" or kits is a heartfelt one (sorry that is seems naff Luke). The equipment needs to be deployed with as much precision as you can muster and things going astray (as they have already) is a very simple and avoidable failure risk on the day.<br>

<br>
More than my 2c<br>
Harry<br>
______________________________<u></u>_________________<br>
AV mailing list<br>
<a href="mailto:AV@plug.org.au" target="_blank">AV@plug.org.au</a><br>
<a href="http://lists.plug.org.au/mailman/listinfo/av" target="_blank">http://lists.plug.org.au/<u></u>mailman/listinfo/av</a><br>
</blockquote></div><br></div>