Media Transcoding in the Cloud – GPU Performance Assessment

In a previous blog (What's the big deal about GPUs?), I discussed two software-only options available for media transcoding in a virtual, Cloud-based environment: CPU-based or GPU-based.

Last time I stated CPU-based media transcoding is somewhat inefficient solution, in terms of power and performance, while GPUs have become the de facto choice to solve large compute-intensive tasks such as media transcoding. In this blog, I will provide more details on how a GPU-based solution compares for cost and performance with CPU-based solutions as well as that of traditional hardware-based DSPs.

To compare the performance of a GPU solution, the following test configuration was established: For the GPU solution, an off-the-shelf COTS server populated with GPU processors from a market-leading vendor; for the CPU only solution, we used a standard 1U dual-socket server populated with x86 processors; and for the traditional hardware-based DSP we used Sonus’ proprietary hardware.

The test bed was created using Sonus’ SBC SWe, it’s virtualized, software-only SBC. The SBC SWe was configured in a microservices model, whereby the SBC processing for signaling, media, and transcoding is done on separate virtual instances. All three test configurations used separate CPUs for the signaling and media processing functions, so the only variability was implementation of the transcoding function.

Two use cases were examined. The first was an interconnect (peering) SBC scenario with 90% of the calls requiring transcoding. The second was an access SBC scenario with only 10% of the calls requiring transcoding. For each case, we compared the following parameters – initial cost (CAPEX) per transcode, power (watts) per transcode, and transcodes per RU. The results are shown below:

Interconnect (peering) scenario - 90% of calls requiring transcoding

• The relative cost of the GPU solution was 50% less than both the CPU and DSP solutions.
• For power per transcode the GPU solution was one-third higher than the DSP solution, but both solutions were less than 30% of the power/transcode required by the CPU solution.
• For transcodes/rack unit (RU) the GPU solution was about one-third less than the comparable DSP solution and only 20% of the transcodes/rack of the CPU solution.
• Projecting forward one year with increased processing and lower costs for both CPUs and GPUs, the GPU solution continues to gain advantage faster in all three parameters.

Access scenario - 10% of calls requiring transcoding

• The relative cost of the GPU solution was 25% lower than then CPU solution and 50% of the DSP solution.
• For power per transcode the GPU solution was marginally higher than the DSP solution, both of which were only 60% of the power required for the CPU solution
• For transcodes/rack unit (RU) the GPU solution was about 25% less than the comparable DSP solution and less than 50% of the transcodes/rack of the CPU solution
• Similar to the peering scenario, projecting forward one year with increased processing and lower costs for both CPUs and GPUs, the GPU solution continues to gain advantage in all three parameters. However, the advantage gained by the GPU solution versus the CPU solution in this scenario is less than the peering scenario because of the much smaller transcoding requirement.

As I interpret these results, for both interconnect and access scenarios and in all three parameters, the GPU solution was superior. It was superior both today as well as projected forward. Given the increasing availability of GPUs from cloud providers such as Amazon, I believe it will be only natural to expect GPU-based solutions to dominate media transcoding for any virtual, Cloud-based SBC deployment.