Melco S100 Ethernet Switch Measurements

[Miska]

19 hours ago, plissken said:

Would there be same sample to sample variance? Either switch or streamer?

 

Again here is the problem: If you start playback on the Lumin D2 and pull the plug how long does it continue to play for?

 

Let's say you get 30 seconds at redbook. That means the data was transferred and buffered up locally 30 seconds ago.

 

So I would like to see this repeated with 48Khz 60 second sample played and then measured while playing out of buffer with the cable pulled.

 

I think it is likely some other channel than the data transfer.

 

As I suspected, in this case too, the ethernet isolation is spoiled by use of STP cable:

https://www.melco-audio.com/products/c1ae/

So likely source for the differences are ground currents through the cable shield. HFN doesn't tell what other equipment was connected to the switch and through what kind of cable, because now in this case it matters greatly.

 

I'd guess the measured differences would go away and performance improve by using much cheaper (at most $10) standard UTP6 cable... But of course they insist on using expensive wrong type cable...

 

One can use shielded STP cables only in very specific circumstances, where both sides of the connection are connected to the same common ground point by some other means.

 

Noting here, that the switch likely uses a floating PSU, although not specified anywhere what kind of PSU it has. So it doesn't likely have any ground (earth) connection of it's own. In case of Mytek Brooklyn Bridge this comes from the earthed IEC power connector it has, through the wrong use of shielded ethernet cable. While the Arcam CDS50 is floating (non-earthed) two pin IEC power connector, so in that case the mains earth is not connected through the ethernet cable. While the Lumin D2 is similar to Mytek that it has 3-pin earthed power connection and thus connects the switch ground to the mains earth through the ethernet cable and Lumin device. Then when measured, it depends if the XLR connections are used and how the ground pin of XLR is related to the measurement equipment ground and the IEC mains earth.

 

IOW, you only need an expensive cable to spoil large portion of the advantages Ethernet can offer. Of course with optical it would be much more challenging to screw up, but I wouldn't be surprised if some company decides to come up with optical cable that has metal shield connected to both ends of the cable...

 

[Miska]

19 hours ago, plissken said:

All that the end point manufacturers have to do is start implementing SFP+ and any mythical issues are just solved.

 

I've been waiting for this to happen...

 

You are still left with the higher level protocol things though.

 

[Miska]

30 minutes ago, plissken said:

Left with those even if doing dial up SLIPP

 

Yes, certainly. I sort of always wonder why people pay attention to network interface jitter things with something like NAA. Since as protocol it would work even over internet between continents...

 

But it is not the case with all protocols. Although it is more about jitter at other places than with the lowest level transport link. Like how well PTPv2 works and how the clock derivation from it is implemented, etc.

 

[Miska]

8 hours ago, jabbr said:

The fiber ethernet ensures that no electrical noise can cross the network, so use a high powered server without concern and an electrically quiet NAA and voila the music comes out. 

 

Yes, certainly, but this isolation doesn't have anything to do with ethernet clocking jitter... Network timings are not critical to NAA, since there is no clock being transferred and NAA doesn't run any clocks. Only critical clock is DAC's sample clock.

 

So technically it doesn't have to be Ethernet. The data transport could as well be a 4G or 5G mobile network. WiFi is also working fine for me, up to 8 channels of DSD256. It is also actually practical if you want to access something like RAVENNA over WiFi, it can act as a bridge from WiFi to Ethernet for RAVENNA case.

 

[Miska]

That's why I said things depend on high level protocol too. On AirPlay the receiver (AirPlay device) reconstructs the sample clock from the inbound RTP packet timing. Which this totally horrible approach.

 

But there are reasons for difference approaches. The main thing here is whether you want to have synchronized multi-room playback (or otherwise multi-endpoint) where multiple network endpoints stay in sample-"accurate" sync. This means all DACs cannot own the clock or they will drift more or less eventually. For this reason NAA doesn't support this functionality.

 

[Miska]

1 hour ago, R1200CL said:

It seems there is an agreement (silenced members included) that a 10GB network with fiber SFP+ cage will be almost an equal solution to what the etherRegen does.

 

But so far it’s only possible to build computers with 10GB fiber interface. So until SPF+ is the preferred standard for streaming.....

 

Or maybe use WiFi? You certainly get full galvanic isolation! ;)

 

[Miska]

9 hours ago, R1200CL said:

What is your advice when it comes to flow control ?

I think this is a way to avoid  a buffer fill up, so put on should on should “slow” down the amount of data being sent. 

 

Especially if you have any small NAA devices or similar, you will certainly want to have it (802.3x) enabled. It can help a lot even with regular desktop computers.

 

[Miska]

5 hours ago, ASRMichael said:

I suggest you turn off QOS, & any other service you don’t need. Use VLAN for audio & good LPS. I found the more services you use just increases CPU load & affects SQ. lower the better. 

 

HQPlayer uses QoS, so if you use HQPlayer with NAA, you need at least:

802.3x Flow Control

802.1p COS / QoS

802.3az EEE (sorta optional, although you'd want it to minimize noise)

 

And on Cisco switches you need to set multicast to "Forward Unregistered", example like this:

 

And use IPv6 if possible instead of IPv4.

 

[Miska]

3 hours ago, ASRMichael said:

What about broadcasting? Less traffic the better? VLAN’s?

 

IPv6 doesn't support broadcasts at all. And none of the proper protocols use broadcasts either. Multicast is the proper replacement.

 

I think only popular protocol left with broadcasts is SMB/CIFS file sharing originated from Windows.

 

[Miska]

4 hours ago, jabbr said:

If you have a good switch, which can support real switched bandwidth between ports, you don't need, nor would benefit from QoS in most home settings.

 

You benefit it already from OS level since each traffic class has it's priority queue, and the network packets are scheduled from these priority queues. Helps making sure your random large internet download doesn't affect music playback...

 

For example HQPlayer NAA and also RAVENNA use this.

 

See:

https://en.wikipedia.org/wiki/Differentiated_services

[Miska]

2 hours ago, ASRMichael said:

Might not slow down but will cause more activity, less being better offcourse! 

 

Less CPU activity at switch means more network activity. Smarter you can get the switch, less traffic like retransmissions you get on the network. For example use of flow control can drastrically reduce amount of network packet traffic because much less resends are needed because there's practically no packet loss due to packet buffer overflows.

 

[Miska]

1 hour ago, ASRMichael said:

Thanks. My ISP hasn’t rolled out IPv6 yet. Can you setup Local inky for IPv6 network? 

 

Yes, you can just setup local IPv6 addresses. For example for the fc00::/64 private subnet.