Hello,

 

This blog post will be a work in progress as time and motivation allow but in this first go round I wanted to start off by talking about the bandwidth requirements (As Observed) from a networking perspective while streaming several different flavors of music files found in your average Audiophiles music library.

 

To date, I have not yet seen anyone post this sort of information on the web showing the actual "flow" patterns and behavior of the various streamed files under test. Understandably, this is probably not all that interesting to many folks and maybe even a bit too far "in weeds" for this given topic but in any event I found it quite interesting and felt maybe the information could be useful to the Computer Audio community in some way now or in the future.

 

At this point its probably a good idea for me to first talk about how I went about gathering this sort of information to prove its validity and worthiness of posting. Afterwards I will move on to the meat and potatoes of the topic itself.

 

Preparation Steps:

 

Step 1

 

I built a dedicated NMS (Network Monitoring Station) using a fresh install of Windows 8.1. The NMS itself is a virtual machine which lives as an instance on Oracle's Virtual Box platform. The physical host machine which supports the virtual NMS runs a copy of Ubuntu 14.04 LTS.

 

During the install of the NMS I chose to place its virtual disk files on the local Ubuntu Host as to avoid any unnecessary network activity which could have skewed the results gathered during this test. The virtual NMS had its network card configured as a "Bridged" adapter which essentially means that it is a dedicated resource on the network, has its own unique MAC Address and receives a DHCP IP Address all its own. This step should, I believe, help filter out any excess chatter taking place on the physical Unbuntu host itself where the virtual machine resides.

 

Step 2

 

Once my NMS was built I proceeded to download a copy of Paessler's "PRTG Network Monitor" software which I have used in the past while doing my day job and am very familiar with. The software is Free for 30 Days and includes full functionality during that time. I then performed the install on the fresh Win 8.1 NMS virtual machine.

 

Step 3

 

I used an enterprise class 8-Port Cisco 2960G switch between the NAS being tested and the NMS computer. The switch itself is a bit more advanced then your average Linksys but still only a basic Layer2 device (ie..no routing). Despite being a lower end Cisco product it still includes the ability to configure an SNMP (Simple Network Management Protocol) community which is the protocol I ultimately used gathered the data for this blog post. Another benefit of using this switch is that it includes a fairly sizable and mature library of MIB's (Management Information Base) for use with SNMP for monitoring purposes.

 

Step 4

 

After setting up an SNMP community on my Cisco switch I then used the PRTG software to scan the IP Address of the switch to look for sensors to monitor. One of the sensors it discovered was the Ethernet Interface where my Synology NAS is plugged into. This interface and the network traffic passed thru it is the source for all data gathered for this blog post.

 

Once I had the above configured I proceeded to adjust the default data gathering interval used by PRTG (60sec) to something a bit more aggressive. In this case I used the lowest supported interval of 10sec per sample. Basically this means that every 10 sec the PRTG monitoring software will "Sniff" the port where the NAS device is plugged into and show me what it see's on a graph and table within the PRTG software. In my case, I will use the Table data from PRTG to then Import it into an MS Excel Spreadsheet for chart creation as seen later in this post.

 

The Streamed Music Files Being Tested:

 

So in order to maintain some form of consistency for this test I dug thru my music library for a group of files that all used the same file type. In the case of this test I used all .FLAC files (except DSD) at the following Bit/Freq rates:

 

16bit x 44Khz - Paul Van Dyk - The Other Side - Politics of Dancing Album

24bit x 48Khz - Peter Gabrial - Heroes - Scratch My Back Album

24bit x 88Khz - Three O'Clock Blues - Eric Clapton & BB King -Riding w/ the King Album

24bit x 96Khz - Stevie Ray Vaghn & Albert King - Blues At Sunrise - In Session Album

24bit x 192Khz - Madonna - Lucky Star - Madonna Album

DSD64 (.dsf) - Boston - More Than A Feeling - Boston Album

 

The Test Process

 

The test approach was pretty simple. I would play each file one by one, record its start and end time, copy the data in the PRTG table for that file then move on to the next one. Rinse and Repeat. Doing it this way would also help to keep the information in the table within the PRTG software nice and separate to avoid any mistakes.

 

The PRTG Software was able to gather both the Volume of data coming from the NAS to the Cisco switch as well as the Speed/Rate at which that data was passing thru the Interface. The Interface used by my NAS is marked ETH0/3. I choose to use this Interface as my data gathering source because there are no network hopes involved between it and the NMS virtual machine which is Local to the same switch. Maybe at some point I will try another test on a different switch further downstream which is Local to the music server itself and see if the output on the chart looks any different then it does here.

 

The Results

 

As you will see below the different files do exhibit a very different behavior as they pass thru the switch. The Red Book file appears to require very small, short bursts of network bandwidth while playing. You can see that roughly every 30 secs or so the music server asks for a 4MB burst and in between that request there are other smaller requests for 1KB of data every 10sec. I suspect this has something to do with pre-determined buffer sizes configured on the music server for the various files being tested.

 

I found it very interesting that the 24x192 file was the most demanding in all cases. This went against my initial assumption that the DSD file would be the most demanding since I thought it contained more data. After some further thought on this I suspect it has something to do with how the file is packaged. Maybe more efficient with less white space but thats just a hunch.

 

Nevertheless, in the grand scheme of things there doesn't look to be any real issue present in terms of the streaming bandwidth requirements for any of the files as long as someone can ensure a solid 30MB of bandwidth is available for streaming from a wired or wireless connection at home. One thing that folks should take notice to though is that during the beginning of each song there is a fairly large spike/request made to begin playback for each of the files and as the file quality goes up so does the need to maintain that solid 30MB of readily available bandwidth. For those in the Wireless camp with antennas at further distances away it wouldn't be hard to imagine that some parts of the house may not have 30MB of headroom to play with so check to make sure your covered (no pun intended) to avoid any issues.

 

Well thats all I have for now. Please feel free to offer any thoughts or observations of your own

 

Thanks

 

 

Traffic Analysis - Incoming Transfer Rate Comparison of the various files under test

 

[ATTACH=CONFIG]16964[/ATTACH]

 

 

Traffic Analysis - Incoming Data Volume Comparison of the various files under test

 

[ATTACH=CONFIG]16965[/ATTACH]