Reclocking data on SSD hardDrive

Hello, I have just seen a new product coming out a stick SSD with a crystek Clock on it. I was wondering are there any benefits of reclocking data on a SSD? 

I'm not expert. It is not for reclocking, it is PCIe interconnect reference clock of Tx PLL and Rx PLL. My understanding is, lower phase noise (jitter) of reference clock means lower bit error rate. There is a upper limit of bit error rate regulated on the specification. For PCIe gen4, bit error rate limit is 10^(-12), this means 1 bit upset of 1000000000000 bit transfer is permitted as the worst case (and the error is detected on the receiver and received data is discarded IIRC). I hope all M.2 NVME in the market meets this specification.

It seems, in order to meet the bit error rate spec, PCIe gen4 clock jitter limit is 500 femtoseconds rms, PCIe gen5 is 150 femtoseconds rms and PCIe gen6 is 100 femtoseconds rms. Therefore clock jitter requirement becomes stricter when PCIe generation is advanced and signaling rate is increased.

I looked into a PCIe interconnect book (M.2 NVMe has a PCIe x4 interconnect).

About bit error handling: PCIe packet size is approx. 4Kbytes maximum. Every packet has a 32bit CRC that is added by the datalink layer as a footer. On the receiver, integrity of every packet is inspected with CRC. When CRC error is found, the received packet is discarded, then the receiver replies NAK DLLP packet to the sender and this initiates packet resend. This mechanism guarantees the integrity of the data of all the packet payload received. On PCIe gen4 16Gbps, in the worst case, this CRC error resend event happens once in 63 seconds of probability, with 10^-12 BER.

About the reference clock accuracy: up to 300ppm clock drift between sender reference clock and receiver reference clock is allowed, there is a clever “elastic buffer” mechanism which absorbs the clock drift.

On 12/22/2021 at 7:11 AM, avangerx said:

Hello, I have just seen a new product coming out a stick SSD with a crystek Clock on it. I was wondering are there any benefits of reclocking data on a SSD? 

Really no, unless the SSD is total junk in which case it should be replaced. Reclocking the SSD data before it hits the PCI-e bus is sort of ridiculous because it won't reclock the PCIe bus itself. One reason PCIe gen4 has taken so long to get out has been the strict clocking requirements *for the system* including CPU etc. PCIe gen5 is even stricter. If Intel can't meet the spec no little add on is going to fix it.

11 hours ago, jabbr said:

Reclocking the SSD data before it hits the PCI-e bus is sort of ridiculous because it won't reclock the PCIe bus itself. 

There are total two reference clocks, on both end, per one PCIe interconnect and lower jitter clock on M.2 SSD improves BER of SSD→CPU data transferring path if my understanding is correct. And femtosecond order, not picosecond order of stability is required for PCIe Gen4+ reference clocks. IMO still 70℃ constant temperature oven controlled oscillator is overkill, it is designed to be used for DAC/ADC clock and its frequency stability against ambient temperature change is not necessary for PCIe reference clock (elastic buffer absorbs frequency difference of two reference clocks).

On 1/9/2022 at 1:07 AM, yamamoto2002 said:

 

There are total two reference clocks, on both end, per one PCIe interconnect and lower jitter clock on M.2 SSD improves BER of SSD→CPU data transferring path if my understanding is correct. And femtosecond order, not picosecond order of stability is required for PCIe Gen4+ reference clocks. IMO still 70℃ constant temperature oven controlled oscillator is overkill, it is designed to be used for DAC/ADC clock and its frequency stability against ambient temperature change is not necessary for PCIe reference clock (elastic buffer absorbs frequency difference of two reference clocks).

Sure, but if the SSD is within spec, and the BER is reasonable, then improving the SSD clock beyond the PCIe receiver clock won't help anything https://pcisig.com/sites/default/files/files/PCI_Express_4_0_Electrical_Previews.pdf -- see discussion of "stressed receiver"

Of course this is all measurable.

19 hours ago, jabbr said:

 

Sure, but if the SSD is within spec, and the BER is reasonable, then improving the SSD clock beyond the PCIe receiver clock won't help anything https://pcisig.com/sites/default/files/files/PCI_Express_4_0_Electrical_Previews.pdf -- see discussion of "stressed receiver"

 

Of course this is all measurable.

True, also, clock oscillators for audio DAC/ADC is designed for cleaner phase noise of low frequency range but it is not necessary for PCIe AIC reference clock, because it is suppressed by CDR on the motherboard.

Some technical terms used in the PDF above...

• AIC: add in card (PCIe card).
• clean clock: means clock is not SSC modulated.
• SSC: spread spectrum clock - clock signal is frequency modulated (modulation frequency is somewhere between 30kHz and 33kHz) to reduce EMI. motherboard reference clock is SSC modulated and AIC refclk is not SSC modulated. On older PCIe specification, in order to perform PCIe compliance testing, motherboard clock should be modified to clean clock.
• Base specification: specification for onboard PCIe devices - transmitter and receiver is directly connected without any slots.
• CEM specification: card electromechanical specification - add in cards that are inserted on mainboard slot.
• via: a rivet to connect different layers of the board electrically.
• UI: unit interval - 1 cycle of signaling bit rate, 400ps for PCIe Gen1, 200ps for PCIe Gen2, 125ps for PCIe Gen3, 62.5ps for PCIe Gen4.
• PRBS: pseudo-random binary sequence.
• compliance pattern: worst-case bit pattern consists of lowest frequency pattern and highest frequency pattern.
• CDR: clock data recovery circuit to extract clock from embedded clock data signal.
• SerDes: serialization/deserialization circuit.
• BERT: bit error rate tester.
• CLB: compliance load board - compliance test board for motherboard PCIe slots provided by PCI-SIG.
• CBB: compliance base board - compliance test board for AIC.
• SigTest: PCIe compliance test app provided by PCI-SIG, works with Agilent, Tektronix and LeCroy oscilloscopes.
• Rj: random jitter.
• Dj: deterministic jitter - consists of periodic jitter Pj (Sinusoidal jitter Sj is among them), duty cycle distortion jitter, pulse width distortion jitter, data dependent jitter and inter symbol interference jitter.
• Tj: total jitter.
• transition bit: NRZ signal changes to 1 level to 0 level or 0 level to 1 level.
• non-transition bit: NRZ signal level does not change.

SigTest screenshot from 畑山仁 (2010). PCI Express設計の基礎と応用. CQ出版社, p.223 

SigTest in action

1 hour ago, yamamoto2002 said:

SigTest in action

Nice video, everyone should recognize that this was 12 years ago and PCIe gen4 is even tighter/faster than 8 Gbps.

The same standard testing is available for Ethernet and all of these tests measure jitter as well as "stressed receiver" which is thge behavior when the incoming signal has maximal allowed jitter.

None of the "audiophile" clocking or network device companies seem to provide the results of this testing. In particular I've never seen a shred of evidence that external clocks or clock "upgrades" provide a shred of improvement in system jitter of any kind.

What if your OS does not run on a HD?

For example TinyCore and piCore both run in RAM.

In fact, if you really look at it, all real work in done in RAM anyway, HD's store data...any given task pulls data from the HD if needed to do its work.

Quote

SSD vs. RAM Speed

RAM is orders of magnitude faster than an SSD. A SSD's theoretical maximum transfer speed is that of the SATA interface -- 6Gbps, which is equivalent to 750MB/sec. A relatively fast SSD may achieve real-world write speeds of 456MB/sec, though. The theoretical maximum speed of RAM is in its PC number, so a module of PC3-12800 memory can transfer 12,800MB/sec--roughly 30 times faster than the real world performance of an SSD. Directly substituting an SSD for RAM would end up significantly slowing down your system.

https://smallbusiness.chron.com/having-solid-state-hard-drive-provide-equivalent-having-ram-68574.html

On 1/10/2022 at 5:38 PM, jabbr said:

 

Sure, but if the SSD is within spec, and the BER is reasonable, then improving the SSD clock beyond the PCIe receiver clock won't help anything https://pcisig.com/sites/default/files/files/PCI_Express_4_0_Electrical_Previews.pdf -- see discussion of "stressed receiver"

 

Of course this is all measurable.

Measurable.

Everything can be measured....what does it matter if it can not be perceived?

Walking past the 'reality' of our perception to focus on an imperceivable measurement is taking a step in the wrong direction. What if we applied the 'religion of measurements' to everything before we consume it....its not realistic.

On 2/16/2022 at 3:38 PM, Dynobot said:

 

Measurable.

 

Everything can be measured....what does it matter if it can not be perceived?

 

Walking past the 'reality' of our perception to focus on an imperceivable measurement is taking a step in the wrong direction. What if we applied the 'religion of measurements' to everything before we consume it....its not realistic.

This topic is concerning reclocking data on SSD harddrive ie very technical. *You* don't need to apply the 'religion  of measurements' in order to listen to music, nor do you need to understand the details of a PCIe bus in order to browse the web.

2 hours ago, jabbr said:

 

This topic is concerning reclocking data on SSD harddrive ie very technical. *You* don't need to apply the 'religion  of measurements' in order to listen to music, nor do you need to understand the details of a PCIe bus in order to browse the web.

Sooooooo, if you reclock data don't you need to 'measure' jitter to find if the jitter has actually been reduced?

I really don't understand what PCIe bus has to do with browsing the web. My computer has one but I don't use it, however I can still browse the web.

I'm confused.....this topic is way over my head ie technical....think I'll go to the sideline.

😆 

3 hours ago, Dynobot said:

 

Sooooooo, if you reclock data don't you need to 'measure' jitter to find if the jitter has actually been reduced?

 

I really don't understand what PCIe bus has to do with browsing the web. My computer has one but I don't use it, however I can still browse the web.

 

I'm confused.....this topic is way over my head ie technical....think I'll go to the sideline.

 

😆

You are right, the so-called "reclockers" should be measured to see if they do anything. I don't advocate using them and said that it is pointless. There are people who reclock everything and use expensive external clocks  -- which are pointless -- but I've never seen a single end to end measurement to see if these widgets/clocks actually do anything, No I don't do random stuff to my computer and then listen so see if it is "better" because life is short and I use reasonable practices.

The relevance of the PCIe bus is that the SSD is connected to it, and right you can browse the web or listen to music without worrying about reclocking the SSD.... that's my point.

2 hours ago, jabbr said:

 

You are right, the so-called "reclockers" should be measured to see if they do anything. I don't advocate using them and said that it is pointless. There are people who reclock everything and use expensive external clocks  -- which are pointless -- but I've never seen a single end to end measurement to see if these widgets/clocks actually do anything, No I don't do random stuff to my computer and then listen so see if it is "better" because life is short and I use reasonable practices.

 

The relevance of the PCIe bus is that the SSD is connected to it, and right you can browse the web or listen to music without worrying about reclocking the SSD.... that's my point.

But how good is your music without being reclocked?

I think the reclockers are sniffing up the wrong end of the issue....the stinky end.

Why not just take a step back and think about who uses clocks on musical data, where and why?

Recording studios use 'master clocks' to keep all the data oriented gear in synch....ahhhhh the magic word "synch". What good is it to reclock data without having it in 'synch' with the rest of the audio chain....no good, its useless. Best way to clock data is to use it to synch up the computer to the dac all the way until the digital becomes analog. Yes, YES YES thats it....a master clock to synch the clocks of all digital gear just like they do on the other end of the Donkey.

Without master clock, two digital sound source timings are drifted and when these signals fed onto single digital mixer, periodical click noise is heard and this noise is recorded onto file, therefore it is absolutely necessary in the studio setup. Other example is novice game youtubers who do not know the importance of sync, records game video/sound with OBS and commentary voice with separated sound file and complains two files are not in sync when loaded onto Davinci : two files timings are drifted over time and they need to align video and voice by hand editing. There is no such necessity of clock sync on audiophile music playback.

14 hours ago, yamamoto2002 said:

Without master clock, two digital sound source timings are drifted and when these signals fed onto single digital mixer, periodical click noise is heard and this noise is recorded onto file, therefore it is absolutely necessary in the studio setup. Other example is novice game youtubers who do not know the importance of sync, records game video/sound with OBS and commentary voice with separated sound file and complains two files are not in sync when loaded onto Davinci : two files timings are drifted over time and they need to align video and voice by hand editing. There is no such necessity of clock sync on audiophile music playback.

This is why instead of reclocking only one part of the audio chain we need a "master clock' to keep all parts of the audio chain in synch

16 hours ago, Dynobot said:

 

But how good is your music without being reclocked?

 

I think the reclockers are sniffing up the wrong end of the issue....the stinky end.

 

Why not just take a step back and think about who uses clocks on musical data, where and why?

 

Recording studios use 'master clocks' to keep all the data oriented gear in synch....ahhhhh the magic word "synch". What good is it to reclock data without having it in 'synch' with the rest of the audio chain....no good, its useless. Best way to clock data is to use it to synch up the computer to the dac all the way until the digital becomes analog. Yes, YES YES thats it....a master clock to synch the clocks of all digital gear just like they do on the other end of the Donkey.

there is no clock in a file or packet data stream... should limit this gedanken exercise to where clock is relevant,  from  audio file data conversion to

the point where D/A has clocked and is converting to analogue. One of the attractions of a true Ethernet DAC is that a driver could be written to eliminate any interaction with

server HW/SW so that all clocking/time domain perturbations were isolated to the network DAC for fault avoidance

4 minutes ago, davide256 said:

there is no clock in a file or packet data stream... should limit this gedanken exercise to where clock is relevant,  from  audio file data conversion to

the point where D/A has clocked and is converting to analogue. One of the attractions of a true Ethernet DAC is that a driver could be written to eliminate any interaction with

server HW/SW so that all clocking/time domain perturbations were isolated to the network DAC for fault avoidance

True there is no clock...per'se...but packets of data do indeed move at a certain rate from X to Y with the help of the CPU. 

That data can and does develop jitter as the CPU handles it esp in systems with many processes running and/or with high amounts of interrupts. Therefore, the CPU -would be- 'the clock'....that thing, that everything else needs to synch up too. And at the same time try to avoid other processes and interrupts from causing jitter as they interfer with the CPU handling those precious packets of data. If you read some of the published material from RedHat, IBM et.al they speak of different methods to reduce this jitter. Sometimes by isolating processes to certain cpu cores, other ways is to isolate interrupts to certain cpu cores as to not cause jitter.

Ethernet has its own sources of jitter which can also be reduced. This too is address in papers written by the aforementioned companies. As for myself, I go by their knowledge and practices to tune my system rather than Audiophile message boards. Granted some folks here and elsewhere are 'hella smart' but I feel a little bit better in the hands of a multi-billion dollar company with their teams of highly degree'd software engineers. No offense to the 'hella-smart' people here....😁

1 hour ago, Dynobot said:

 

True there is no clock...per'se...but packets of data do indeed move at a certain rate from X to Y with the help of the CPU. 

That data can and does develop jitter as the CPU handles it esp in systems with many processes running and/or with high amounts of interrupts. Therefore, the CPU -would be- 'the clock'....that thing, that everything else needs to synch up too. And at the same time try to avoid other processes and interrupts from causing jitter as they interfer with the CPU handling those precious packets of data. If you read some of the published material from RedHat, IBM et.al they speak of different methods to reduce this jitter. Sometimes by isolating processes to certain cpu cores, other ways is to isolate interrupts to certain cpu cores as to not cause jitter.

 

Ethernet has its own sources of jitter which can also be reduced. This too is address in papers written by the aforementioned companies. As for myself, I go by their knowledge and practices to tune my system rather than Audiophile message boards. Granted some folks here and elsewhere are 'hella smart' but I feel a little bit better in the hands of a multi-billion dollar company with their teams of highly degree'd software engineers. No offense to the 'hella-smart' people here....😁

 

 

The nature of a packet is that it doesn't exist after reception at destination... the PAD function strips the packet envelope and adds the chunk of data added to a buffer. The only complexity is sequencing, thats why the window for packet transmission is typically a low number to flow control transmission, minimize what needs to be stored while awaiting out of sequence arrivals,  re-transmissions. A good network card should have its own processor

So glad I don't have to worry about such things with my setup.

One by one, slowly but surely I ended up rolling my own [just about everything] audio related.

At first I used to suggest things to other dev's just to have them turn my suggestion down and later implement it. 

JRiver [WASAPI, Linux version, Mac Version]

Daphile [Real time kernel]

Material Skin, Roon, MoOde etc.

I've learned to keep my mouth shut and spend the necessary time to build my own from the ground up.

11 hours ago, Dynobot said:

That data can and does develop jitter as the CPU handles it esp in systems with many processes running and/or with high amounts of interrupts. Therefore, the CPU -would be- 'the clock'....that thing, that everything else needs to synch up too. And at the same time try to avoid other processes and interrupts from causing jitter as they interfer with the CPU handling those precious packets of data. If you read some of the published material from RedHat, IBM et.al they speak of different methods to reduce this jitter. Sometimes by isolating processes to certain cpu cores, other ways is to isolate interrupts to certain cpu cores as to not cause jitter.

When CPU is busy and a lot of incoming packets arrived, the packets cannot be processed are just discarded. There is no jitter to increase. I think you have some misunderstanding about this topic. Perhaps you are saying about some hard realtime system ? It is not related to PC music playback.

11 hours ago, yamamoto2002 said:

 

When CPU is busy and a lot of incoming packets arrived, the packets cannot be processed are just discarded. There is no jitter to increase. I think you have some misunderstanding about this topic. Perhaps you are saying about some hard realtime system ? It is not related to PC music playback.

Absolutely.

So what happens to jitter levels while the incoming packets are arriving and just before they get discarded?

I think I do misunderstand this topic and the deep rabbit hole it relates too. Its not a hole that I'm in....perhaps this is a Windows issue....don't know but I'll let you guys enjoy yourselves. 

My system doesn't use hard drives of any sort and certainly never run into a CPU flooded with packets.

Best.

5 hours ago, Dynobot said:

Absolutely.

 

So what happens to jitter levels while the incoming packets are arriving and just before they get discarded?

 

I think I do misunderstand this topic and the deep rabbit hole it relates too. Its not a hole that I'm in....perhaps this is a Windows issue....don't know but I'll let you guys enjoy yourselves. 

 

My system doesn't use hard drives of any sort and certainly never run into a CPU flooded with packets.

 

Best.

Thank you for your reply. On modern PCM streaming system from Ethernet, the DAC clock is fed by quartz oscillator near the DAC chip and its clock jitter do affect the analog output performance of DAC. This clock is free running (asynchronous) and decoupled from incoming packet timings / USB microframe timings / Ethernet clock / CPU clock / DMI clock / PCIe clock etc., using FIFO and flow control. 

When PCM data is arrived late due to TCP resend, PCM sample count on the FIFO buffer is decreased, it does not affect to the jitter of the quartz oscillator. When FIFO is starved, music playback is suspended until the next PCM data is arrived, still it does not affect to the jitter.

15 minutes ago, yamamoto2002 said:

 

Thank you for your reply. On modern PCM streaming system from Ethernet, the DAC clock is fed by quartz oscillator near the DAC chip and its clock jitter do affect the analog output performance of DAC. This clock is free running (asynchronous) and decoupled from incoming packet timings / USB microframe timings / Ethernet clock / CPU clock / DMI clock / PCIe clock etc., using FIFO and flow control. 

 

When PCM data is arrived late due to TCP resend, PCM sample count on the FIFO buffer is decreased, it does not affect to the jitter of the quartz oscillator. When FIFO is starved, music playback is suspended until the next PCM data is arrived, still it does not affect to the jitter.

Thank you

Have fun!

😁