Advice on GDC Servers- Ingest during Playback

[Bethany Tipping]

Hi all,

I manage tech in two theater locations, one has GDC SX-2000, and the other SR-1000. We've noticed it's impossible to ingest full length features during playback, it'll either cause lag in the other theaters or the ingest will be horrifically slow. Typically we ingest early in the morning or late at night when nothing is playing. However, my bosses want us to be able to ingest while showtimes are running. Does anyone know a work around for this? I think it's just a GDC issue myself, the system just seems to be unable to handle multiple tasks at once. However I am also new to learning digital cinema, so would love to hear from this community as I know your experience excels mine. Any advice would be much appreciated, thank you so much!

[Dennis Benjamin]

Are you INGESTING content or TRANSFERRING content? There is a big difference. GDC does not recommend transferring any content around on the network during playback.

You can certainly ingest LOCALLY during playback. It does take longer to do so while a film is running. For that SX-2000, it's best to ingest using the CRU drive bay using a hard drive.

[Bethany Tipping]

It can be either, transferring from another theater or our NAS which is separate storage system but is connected to all theaters. Ingesting from our Deluxe box causes lag, and if we're transferring content. We've found even ingesting from the NAS causes lag in neighboring screens even if the content is not going into that server. I ingested from a drive directly during Dune and it was probably 1% every few minutes and we needed the content within the hour. That was more of an emergency situation and not typical of our operation.

[Gordon McLeod]

Our rule of thumb with GDC no transfer or ingest while content is playing the servers tend to stutter the playback

[Steve Guttag]

The only GDC servers that tolerate (don't have significant slow downs) ingesting while playing are those with Cine Cache (SR-1000s, so equipped).

[Bethany Tipping]

Thank you ! I'll give that a try with the SR1000, it was unfortunately more an issue with our other ones so maybe we'll just have to upgrade.

[Ryan Gallagher]

We have one SX2000 and one Doremi DCP2000. Both can handle ingesting LOCALLY (CRU drive or USB) while playback... but it's almost slow enough that you might as well wait. Rarely will finish one feature ingest while another is playing, maybe you shaved 10min of ingest time. More often we'll do it for updated slides and pre-roll type stuff.

The only time our antiquated process involves network ingests is for SXSW (*cough*, like right now), and we try to avoid that on the GDC during playback. Doremi doesn't care since not using the network to throw frames at the projector.(and different physical switch/subnet from our GDC).

I think the "best practice" advice is good to follow here. But with the right network topology (GDC has multiple NICs), you might be able to get network ingests to avoid stuttering other screens. Basically try to move your transfers off the physical switches that talk to IMBs? Just an idea. The fact it affects other screens definitely makes it sound like a network congestion/bandwith issue.

Edit: Alternatively investigate upgrading existing networking switches to ones with higher rated throughput on the backplanes, so that each port can actually utilize Gigabit without bogging it down etc. But you'll still be sharing that with IMB traffic.

[Ryan Gallagher]

Just to add, before you spend any money . You could feasibility test ingesting via the secondary NIC from just about any device that can host a FTP server and bypass existing switch. The hope would be to avoid stuttering other screens, but no promises GDC would ingest any faster.

This of course assumes your 2nd NIC is not performing some other function already.

[Armand Daiguillon]

Yeah - what everybody else said ....GDC's just dont transfer while playing. (except trailers) - I had Doremis before and they had no issues with it .....
However, spending money to upgrade seems a waste. (unless you are one of the few theaters with money to burn ?)
I'd suggest just being proactive and make sure your transfers are done overnight the night before. And in emergency situations you can always "live play" direct from a drive. (you can copy any movie from your server to a drive in usually around 15 to 20 minutes, so less than any regular transfer) The one good thing about the GDC's is their easy "live play" ability.

[Marcel Birgelen]

Just to add, before you spend any money . You could feasibility test ingesting via the secondary NIC from just about any device that can host a FTP server and bypass existing switch. The hope would be to avoid stuttering other screens, but no promises GDC would ingest any faster.

This of course assumes your 2nd NIC is not performing some other function already.

I don't think it will solve the underlying problem, because I don't think that the network bandwidth really is the problem. GDC seems to have a scheduling issue on most of their servers in regards to combining playback and I/O heavy loads in general. To be honest, I think they should simply disable the ingest feature when playback is active, to avoid show disruptions. The SR-1000 seems to be sufficiently beefy to be able to handle both "ingestion' into the "CineCache" and doing playback. I guess the hardware has evolved to such an extend that it has become a no-brainer, even without low-level scheduling optimizations.

[Gordon McLeod]

I was told that the reason GDC have ingest issues while running content is that they are a software raid. That said I dont see why one would replace them when all one needs to do is schedule the transfers and ingest after hours

[Ryan Gallagher]

I don't think it will solve the underlying problem, because I don't think that the network bandwidth really is the problem. GDC seems to have a scheduling issue on most of their servers in regards to combining playback and I/O heavy loads in general. To be honest, I think they should simply disable the ingest feature when playback is active, to avoid show disruptions. The SR-1000 seems to be sufficiently beefy to be able to handle both "ingestion' into the "CineCache" and doing playback. I guess the hardware has evolved to such an extend that it has become a no-brainer, even without low-level scheduling optimizations.

I would expect that is SPOT ON relative to network ingests disrupting the screen that the server is also playing back to. The part that sounded like wider network issues was the fact Bethany would have other screens (ones not involved in the ingest) also get disrupted. Although maybe the OP wasn't clear and they were pushing to all screens and not just one when observing that network wide issue.