Diretta audio protocol

[jabbr]

On 1/7/2021 at 6:51 AM, FredericV said:

By splitting the data into smaller packets, there will be more interrupts, and based on our testing this causes more software jitter as the cpu is interrupted more frequently to handle the incoming packet. This radiation is leaking inside the enclosure of the streamer and this can be measured.

With our own DSP, the DSP actually sounds a lot better when working on larger chunks instead of very small chunks. The smaller the chunks, the more context switches, and more noise generated by the cpu.

In a former life I was a network engineer for Alcatel, so looking at their approach they have to convince me why it would sound better sending a lot of small chunks instead of larger packets.

Furthermore in the screenshots I see LGPL, but is their protocol open source or not (as they want to license it to manufacturers), and how would it work with open source players such as MPD and Logitech Media Server - LMS already having a bitperfect protocol for this purpose.

Also to solve the noise issue on a LAN, all these isolators and optical solutions are not going to prevent ingress packets to arrive, causing an interrupt generated by the NIC, and every interrupt and potential context switch generates RF noise which is emitted from the CPU.

On CPU's interrupt handlers and userspace code actually fight for the same resources, and the more switching the more software jitter.

 

 

Err ... sorry this isn't how modern NICs work. My Mellanox ConnectX-4 and 5 NICs ***most certainly*** don't generate a CPU interrupt for each packet.

In ancient days, perhaps, but modern networks just don't do this and the topic is far too complex for a robust discussion here ... see RDMA, ROCE

Also look at how an FPGA processes Ethernet.

 

A lot of these things is frankly why I'm hesitant to look at Diretta without access to a highly technical whitepaper. It's just handwaving to me otherwise.

[jabbr]

1 hour ago, Miska said:

 

If protocol uses very small packets, it'll certainly have very frequent wake-ups. Something I specifically want to avoid with NAA. When NICs bundle several MTUs together, it just makes protocols relying on small packets suffer (for their own good).

 

In summary: the entire TCP/IP stack can be implemented on the NIC:

 

https://shelbyt.github.io/rdma-explained-1.html

https://community.mellanox.com/s/article/what-is-rdma-x

 

in any case my point is that the CPU “wake up” issue is not inherent to TCP/IP and the idea that an arbitrary protocol is “better” than TCP/IP is not in following with modern network implementations. 

 

[jabbr]

1 hour ago, Miska said:

 

Yeah, for gaming, the popular Killer NIC has also been doing that to reduce latencies and CPU load. I have bunch of Gigabyte motherboards with Killer NIC. Intel has also pretty good offloading support even on the cheaper NICs integrated to the motherboards.

 

HQPlayer NAA protocol (built on top of TCP and UDP) is trying to utilize these features

 

I know that Intel implements Data Direct IO (DDIO) in Xeons and their NICs to improve power performance and reduce latency on small packet tasks.