NAS Hdd filesystem
Posted by: LarsDK on 22 December 2013
After 2 hdd failures on US, I am replacing US 2tb w US ssd + synology ds713+ nas w 2 wd red hdds in raid for baxkup
Which filesystem should I use to format the Hdds to best work w NDS?
I assume i should use raid 0 for mirroring
Any other tips/hints?
Many thanks
Lars
I recently added a second hard drive to my Synology, which I use only for backup, and it chose Synology hybrid raid, which gives one disk redundancy. That should work for you.
I recently added a second hard drive to my Synology, which I use only for backup, and it chose Synology hybrid raid, which gives one disk redundancy. That should work for you.
Agreed. This is how I run my 2 hdd Synology nas.
Formatting is done from within the management software of the NAS after startup.
Usually it is some Linux format and not a windows format.
The physical format of the drives is of no relevance to the NDS - what is important to the NDS is that the UPnP server is stable and reliable.
The format of drives in a NAS is "hidden" from the devices that access them by *NETWORK PROTOCOLS* however the NDS does not access the network shares directy - it *ONLY* talks to UPnP servers.
Best Regards
Phil
... however the NDS does not access the network shares directy - it *ONLY* talks to UPnP servers.
Best Regards
Phil
Unfortunately
Although there are some reasons why it would be handy to have the ND/Uniti Series streamers access shares directly there are a number of downsides - large collections of music spread over many shared folders would mean that a lot of processing and memory would need to be dedicated to maintaining media lists etc - so using UPnP means that we can keep a lot of the performance degrading housekeeping away from the player itself ... we built the UnitiServe / HDX / NS0x UPnP servers so that they were able to be flexible (in that they can compile together music from numerous locations and present it as a single collection - quite a rare function in itself) as well as being able to easily force the decompression of source files to uncompressed "WAV" formats for playing - hence removing that load from the player itself.
Unfortunately, generally, it's still not very well understood what significance the UPnP server itself has to the performance of a system as a whole but - just as you know that the performance of a system can be improved by upgrading the "free" audio hookup leads that are supplied with audio components then using a good UPnP server also has a very positive effect on performance, responsiveness and functionality.
Although there are some reasons why it would be handy to have the ND/Uniti Series streamers access shares directly there are a number of downsides - large collections of music spread over many shared folders would mean that a lot of processing and memory would need to be dedicated to maintaining media lists etc - so using UPnP means that we can keep a lot of the performance degrading housekeeping away from the player itself ... we built the UnitiServe / HDX / NS0x UPnP servers so that they were able to be flexible (in that they can compile together music from numerous locations and present it as a single collection - quite a rare function in itself) as well as being able to easily force the decompression of source files to uncompressed "WAV" formats for playing - hence removing that load from the player itself.
Unfortunately, generally, it's still not very well understood what significance the UPnP server itself has to the performance of a system as a whole but - just as you know that the performance of a system can be improved by upgrading the "free" audio hookup leads that are supplied with audio components then using a good UPnP server also has a very positive effect on performance, responsiveness and functionality.
Phil
I have had to read this a few times but I think I understand it now .
Although there are some reasons why it would be handy to have the ND/Uniti Series streamers access shares directly ...
Yes, as the lower levels of network connectivity are much more stable than the UPnP-level connections, because most UPnP servers aren't as robust as the CIFS/NFS-implementations. Also many consumers lack the network/UPnP debugging skills to resolve playback issues.
... there are a number of downsides - large collections of music spread over many shared folders would mean that a lot of processing and memory would need to be dedicated to maintaining media lists etc - so using UPnP means that we can keep a lot of the performance degrading housekeeping away from the player itself ... we built the UnitiServe / HDX / NS0x UPnP servers so that they were able to be flexible (in that they can compile together music from numerous locations and present it as a single collection - quite a rare function in itself) as well as being able to easily force the decompression of source files to uncompressed "WAV" formats for playing - hence removing that load from the player itself.
Yes, I concur that having elaborate music management on the player itself is a bad thing for sound quality. That's why I don't have music management at all and can manage quite happily with:
- a directory structure that follows \composer\genre\album\tracks.wav and also
- a parallel directory structure that follows \artist\album\"shortcut to album-directory with the tracks"
Having luxurious functionality on the playback device is always a trade off with sound quality. My Audio PC is based on Windows 2012 Server Core edition, so is pretty basic.
Unfortunately, generally, it's still not very well understood what significance the UPnP server itself has to the performance of a system as a whole but - just as you know that the performance of a system can be improved by upgrading the "free" audio hookup leads that are supplied with audio components then using a good UPnP server also has a very positive effect on performance, responsiveness and functionality.
User experience is indeed best served with a very good and stable UPnP Server if one wants to go that route. That's why I think the NASes with Wonky e.g. is not a good idea for most consumers, and the more computer savvy will know how to find, install and maintain the better UPnP servers. The not so computer savvy IMHO best stick to out of the box devices like Naim server components.
What I think the positive effect of the UPnP separation of server and renderer in combination with the UPnP-streaming concept is that only little amounts of data have to sent into the internal DAC / driver of the external DAC and thereby timing of the playback of that data can be kept at an optimum. This is also the route that JPlay has taken with their dual PC streaming concept though they don't use UPnP for this communication but keep it at the level of UDP-communication.
But all this being said and done, I have noticed recently that another player MQn, manages IMHO to even top this type of streaming playback. The low level details of their programming are beyond me, but this player is a single PC player that has been written for only the WASAPI interface and it manages to better JPlay. And they do it by (among other things) optimising memory alignment, CPU-cycle optimisation, finding optimal Windows CORE AUDIO commands and command sequence optimisation combined with finding the optimised settings for timer resolution, clock rate and buffer size.
So I think for the computer savvy and those who can forego on flashy user interfaces and music management, there is a lot of computer audio frontier developments that one can profit from without having to fall back onto UPnP concepts.
Cheers
Aleg
Brilliant 4-hands summary, Phil & Aleg. Thanks. (I personally knew that already, but I'm sure it will be very useful to many -- as are to me similar detailed explanations on other subjects. Always very appreciated.)
MQn has been hinted at a few times before on here. It's somewhat funny to see this kind of development, that sort of aims to turn a general-purpose computer into a very dedicated one -- what a streamer, eventually, already is.
General-purpose vs dedicated, a very old story in the computing field, as is the hardware vs software debate. Nothing changes, everything stays the same -- except the times. A good thing, as it allows everyone to choose what suits him best, with a little help from the forum !
Phil, Aleg, well I have found TCP parameters on the UPnP server can affect the sound of a NDS and NDX. I wouldn't venture to say certain TCP parameters are better than others .. Yet.. But I do hear differences and am looking into it. The differences are less pronounced but not dissimilar to the audible decode effects between WAV and FLAC.
I have heard this on my 'humble' 282/250 system as well as a 500 series system.
All I can confidently say right now is that I prefer the 'sound' of Asset running on a Pi as opposed to Windows into my Naim, and therefore the Pi is now part of my permanent setup. (This is with identical media coming from the same CIFS mounted NAS). My WHSv1 running on a Asus micro server sounded superb as well, although it did vary slightly, but that has since hit the dust.
Simon
Phil, Aleg, well I have found TCP parameters on the UPnP server can affect the sound of a NDS and NDX. I wouldn't venture to say certain TCP parameters are better than others .. Yet.. But I do hear differences and am looking into it....
Simon
Simon
I can imagine it does matter. I'm not knowledgeable enough on the level of TCP/IP configuration, but I have toyed with NIC buffers and offloading and changing these give noticeable effects as well.
Cheers
Aleg
Simon, do you think that's because the network settings on the Pi are tuned differently, or because the Pi is an electrically quieter computer compared to your previous Asus server ?
As Asset now runs on Linux, that means it could also run directly on a Linux-based NAS. That would be one less computer on the network (admittedly at the expense of a more busy one). I'm wondering if the mains electrical pollution from a computer has more influence than the network parameters, what do you think ?
I'm still trying to figure out what the most important variables are regarding network streaming, but it seems the dust hasn't settled yet.