Film-Tech Cinema Systems
Film-Tech Forum

Post New Topic  Post A Reply
my profile | my password | register | search | faq & rules | forum home
  next oldest topic   next newest topic
» Film-Tech Forum   » Operations   » Digital Cinema Forum   » Auditorium vLan networking

Author Topic: Auditorium vLan networking
Gunnar Asgeirsson
Film Handler

Posts: 63
From: Iceland
Registered: Jul 2006

 - posted 10-31-2017 06:46 AM      Profile for Gunnar Asgeirsson   Email Gunnar Asgeirsson   Send New Private Message       Edit/Delete Post 
Now i might be even to technical for this forum but it does not hurt to ask.

I have work as projectionist for 12 years, 2 years ago i did take a lot of curse for networking purpose. Cisco CCNA, CompTia Network+ Microsoft MCSA and more stuff.

The cinema i am technical director in (previously projectionist) have 3 screening room.

The thing is all this digital cinema equipment are on the same lan. It works well but as soon as i do some heavy file transfer. Like transfering DCP´s from the DCP mastering computer directly into the cinema servers the network might start to choke in one way or another.

For example, if i transfer DCP from the DCP mastering computer to the Dolby server in screen 1 i can not log into the CP750 processor remoetly. Just to much traffic going on and it just choke. And sometimes it do happen that i would like to transfer DCP to the server when show is going on. It works but what will fail alot is the subtitle just stop working. And of cause i know it is all because of the network is choking since it is all one lan. Not separate vlan for each screening room.

I know a lot about networking but i am really not sure about the ideal theater vs auditorium network.

So is there somewhere out there a good guideline about the best networking installation in a projection booth. Are some switches better than others.

 |  IP: Logged

Marcel Birgelen
Film God

Posts: 2610
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012

 - posted 10-31-2017 06:58 AM      Profile for Marcel Birgelen   Email Marcel Birgelen   Send New Private Message       Edit/Delete Post 
If you're experiencing this kind of problems on your network, then VLANs are not going to help you. VLANs create separate broadcast domains, but they're not going to speed up your network, unless your problem is a lot of broadcast traffic. And if there is an excessive amount of broadcast traffic, you either have a HUGE (really HUGE) network, or something is wrong.

In your case, if you're doing a file transfer from A to B and C and D cannot reach each other while doing so, you got a pretty shitty switch and might consider replacing it with something that can handle all ports at wire speed. Either that, or there is something wrong with your network architecture, like an over-saturated link between separate switches.

As for separate VLANs per auditorium: Why? You would also need a separate gateway per screen this way and if one screen would need to communicate to e.g. a TMS, it needs to cross this gateway.

VLANs should be segmented by function, not so much by physical rooms. So, splitting your auditorium LAN, office LAN, guest LAN, wireless and maybe POS network into separate VLANs with a firewall in between sounds like a good idea, splitting your auditoriums into VLANs feels like just a pain in the back.

If your subtitles drop when you do a DCP transfer, I guess you've got something else going on, something like a loop or something else that causes excessive broadcast traffic, like a broken device or a shitty switch.*

Excessive broadcast traffic can severely impact the performance of network connected devices, because they need to act on all broadcast packets they receive.

* More expensive switches offer some protection against "broadcast storms".

 |  IP: Logged

Steve Guttag
We forgot the crackers Gromit!!!

Posts: 12207
From: Annapolis, MD
Registered: Dec 1999

 - posted 10-31-2017 07:16 AM      Profile for Steve Guttag   Email Steve Guttag   Send New Private Message       Edit/Delete Post 

My first question is, did you set up the networks "The Dolby Way" buy using the Theatre and Auditorium networks?

If you did, the topology should look like a "Spoke-and-wheel" network with the Theatre Network in the middle. By design the Dolby networks have N+1 VLANs where the auditorium networks are all completely separate. Each server has an internal router to allow communication between the Theatre network and the auditorium BUT you have to put the routes in your Theatre router to list each respective server's Theatre NIC as the gateway to that theatre's Auditorium LAN.

In this manner one can be on the Theatre LAN and "see" every auditorium LAN so long as that respective server is up. Content only moves on the Theatre Network (as I recall, the key criteria to the Theatre switch was gigabit and jumbo frames).

The scheme is slick in that one has essentially an unlimited number of IPs available (each auditorium can have upwards of 128 IPs) and one can have as big a complex as they want (over 200 screens) with as many clients as needed (you have 254 IPs to share between the clients and servers, essentially a bottomless pit).

It is true that the Theatre network is only gigabit so as you are moving content, the more you move, less bandwidth that is available for the rest on that single gigabit cable/switch.

I don't know how many screens are on your network and how much content is moving about when you experience the problem but I have an 8 plex that was using the standard Dolby scheme and it wasn't an issue. Yeah, you would get slow downs when a lot of content was moving but it was never so bad as you couldn't talk to a CP750.

That said, MOST complexes around the world use a two concentric circle scheme where by the Theatre Network is treated as a media network exclusively and the Auditorium network is treated as a big management network.

What I have done, and prefer to the standard Dolby scheme is to have the auditorium network be one flat VLAN and likewise for the Theatre network (concentric circles). Via your router, you can set up the routing/gateway to allow communication to either from your computer but the bulk of your communication would be on the auditorium network to the individual pieces. VNC works on either Dolby NIC. The only reason to be on the Theatre network, at that point, is to use Jupiter client (it has to log into the "Management" for the Dolby network). Presuming you are using either a DSL100/200 or it is a mini-plex (3 or less servers with one as the TMS), then from the Dolby TMS standpoint, the Theatre network continues as the "management" network for just the TMS

So what you are left with is the Theatre network to just move content and the Auditorium network to communicate with the individual devices (servers, sound processors, automations...etc.). You won't get the slow downs because your communication with the sound processors won't depend on going through the server that may be busy sending/receiving content. You also won't depend on the server being up to talking with things on the auditorium network.

If you elect to do this, I would turn off the internal router since you will have a router doing a router's job and won't need N+1 routers trying to bridge the two networks.

 |  IP: Logged

Dave Macaulay
Film God

Posts: 2133
From: Toronto, Canada
Registered: Apr 2001

 - posted 10-31-2017 12:59 PM      Profile for Dave Macaulay   Email Dave Macaulay   Send New Private Message       Edit/Delete Post 
Dolby's solution was elegant and isolates each "auditorium" network with the content transfer on the "theater" network. What you describe to get talking to auditorium devices is great but few cinema people are up to doing that kind of routing. Sure it's a one-shot setup but I have enough problems with tracking configuration backups for servers and projectors, a failed router replacement becomes a problem if it has to be configured to get the site functional.
The two ring approach is more user-friendly, and dumb switches with no configuration are all that's needed to have connections to all devices on the management network for control of all projectors, servers, sound and automation. Content transfers go on the media network if the servers are configured to use media network addresses for sources/destinations. Local communication between server, projector, sound, and automation is low volumes of data, I doubt that the management network will get congested with any realistic number of screens.
A TMS in a large multiplex should have a high bandwidth (10G+) connection from its media store to a fast switch/router and 1G links to each server to avoid saturating the media network on switchover day when new content is pushed out to the complex.

 |  IP: Logged

Steve Guttag
We forgot the crackers Gromit!!!

Posts: 12207
From: Annapolis, MD
Registered: Dec 1999

 - posted 10-31-2017 01:44 PM      Profile for Steve Guttag   Email Steve Guttag   Send New Private Message       Edit/Delete Post 

Remember, Gunnar presented himself as IT savy so the option of how to set up the network should be his. I've done the routing and I'm far from an IT expert.

I also indicated that most (including myself) have gone with the 2-network solution.

 |  IP: Logged

Marcel Birgelen
Film God

Posts: 2610
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012

 - posted 10-31-2017 01:54 PM      Profile for Marcel Birgelen   Email Marcel Birgelen   Send New Private Message       Edit/Delete Post 
Over the years I've become a big contender of simplification of networks. There is a merit in dividing networks and connecting them with routers/gateways/firewalls, but the increased complexity also makes it often hard to debug, especially if you're confronted with situations that are new.

Any modern switch should be capable of forwarding packets at wire speed on all ports simultaneously. If it doesn't, then throw the switch away and replace it with something that does. So performance wise, there should be little to nothing to be gained in segmenting networks.

The best known reason to do segmentation is for security. You don't want people using your free wifi to be able to access any of your gear for example.

 |  IP: Logged

Harold Hallikainen
Jedi Master Film Handler

Posts: 763
From: Denver, CO, USA
Registered: Aug 2009

 - posted 10-31-2017 07:03 PM      Profile for Harold Hallikainen   Author's Homepage   Email Harold Hallikainen   Send New Private Message       Edit/Delete Post 
Now and then I hear of one of our devices being flooded with traffic not destined to the device. This MAY cause the device to log the issue and reset. I saw a Wire Shark capture where our IR panel was seeing communications between a server and a CP850, It SEEMS that switches should isolate this traffic and only send stuff to us that is destined to us (based on IP address, ARP, then MAC address).


 |  IP: Logged

Marcel Birgelen
Film God

Posts: 2610
From: Maastricht, Limburg, Netherlands
Registered: Feb 2012

 - posted 10-31-2017 09:06 PM      Profile for Marcel Birgelen   Email Marcel Birgelen   Send New Private Message       Edit/Delete Post 
The basic operation of a switch is pretty simple, especially if you ignore multicast for a moment and stuff like loop prevention via *STP/BPDU packets. Then there are just two types of traffic: unicast and broadcast.

A switch simply keeps track of which mac address is behind which port by simply learning it and administering it in a table. Once it sees traffic from a certain mac address move to a new port, it will simply update the table.

Once it receives traffic for a certain mac address on a port, it will look in the table and locate the corresponding port, it will then repeat this packet on the corresponding port. If the receiving mac address is not in the table, it will just discard the packet. If it's a "managed switch", it usually also logs such an event by increasing an administrative internal counter somewhere.

If the packet was addressed to the broadcast address, it will repeat the packet on all ports, except the one it was received on.

Now for multicast traffic, there are certain extensions to handle them in a smarter fashion and to learn which ports are participating in which multicast groups. In most cases, they're not enabled or the switch lacks the functionality. In that case, multicast is treated like broadcast traffic.

Now, Ethernet was conceived as a bus protocol, it's therefore acceptable to see unicast traffic of other devices on your device. Usually, it should also not negatively affect the operation of this device, as those packets not directed to the device should be dropped by the hardware ethernet implementation already, with the exception of you putting the interface in "promiscuous mode", in that case it will actively process ALL packets it receives. Stuff like Wireshark will put your interface in that mode.

Now, a good switch should never forward traffic to a port that's not supposed to receive the traffic, besides broadcast (e.g. ARP) and multicast (e.g. DHCP) traffic obviously. If you still see this traffic, then either your switch is a hub (which fortunately have become rare beasts), your switch is crappy (unfortunately, there are tons of crappy switches out there, also from halfway reputable names like Dell, Linksys, etc.) or some feature like port mirroring has been activated.

 |  IP: Logged

All times are Central (GMT -6:00)  
Post New Topic  Post A Reply Close Topic    Move Topic    Delete Topic    next oldest topic   next newest topic
 - Printer-friendly view of this topic
Hop To:

Powered by Infopop Corporation

The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion and agrees to release the authors from any and all liability.

© 1999-2018 Film-Tech Cinema Systems, LLC. All rights reserved.