Network card Clock upgrade

[jabbr]

This paper discusses clock domain crossing: http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf -- and see that this is a complex issue.

[The Computer Audiophile]

Interesting topic. I won't rule out possible benefits or that some have experienced benefits from such an upgrade. However, I will provide my opinion and experience. I do the understand how this type of clock change could possibly help and I've never been able to hear differences when applying tweaks upstream of Ethernet audio equipment.

 

That's just me. I make no judgement about others or those with open minds trying to squeeze every ounce of sound quality out of their systems.

 

Sent from my Pixel using Computer Audiophile mobile app

[mourip]

Hi!

 

So, do you have experience with clock upgrade on a network card, and do you know what the frequency of the clock in a network card is?

 

Thanks in advance

 

CAT

 

So while I agree that changes to the network card in a non-AOIP setup might not make a difference in theory it seems to me that only JABBR attempted to answer the OP's actual question and did so respectfully.

 

OP did not ask if it would make a difference. He asked how to upgrade so he could try it for himself.

 

I am finding the contentiousness and chest beating a bit tiresome on CA these days. What happened to respect and a sense of discovery? How about a bit less bark and a bit more wag?

 

Hang in there Nouchka. Folks with an open mind who experiment and take risks have led the way here...

[plissken]

I you are inviting me to speculate well then ...

 

Let's start at the DAC and work our way back. For DSD let's use the Signalyst DSC1 (because the discrete design is simple and published). The discussion thread is here:Signalyst DSC1 - diyAudio) which takes as input a direct DSD signal or alternatively for PCM the I2S or PCM signals e.g. the PCM1704 datasheet discusses: http://www.qlshifi.com/jszl/PCM1704.pdf

 

Let's assume that the signal integrity of either the DSD, I2S or PCM lines is of paramount importance.

 

From the network, the bits necessarily have a clock domain crossing from the NIC clock to the master DAC clock (e.g. BCLK).

 

Perhaps having low jitter on the NIC input improves the clock domain crossing and if so, might result in less jitter on the BCLK.

 

That could be tested.

 

Packets don't directly pass from the NIC clock to the I2S or whatever is clocking them however. The only two clocks involved on the DAC are the I2S and the USB clock.

 

Again, start playback, pull the network cable, and the DAC is still receiving data. You are trying to bend a paper that doesn't have anything to do with the conjecture to fit.

[plissken]

Interesting topic. I won't rule out possible benefits or that some have experienced benefits from such an upgrade. However, I will provide my opinion and experience. I do the understand how this type of clock change could possibly help and I've never been able to hear differences when applying tweaks upstream of Ethernet audio equipment.

 

That's just me. I make no judgement about others or those with open minds trying to squeeze every ounce of sound quality out of their systems.

 

Sent from my Pixel using Computer Audiophile mobile app

 

Chris, it can not make a difference. Again start playback, pull the plug, and tell me what the clocking of the Ethernet PHY has to do with the playback that you are currently experiencing. A clock is about timing, timing is about jitter control to accepted parameters. Mac, Linux, Windows are not RTOS's and variance on the Ethernet side including some clock float, aren't going to affect playback unless the buffer empties.

 

Read the paper Jabbr provided. It doesn't support the conjecture because it's being misapplied / misunderstood.

 

It's really time to accept some things as absolutes. Just like a file copied from USB disk or over the Internet can't sound different if they are bitwise identical.

[Jud]

This paper discusses clock domain crossing: http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf -- and see that this is a complex issue.

 

I do not know if I can credit this paper if they did not perform the critical "pull the plug" test.

 

 

Sent from my iPhone using Computer Audiophile

[plissken]

So while I agree that changes to the network card in a non-AOIP setup might not make a difference in theory it seems to me that only JABBR attempted to answer the OP's actual question and did so respectfully.

 

OP did not ask if it would make a difference. He asked how to upgrade so he could try it for himself.

 

I am finding the contentiousness and chest beating a bit tiresome on CA these days. What happened to respect and a sense of discovery? How about a bit less bark and a bit more wag?

 

Hang in there Nouchka. Folks with an open mind who experiment and take risks have led the way here...

 

Why is it that I can be asked to have an open mind about a topic I understand completely but when I ask:

 

If you start playback, pull the Ethernet cable, and the music still plays: What does the modified crystal on the NIC / Router have to do with it?

 

No one will venture an answer. Just throw something out there.

 

It's not chest beating if one is 100% correct. Ignorance turns into stupidity when left willfully uncorrected.

[plissken]

I do not know if I can credit this paper if they did not perform the critical "pull the plug" test.

 

 

Sent from my iPhone using Computer Audiophile

 

Jud, are the I2S and Ethernet clocks ever crossing? Does the paper answer that?

 

Here you go Jud, from the paper that Jabbr posted and directly answers your question about pulling the plug.

 

5.8.1 Multi-bit CDC signal passing using asynchronous FIFOS

Passing multiple bits, whether data bits or control bits, can be done through an asynchronous FIFO. An asynchronous FIFO is a shared memory or register buffer where data is inserted from the write clock domain and data is removed from the read clock domain. Since both sender and receiver operate within their own respective clock domains, using a dual-port buffer, such as a FIFO, is a safe way to pass multi-bit values between clock domains. A standard asynchronous FIFO device allows multiple data or control words to be inserted as long as the FIFO is not full, and the receiver and then extract multiple data or control words when convenient as long as the FIFO is not empty.

 

Again. Pull the plug and the music still plays. What does the clock on Ethernet cable have to do with it? And the buffered data from the Ethernet cable isn't even the buffer the audio application setups up or the buffer the USB bus uses.

 

You don't even need to have the paper Jabbr provided. You just need to have the same open mind that one would target toward a soldering iron and a oscillator toward the question I was asking.

 

So a way to test this is to modify the Intel NIC and take a standard one and place them in a LAG. You tell me when the modified NIC is active during playback and the bog standard NIC is active.

[The Computer Audiophile]

Chris, it can not make a difference. Again start playback, pull the plug, and tell me what the clocking of the Ethernet PHY has to do with the playback that you are currently experiencing. A clock is about timing, timing is about jitter control to accepted parameters. Mac, Linux, Windows are not RTOS's and variance on the Ethernet side including some clock float, aren't going to affect playback unless the buffer empties.

 

Read the paper Jabbr provided. It doesn't support the conjecture because it's being misapplied / misunderstood.

 

It's really time to accept some things as absolutes. Just like a file copied from USB disk or over the Internet can't sound different if they are bitwise identical.

 

I told you I don't see how this could make a difference (this is me being on your side) and I said this has been my first hand experience as well (this is me being on your side again). Yet, you seem upset and determined to set me straight.

 

I don't get it.

 

I value your knowledge and willingness to share it here on CA. I just don't appreciate the delivery. You're on an endless journey to correct everyone you believe is incorrect on the Internet.

 

It doesn't hurt me to see people be inquisitive and want to try things on their own time and dime. If they derive enjoyment from the experience, even better for them.

 

We are talking about audio here. Nobody is killing puppies or saving babies. If the sky is blue and someone wants to see if it might be purple under certain circumstances, I couldn't care less. Live and let live.

[jabbr]

Jud, are the I2S and Ethernet clocks ever crossing? Does the paper answer that?

 

Here you go Jud, from the paper that Jabbr posted and directly answers your question about pulling the plug.

 

5.8.1 Multi-bit CDC signal passing using asynchronous FIFOS

Passing multiple bits, whether data bits or control bits, can be done through an asynchronous FIFO. An asynchronous FIFO is a shared memory or register buffer where data is inserted from the write clock domain and data is removed from the read clock domain. Since both sender and receiver operate within their own respective clock domains, using a dual-port buffer, such as a FIFO, is a safe way to pass multi-bit values between clock domains. A standard asynchronous FIFO device allows multiple data or control words to be inserted as long as the FIFO is not full, and the receiver and then extract multiple data or control words when convenient as long as the FIFO is not empty.

 

Again. Pull the plug and the music still plays. What does the clock on Ethernet cable have to do with it? And the buffered data from the Ethernet cable isn't even the buffer the audio application setups up or the buffer the USB bus uses.

 

You don't even need to have the paper Jabbr provided. You just need to have the same open mind that one would target toward a soldering iron and a oscillator toward the question I was asking.

 

So a way to test this is to modify the Intel NIC and take a standard one and place them in a LAG. You tell me when the modified NIC is active during playback and the bog standard NIC is active.

I see that you are at least starting to read the paper I provided rather than ASSUME a point you thought I was trying to make.

 

Clock domain crossings (the number depends on the exact system but for example): NIC to PCIe to USB to DAC input to DAC BCLK.

 

You've quoted the short answer which is correct. The long answer is that its more complicated in that the behavior of the Async FIFO is not fixed but depends on its own engineering. That's the rest of this one paper and there are many others on the topic. When designing and modeling such circuits, input and output constraints are specified. If the actual signals exceed the specifications, then instability can occur. The constraints have to do with jitter. The tighter the constraints that can be specified, the higher the performance that can be achieved (to a certain degree).

 

So yes, having better signal integrity and lower jitter on the input signals allows lower jitter on the output signals -- in general. Alternatively one could achieve the same output jitter/signal integrity with a more effective design -- much the same as different amplification circuits have different PSRR but you need to know what specs you aim to achieve in order to properly design the circuit to do so.

 

The paper does not address Ethernet clocks per se, rather clock domain crossing in general, but let me spell this out very clearly:

 

1) Data on the Ethernet line is clocked by the Ethernet clock domain

2) When data is converted from Ethernet to USB, it crosses the Ethernet clock domain to the USB clock domain

3) When data is converted from USB to I2S it crosses the USB clock domain to the I2S clock domain

4) If the last crossing is not gated by the DAC master clock, then there is an additional clock domain crossing between the I2S clock and the DAC clock

 

So of course the Ethernet and I2S clocks are crossed. A direct Ethernet input DAC might even directly cross these clock domains.

[Jud]

I told you I don't see how this could make a difference (this is me being on your side) and I said this has been my first hand experience as well (this is me being on your side again). Yet, you seem upset and determined to set me straight.

 

I don't get it.

 

I value your knowledge and willingness to share it here on CA. I just don't appreciate the delivery. You're on an endless journey to correct everyone you believe is incorrect on the Internet.

 

It doesn't hurt me to see people be inquisitive and want to try things on their own time and dime. If they derive enjoyment from the experience, even better for them.

 

We are talking about audio here. Nobody is killing puppies or saving babies. If the sky is blue and someone wants to see if it might be purple under certain circumstances, I couldn't care less. Live and let live.

 

Beyond all this: plissken, do you tend to listen more closely to someone who speaks to you from time to time in a normal tone, or someone who is constantly, loudly, in your face?

 

Yep, exactly. So if you really want to persuade people....

 

 

Sent from my iPhone using Computer Audiophile

[plissken]

I see that you are at least starting to read the paper I provided rather than ASSUME a point you thought I was trying to make.

 

Clock domain crossings (the number depends on the exact system but for example): NIC to PCIe to USB to DAC input to DAC BCLK.

 

You've quoted the short answer which is correct. The long answer is that its more complicated in that the behavior of the Async FIFO is not fixed but depends on its own engineering. That's the rest of this one paper and there are many others on the topic. When designing and modeling such circuits, input and output constraints are specified. If the actual signals exceed the specifications, then instability can occur. The constraints have to do with jitter. The tighter the constraints that can be specified, the higher the performance that can be achieved (to a certain degree).

 

Thanks for the above but do you truly appreciate what you have written? So is the Intel Pro 1000/GT an 'unstable' product that needs to be made 'more stable'.

 

So yes, having better signal integrity and lower jitter on the input signals allows lower jitter on the output signals -- in general. Alternatively one could achieve the same output jitter/signal integrity with a more effective design -- much the same as different amplification circuits have different PSRR but you need to know what specs you aim to achieve in order to properly design the circuit to do so.

 

So an Intel NIC doesn't output jitter/signal integrity? Or otherwise not properly designed.

 

The buffer is what solves the clock crossing issues. The clocks are removed from the equation and the buffer can be read from 'at convenience'. The the reading systems clock is applied to stream that static data back out of buffer.

 

 

The paper does not address Ethernet clocks per se, rather clock domain crossing in general, but let me spell this out very clearly:

 

1) Data on the Ethernet line is clocked by the Ethernet clock domain

2) When data is converted from Ethernet to USB, it crosses the Ethernet clock domain to the USB clock domain

3) When data is converted from USB to I2S it crosses the USB clock domain to the I2S clock domain

4) If the last crossing is not gated by the DAC master clock, then there is an additional clock domain crossing between the I2S clock and the DAC clock

 

So of course the Ethernet and I2S clocks are crossed. A direct Ethernet input DAC might even directly cross these clock domains.

 

Jabbr this is my point. There is no Ethernet to USB boundary as it pertains to a USB DAC.

 

Data is read into buffer off the NIC, reordering and sorting and resend if required, then into buffer set aside in some POSIX style fashion by the CPU until it's needed to be read by an application that requested it, then into the buffer set aside by the player application, into another buffer *most likely USB* and then over the wire into the DAC buffer were IT's clock is applied killing any timing variance of a clock down stream.

 

In the case of Ethernet enabled DACs, Dante etc: "Alternatively one could achieve the same output jitter/signal integrity with a more effective design"

 

And this is what those designers have done. They have to because the market place will eat them up and spit them out.

 

I have another question. When you are streaming Tidal does the clock at their server farm, the interceding routing, your ISP etc matter?

 

I'm asking questions that people seem incapable of applying critical thought to.

[plissken]

Beyond all this: plissken, do you tend to listen more closely to someone who speaks to you from time to time in a normal tone, or someone who is constantly, loudly, in your face?

 

Yep, exactly. So if you really want to persuade people....

 

 

Sent from my iPhone using Computer Audiophile

 

No, I want threads to stop sliding when I ask a simple question:

 

When you pull the Ethernet cable and the music still plays does the clock on the Ethernet cable matter?

 

I tend to listen when someone makes a cogent argument. The OP already had an answer in mind before even asking the question.

 

Jabbr provided a paper that is going to provide all the information I need to make the point that needs to be made.

[plissken]

I won't rule out possible benefits or that some have experienced benefits from such an upgrade. However, I will provide my opinion and experience. I do the understand how this type of clock change could possibly help

 

 

This is the part that I was mainly responding to.

 

I'm now asking a third question (let me know if it's asking is unreasonable):

 

Can we collectively entertain the thought that Ethernet is a data and not audio standard? That it's Async and there is actually no clock placed on the data itself but just the analog wire frequency to get two end points to form a collision domain and manage the framing from there?

 

My fourth question is:

 

Why can I be asked to keep an open mind about using a clock that is more accurate out to some Nth decimal point....

 

But when I ask what happens to the sound quality of the audio with the enhanced clock when the Ethernet is pulled and the music continues to play it presents a problem?

 

Are my questions in any way unfair?

[The Computer Audiophile]

This is the part that I was mainly responding to.

 

I'm now asking a third question (let me know if it's asking is unreasonable):

 

Can we collectively entertain the thought that Ethernet is a data and not audio standard? That it's Async and there is actually no clock placed on the data itself but just the analog wire frequency to get two end points to form a collision domain and manage the framing from there?

 

My fourth question is:

 

Why can I be asked to keep an open mind about using a clock that is more accurate out to some Nth decimal point....

 

But when I ask what happens to the sound quality of the audio with the enhanced clock when the Ethernet is pulled and the music continues to play it presents a problem?

 

Are my questions in any way unfair?

 

Typing on my phone I totally fat fingered that. I meant to say I don't understand how this clock change can help.

 

Questions are never inappropriate.

 

I'm with you that Ethernet is data. Not audio.

 

Your questions about pulling the plug are totally fine. People should try it. But, if they believe something has been done to the data prior to pulling the plug, it won't matter.

 

I'm with you, just not the tone. Sugar is better than spice for me.

[jabbr]

Can we collectively entertain the thought that Ethernet is a data and not audio standard? That it's Async and there is actually no clock placed on the data itself but just the analog wire frequency to get two end points to form a collision domain and manage the framing from there?

 

Of course there is a clock placed on the data. Just read the spec. Or since you are into pulling plugs -- why not just rip the clock out of your NIC and see if it works... FWIW: when I disconnect my Ethernet cable, the music stops ... period.

[plissken]

Of course there is a clock placed on the data. Just read the spec. Or since you are into pulling plugs -- why not just rip the clock out of your NIC and see if it works... FWIW: when I disconnect my Ethernet cable, the music stops ... period.

 

Sorry, there is no clock placed on the audio as it goes over Ethernet.

[jabbr]

I meant to say I don't understand how this clock change can help.

 

I'm all for measurements -- though these can be hard. This topic is actually very technical and again proof would be (in my mind) making X change and then measuring phase error at the DAC clock.

 

But consider this (as an analogy): It is well known that PLL can re-sync a signal or sync 2 signals together but ... and this is the big but ... PLL only does this for "far out" phase error. Every PLL has a corner frequency below which the phase error is relatively less improved.

 

So let's not assume an async FIFO is perfect at reclocking and in the absence of actual measurements, its a mistake to assume that the reclocking has the same reduction in phase error at all offsets ... what if the async FIFO has the same corner frequency like a PLL? what if the slow wandering (close in phase error) causes a clock transition collision ever "n" seconds or whatever?

 

Close-in phase errors (these are the phase errors that "fatten" what would otherwise be sharp FFT peaks) are the hardest to correct. How many phase error by frequency offset plots have you seen published for actual DAC circuits (as opposed to their clocks)?

[jabbr]

Sorry, there is no clock placed on the audio as it goes over Ethernet.

Sure. As I've said many times, ultimately the only thing that is important is the clocked data in the DAC itself.

[The Computer Audiophile]

I'm all for measurements -- though these can be hard. This topic is actually very technical and again proof would be (in my mind) making X change and then measuring phase error at the DAC clock.

 

But consider this (as an analogy): It is well known that PLL can re-sync a signal or sync 2 signals together but ... and this is the big but ... PLL only does this for "far out" phase error. Every PLL has a corner frequency below which the phase error is relatively less improved.

 

So let's not assume an async FIFO is perfect at reclocking and in the absence of actual measurements, its a mistake to assume that the reclocking has the same reduction in phase error at all offsets ... what if the async FIFO has the same corner frequency like a PLL? what if the slow wandering (close in phase error) causes a clock transition collision ever "n" seconds or whatever?

 

Close-in phase errors (these are the phase errors that "fatten" what would otherwise be sharp FFT peaks) are the hardest to correct. How many phase error by frequency offset plots have you seen published for actual DAC circuits (as opposed to their clocks)?

 

I hope my saying "I don't understand how a clock change can help" is taken literally. I really don't but that's the limit of my understanding. It make help or hurt.

[plissken]

I'm all for measurements -- though these can be hard. This topic is actually very technical and again proof would be (in my mind) making X change and then measuring phase error at the DAC clock.

 

But consider this (as an analogy): It is well known that PLL can re-sync a signal or sync 2 signals together but ... and this is the big but ... PLL only does this for "far out" phase error. Every PLL has a corner frequency below which the phase error is relatively less improved.

 

The PLL is only sync'ing the the READ out of buffer for the requested clock rate by the DAC chip. I.E. 16/44.1 or 24/192 or what ever else.

 

"and the receiver and then extract multiple data or control words

when convenient as long as the FIFO is not empty"

 

It has zero to do with the 125Mhz signalling rate on Ethernet. When convenient is the key term here. The PLL has setup the retrieval clock from buffer. As long as the buffer isn't underrun we are fine and as long as the process does it's FIFO correctly the send side will never see a full up buffer where it needs to write data.

 

So let's not assume an async FIFO is perfect at reclocking and in the absence of actual measurements

 

I would rather assume what is in the paper you provided: That the async FIFO is with in the design parameters and working correctly. Perfection is a loaded term and is a bit of a smoke screen.

 

its a mistake to assume that the reclocking has the same reduction in phase error at all offsets ... what if the async FIFO has the same corner frequency like a PLL? what if the slow wandering (close in phase error) causes a clock transition collision ever "n" seconds or whatever?

 

Even if a buffer has the same frequency on the FI or FO side of things you can't discount the asymetric packet size.

 

I may be able to deliver 1k packet to FIFO for every 2 reads of .5k.

 

Is this an actual case or just a mental exercise? What you are failing to recognize is that the PLL on the DAC is locking onto the buffer to clock data out of if. Again as long as the static, and this is the key term here, buffer is full, the send side clock is not material because you can't disassociate data rate from the event.

 

Are maintaining that the data in the static buffer has clocking data on it: "what if the async FIFO has the same corner frequency like a PLL" The only clock on that is the clock on the RAM that constitutes it's buffer or the USB buffer.

 

Again has nothing to do with the 125Mhz that the Ethernet cable is operational at. That data has been moved through several copies.

 

This isn't a zero copy stack.

[jabbr]

The PLL is only sync'ing the the READ out of buffer for the requested clock rate by the DAC chip. I.E. 16/44.1 or 24/192 or what ever else.

 

....

 

Is this an actual case or just a mental exercise? What you are failing to recognize is that the PLL on the DAC is locking onto the buffer to clock data out of if. Again as long as the static, and this is the key term here, buffer is full, the send side clock is not material because you can't disassociate data rate from the event.

 

Are maintaining that the data in the static buffer has clocking data on it: "what if the async FIFO has the same corner frequency like a PLL" The only clock on that is the clock on the RAM that constitutes it's buffer or the USB buffer.

 

Again has nothing to do with the 125Mhz that the Ethernet cable is operational at. That data has been moved through several copies.

 

This isn't a zero copy stack.

 

OK several different issues are getting muddled together here:

 

1) what "PLL on the DAC" are you referring to? Are you insisting that all DACs use async FIFO as described in the paper? Have you looked at specific schematics? Please show me a specific example? (That said PLL is not the best way to get low phase noise DAC because of the corner issue I've described above)

 

2) Do you think all or even most DACs use async FIFO isolation? Yes I am suggesting and have provided literature as to why this should be done but it is not done uniformly -- for example let's take the Amanero XMOS USB to I2S interface... used on DAC such as Lampizator

 

3) Maybe it is a zero copy stack but why should that matter -- what is needed is dual readout memory which can be written to with one clock and then read out with a different clock and with very careful mechanisms to be sure there aren't read/write collisions, not only with memory but also registers-- this is the domain of FPGAs but FPGAs are not nearly universally used in DACs -- these technologies have advantages that go beyond filtering and upsampling.

[plissken]

 

Your questions about pulling the plug are totally fine. People should try it. But, if they believe something has been done to the data prior to pulling the plug, it won't matter.

 

In agreement with you there :-)

[plissken]

OK several different issues are getting muddled together here:

 

1) what "PLL on the DAC" are you referring to? Are you insisting that all DACs use async FIFO as described in the paper? Have you looked at specific schematics? Please show me a specific example? (That said PLL is not the best way to get low phase noise DAC because of the corner issue I've described above)

 

2) Do you think all or even most DACs use async FIFO isolation? Yes I am suggesting and have provided literature as to why this should be done but it is not done uniformly -- for example let's take the Amanero XMOS USB to I2S interface... used on DAC such as Lampizator

 

3) Maybe it is a zero copy stack but why should that matter -- what is needed is dual readout memory which can be written to with one clock and then read out with a different clock and with very careful mechanisms to be sure there aren't read/write collisions, not only with memory but also registers-- this is the domain of FPGAs but FPGAs are not nearly universally used in DACs -- these technologies have advantages that go beyond filtering and upsampling.

 

1> I was using your example. Correct PLL isn't the universal mechanism for jitter elimination.

 

2>It's not material because we are talking about a direct boundary between Ethernet and DAC and this simply isn't the case. What DAC has Zero buffer and uses ASync USB?

 

3> No, it's not a zero copy stack period. Correct on the read write collisions in the buffer: But to circle back how does a tighter tolerance TXCO make a system even 'more solved'.

 

Here's a typical block diagram of an Ethernet PHY notice there are two buffers. The next hop is the PCIe bus and that could be buffered or DMA'd if the NIC has the appropriate CPU. But it's still not near the buffer feeding the USB for the DAC or the DAC buffer, regardless of how they have it setup. So we are back to what difference does more numbers after the decimal point of an oscillator do for audio SQ?

 

[jabbr]

Is this an actual case or just a mental exercise? What you are failing to recognize is that the PLL on the DAC is locking onto the buffer to clock data out of if. Again as long as the static, and this is the key term here, buffer is full, the send side clock is not material because you can't disassociate data rate from the event.

 

Are maintaining that the data in the static buffer has clocking data on it: "what if the async FIFO has the same corner frequency like a PLL" The only clock on that is the clock on the RAM that constitutes it's buffer or the USB buffer.

 

Again has nothing to do with the 125Mhz that the Ethernet cable is operational at. That data has been moved through several copies.

 

This isn't a zero copy stack.

 

A) not a mental exercise:

B) not a static buffer

C) No USB

D) Maybe zero copy stack