I made quick stats (TCP Throughput, TCP WindowSize and TCP RTT) of network traffic between RoonServer (RealTime linux kernel, heavily stripped-down OS, 4xcpu fixed to 2,4GHz) and RoonBridge (RPI4, also RT kernel, stripped down, 4 cpu underclocked to fixed frequency 400MHz).
I’m not defining any conclusion based on the stats, just sharing for curious ones…
My general observation is, that EtherRegen is probably chaning WindowSize to fixed value and that with EtherRegen the RTTs were without occasional spikes.
Methodology:
run tcpdump on RoonServer, just before hitting play button in Roon. Tcpdump is filtering only traffic between Server and Bridge.
Test scenarios:
RPI connected directly to LAN switch at 1gbps
RPI connected directly to LAN switch at 1mbps
RPI connected to EtherRegen 100mbps “B” port, which is connected via 1gbps OpticalModule to LAN
RPI connected directly to LAN via WiFi (it was mostly reportig 100% sigal quality and 72mbps rate)
Results:
FLAC-44.1: https://localhost.sk/dropzone/PCM-44_1-Pics.zip
DSD-128: https://localhost.sk/dropzone/DSD-128-pics.zip
I have also original pcap files if someone would be interested to see them…
I don’t have UPnP dumps available at hand, but the major difference between RAAT and UPnP was that UPnP was heavily buffering on the beginning of track, then almost no traffic for say 30 seconds and then again quick big chunk of traffic , while RAAT is working with much smaller buffers. I would wish Roon would have options to set % of track to be preloaded before playing , then setting it to 100% would basically play from RAM. To me it seems, that reducing network interrupts during playback on the transport side (RoonBridge) have positive impact on SQ. I’m sure not all transports have enough RAM to buffer whole tracks in high-res, but for people with RPI transport this is no issue as there are 8GB Rpi4s available…