Jump to content
IGNORED

Synology NAS SSD Cache


Recommended Posts

Upgraded from synology 1512+ to 1817+ and added a pair of 60gb ssd as raid 1 cache and noted the following. BTW, am using nas to store files and accessing it via afp from macmini running jriver mc23 to sotm sms200 to ayon stealth dac.

 

1. No difference in first 5 hours or so as the ssd cache started to fill up.

2. Noted hard disk physical access began to reduced thereafter as files are accessed from the ssd.

3. Less noise from hard disk activity and also less noise from synology fans as the unit also ran with less heat as hard disk temperature goes down.

4. Faster access time when choosing new songs.

5. Sounded better controlled especially with stacato notes with tighter bass and treble rather than leaky decay.

6. Background was also darker.

 

SSD cache is activated per volume basis and i think you would need to have all your music in one single volume to enjoy the cache.

 

cheers,,,,pete

 

Link to comment

Agree with you that it is difficult to rationalise. From the little i know about computer networking, i understand that tcpip you mentioned does have a thing called retries if the packet fails some integrity test and perhaps there is reduced retries leading to better sound. Just a wild guess.

Link to comment

Its still a source of puzzlement to me why my music stored on  class 10 SDXC  cards USB3 connected to NAS sounds clearer than music stored locally on the NAS's SSD. It's a difference I can't ignore even though it drives my storage costs to $600/TB. The difference both our approaches have in common is that the data bus is in greater use by the file read process during block transmission, less time for other processes to engage the CPU during the processing of audio. I'd love some time to see a walk through  at a macro machine processing level of what happens from disk read to encapsulation as an audio packet. However once data is in a packet it's outside audio clocking, that's handled by protocols/solutions before and after TCP/IP packet layer handling. If audio clock integrity is going to degrade it will be before or after the packet layer.

Regards,

Dave

 

Audio system

Link to comment
8 hours ago, lkypeter said:

Agree with you that it is difficult to rationalise. From the little i know about computer networking, i understand that tcpip you mentioned does have a thing called retries if the packet fails some integrity test and perhaps there is reduced retries leading to better sound. Just a wild guess.

Error rates  with working  wired Ethernet are infinitesimal. Retries due to electrical problems can delay audio buffer fill at the receiving end, cause stutter or in worst case "freeze" the playback as  unable to proceed. Wired Ethernet is an "interconnect" and any electrical wired connection can cause electrical interactions between

2 connected devices, degrade an analog audio output. So you can potentially hear a difference between wired Ethernet cables based on how they " soothe" the unwanted LRC and electrical noise interactions between switch/router and audio device. Fiber Optics and WiFi do eliminate this particular concern.

Regards,

Dave

 

Audio system

Link to comment
  • 2 weeks later...
On 3 décembre 2017 at 6:26 AM, lkypeter said:

 

5. Sounded better controlled especially with stacato notes with tighter bass and treble rather than leaky decay.

6. Background was also darker.

 

SSD cache is activated per volume basis and i think you would need to have all your music in one single volume to enjoy the cache.

 

cheers,,,,pete

 

 

tested successfully !! ("Sounded better controlled...")

thank you for this info

 

Philippe

Link to comment
On ‎12‎/‎4‎/‎2017 at 3:20 AM, davide256 said:

Error rates  with working  wired Ethernet are infinitesimal. Retries due to electrical problems can delay audio buffer fill at the receiving end, cause stutter or in worst case "freeze" the playback as  unable to proceed. Wired Ethernet is an "interconnect" and any electrical wired connection can cause electrical interactions between

2 connected devices, degrade an analog audio output. So you can potentially hear a difference between wired Ethernet cables based on how they " soothe" the unwanted LRC and electrical noise interactions between switch/router and audio device. Fiber Optics and WiFi do eliminate this particular concern.

Agree that error rates with wired Ethernet is so small to be significant.

The same cannot be said for hard disk. I was made to understand that the reading and writing of information on hard disk is a statistical and mathematical  model based on complex error correction logic which is now encapsulated on chips. This might be the rationale why your solid state memory sounds better to you.

The downside of external devices is lack of RAID protection afforded by Synology and this is why is use SSD cache. If SSD cache fails, it can be rebuilt from the hard disk.

If money no object, I would actually use SSD in place of hard disk and RAID it and do away with SSD cache to reduce the additional processing but it is too exorbitantly expensive now for poor me until SSD prices continue to drop close to hard disk.

Link to comment
9 hours ago, lkypeter said:

Agree that error rates with wired Ethernet is so small to be significant.

The same cannot be said for hard disk. I was made to understand that the reading and writing of information on hard disk is a statistical and mathematical  model based on complex error correction logic which is now encapsulated on chips. This might be the rationale why your solid state memory sounds better to you.

The downside of external devices is lack of RAID protection afforded by Synology and this is why is use SSD cache. If SSD cache fails, it can be rebuilt from the hard disk.

If money no object, I would actually use SSD in place of hard disk and RAID it and do away with SSD cache to reduce the additional processing but it is too exorbitantly expensive now for poor me until SSD prices continue to drop close to hard disk.

Need to differentiate data errors from timing here.

Data has no "clock", its a byte/block pattern of 1's and 0's.

Since the advent of the personal computer in the 1980's, there has been zero tolerance for data error transmission in hardware, firmware and software because programs don't work, banks can lose  ungodly sums of money from a data error. I am supremely confident that as long as you stay in the data (clockless) domain data sent will arrive identical to what was sent. 

 

The issue is when you need real time (clocked) analog output performance, at that point a variety of solutions are used to try to deal with the effects of path latency, error correction re-transmission impacts, hardware conversions, CPU load, etc. These are the places where the clock association originally intended for a data sample (block) can be unintentionally altered. My thoughts on this are that if you reduce the opportunity for mistakes in timing, you have a chance for better sound. Moving data off the drive faster for transmission processing seems to do this.

Regards,

Dave

 

Audio system

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...