@djones51 I am honesty trying to understand your post.
Is this jitter measured in the Ethernet link? How jitter in the link could affect sound if there is no "Ethernet jitter" to speak of from the NIC to the PCIe bus/refclk?
Ethernet jitter ceases to exist at the PCIe layer, it just can’t because of the electrical design.
I am honestly trying to understand, because once "out" of the "the Ethernet stack in the NIC" and hits the PCIe bus the only jitter there is, is the PCIe jitter from the different REFCLK clock architectures, and now we are talking 100MHz for PCIe 3 and 4, PCIe5 has a different refclk architecture and there we are talking phase jitter on the ranges 12 kHz to 20 MHz and 10 kHz to 50 MHz.
Needless to say that a NIC binds to the bus’s refclk and nothing else, it is just electrically impossible.
In the case that the streamer/DAC uses different protocol than PCIe for their bus architecture whichever clock they use for reference, this would be "internal-linked" to the component refclk by which all the bus timing functions would be derived from.
Again, I am tryin to understand how jitter in the Ethernet link can affect anything in the component bus refclk.
it is my understanding that if anything it is the component’s refclk which would affect the music timing, and this refclk has absolutely nothing to do with the Ethernet SSM, as a matter of fact I am not aware of any protocol for bussing that is aware of any other ref clock that does not participate in the bus and there I am certain that there is no way an SSM would be even accurate to even to execute any of the Link Inspector Commands in the bus.
I know this might be boring but I want to understand, so I kindly ask you if you can teach/explain the point of measuring jitter at the Ethernet layer and how it affects anything beyond the NIC/bus adapter.
Are we saying the same thing?
Thank you