1

Topic: Virtualized Nion

Is Peavey looking at virtualizing the NION to run on a VM? With everything moving to AVB, Dante, or Corbanet, you could run an entire campus on  a VM using only CABs if the Nion was only software running on a VM. Plus you would get all the redundancy benefits of VMware's fabric.

Thoughts??

2

Re: Virtualized Nion

I see you've been looking in your crystal ball again...

Fergy

Make it intuitive, never leave them guessing.

3

Re: Virtualized Nion

The "why haven't we thought of this yet?" crystal ball or the "who has been listening to our meetings?" crystal ball?

This is a wonderful idea and would be absolutely amazing to see it happen in the future! How likely is it that this is something that will happen in the future?

4

Re: Virtualized Nion

I see where you are coming from. We do use virtualisation extensively in our server and development environments. We have two multiprocessor servers running the VMWare ESXi hypervisor. About 2 or 3 years ago we migrated our hotchpotch of standalone Windows and Linux servers and build machines to VMs and these now all run virtualised. We also occasionally run VMs on our workstations. I mention this to illustrate that we are not oblivious to the benefits of virtualisation.

The important part of what the NION does, in reality its raison d'etre, is the low latency audio processing. We have a number of custom DSP algorithms that are designed to achieve high quality audio and low latency. These algorithms have been proved in the NION. To achieve consistent performance, which probably holds true for any comparable system we have to run the audio signal chain processing "bare metal" so we have absolute control over what happens when. Using an OS, let alone one running on a virtualised platform introduces so many timing uncertainties that all bets are off for low latency high quality audio signal processing. There has to be dedicated h/w to deal with the audio.

One thing we have issues with is network architecture. There are a lot of issues that boil down to audio engineers not being network engineers and IT engineers not being audio engineers. This is of course changing but a lot of MediaMatrix issues are down to network issues.

Expecting audio engineers to learn to manage virtualised environments or IT engineers to provide suitable highly responsive virtualised systems would probably compromise the perception of MediaMatrix. This could be overcome by providing our own virtualised boxes but then that has come back to custom h/w.

The scenario suggested is essentially a centralised architecture. Whilst this architecture is quite common a lot of people like the distributed nature of MediaMatrix. We want to continue to provide a flexible architecture to meet the demands of real world situations. As such virtualisation doesn't offer a flexible enough solution. We are aware of the need for fault tolerant systems and we want to provide one that works for MediaMatrix not one that works for Webservers.