The visual effects (VFX) sector is one of the most challenging to network for. The creative studios that produce the computer-generated imagery (CGI) we watch on screen are rendered with high-performance computing (HPC) resources, and many of these resources are in the cloud. VFX rendering, which is done in post-production, requires burst capacity–the ability to bring up a lot of compute at a moment’s notice and conversely, keep them dormant when the effects are still in pre-production and production.
Rendering is a process by which 3D scenes are converted into a series of 2D images that enhance the texture, lighting, and shading, among other aspects, of the visual effect. It’s typically handled by graphics processing units (GPUs) that require lots of compute power. The rendering is often done in render farms–server farms that sit inside a cloud provider’s data centers. Depending on the complexity of a scene, rendering can take days, weeks, or even months.
Reliable, low-latency connectivity is absolutely critical to VFX rendering. If data is delayed in delivery between on-prem and cloud resources, the project will inevitably also be delayed. Many companies use VPN connectivity over the public internet to connect their on-premises infrastructure to their render farms, and those IPsec tunnels are prone to breaking or becoming congested due to the bandwidth limitations of best-effort internet connectivity, creating headaches for the creative teams who have to set up and manage these tunnels.
How VPN Failed VFX
An industry-leading VFX company known for creating digital imagery for feature films, advertising, and games, began seeing higher-than-desired round-trip time (RTT) on a mission-critical VFX application. The company was using VPN tunnels over the public internet to connect to its Google Cloud virtual environment in Hillsboro, Oregon from its production studios in California and Vancouver, British Columbia, Canada. The application required a sub-20ms RTT from the originating data center in Oregon, but began experiencing RTTs of 40ms, with spikes that were even higher.
Leaving Latency On The Cutting Room Floor
The company used PacketFabric to establish a direct, secure connection to GCP in Oregon. This improved application performance because traffic now traveled a shorter distance on PacketFabric’s private Layer 2 network rather than traversing the public internet between Hillsboro, California, and Vancouver. Internet connectivity is by nature less reliable than private network connectivity with dedicated circuits. The PacketFabric connection to GCP provided a stable and predictable RTT for the company’s VFX post-production application.
How stable and predictable? The company went from unpredictable RTTs of over 20ms to a steady 4.5ms using PacketFabric. The company cut their RTT by at least 75%
Getting Up and Running Fast
The solution wasn’t complicated. The customer was able to provision the connection in minutes on the PacketFabric portal, receiving an executable Letter of Authorization (LOA)/Connecting Facility Assignment (CFA). The PacketFabric Customer Success organization procured both cross connects for the customer and the connectivity was up and running nearly instantly. Provisioning the same type of connectivity from telco might take weeks or months.
Problems with Application Performance?
Having to troubleshoot suboptimal application performance is part of a network engineer’s everyday job.
If you’re looking for a connectivity solution that gives you lower, more predictable RTTs, procuring and provisioning private, dedicated connectivity is the best answer. There are many companies that can provide you this connectivity if you sign longer term contracts and are willing to wait a long time for the connectivity to be installed. But network-as-a-service providers like PacketFabric, who have built a carrier-grade network with services that can be ordered and instantly provisioned via a portal, can give you the connectivity you need much faster, so you can experience the latency benefits right away.
Are you having problems with application performance? Talk to one of our sales engineers.