Optical Network Configurations

[plissken]

19 minutes ago, ericuco said:

Also, there has been no (zero) errors reported in either of the switches' SwOS error panels. So for now, flow control will continue to be left off under the theory that flow control adds some amount of additional processing required by the switches and the general rule is less processes is better (not sure if that applies here but that is my stance and I am sticking to it). 🤨

 

If a manufacturer says use Flow Control then I would use it no problem. But normally we expect application devs to come up with their own congestion avoidance as how data flows is typically application determinate.

 

If I had my way, and taking HQ player as an example since @Miska uses CS5 markings:

 

I would enable QoS to respect those markings and enable flow control as he's indicated. Alternatively what I would do is look at the end point and see what the manufacture is stating on it's network I/O and shape traffic accordingly. This could be as simple as a bandwidth statement.

[plissken]

27 minutes ago, Jud said:

 

For the benefit of the ignorant (me), since I have double runs of fiber for redundancy and I see a LAG  setting on the Mikrotik, what is LAG?

Lag is an acronym for link aggregate control. It's bundling two - eight physical connections and presenting it as one logical connection just in case you have one connection go down. When I had this work out for me it's typically when I've had an SFP module fail.

[plissken]

5 hours ago, Bertel said:

the ability to reject upstream jitter is in the design and build of a 10GbE switch, and the components used like clock etc., to achieve compliance with the specifications, not in transmitting at a rate of 10GbE or above, but I might have misunderstood this?

 

The real jitter rejection for our playback of audio applications happen past the network connection. Jitter is a timing variance that we have to worry about during playback. Since there is no timing data on the audio data that flows across your network jitter isn't a concern BECAUSE your audio data is bandwidth greedy and delay insensitive.

 

I want to give you some examples with this as our understanding: If jitter is a timing variance in the delivery of data or the clock sync variation then we have to capitulate to my example that unplugging the network cable during playback is the largest form of jitter that someone can introduce. I've yet to see anyone attempt to counter argue this point.

 

So:

 

Roon buffers/caches 10 seconds

Tidal will buffer/cache entire tracks

JRiver (which is what I use) will buffer up to 1GB. As a test a took a Rachmaninoff album and concatenated the entire album in Audacity and converted to Flac for 480MB file. On my 10GBe network I was able to start play back. In the span of the time it took me to pull the network cable the entire album was in memory on my end point and played w/o any issues in it's entirety. 

 

If I'm able to play back with out the network cable what does any possible jitter that happened for the <2 seconds the entire album took to transfer have to do with it.

 

Point is the design effort needs to be placed on the selection of playback software and end points. I think 1Gbe Ethernet at ~112MB/s is more than ample. Consider your average 16/44.1 track is ~50-60MB.

 

See this video where I replied to Hans Beekhuyzen on this this point:

 

[plissken]

41 minutes ago, R1200CL said:

Those of us using a server/PC to endpoint configuration is using the network as a live transmission line for music. We can’t pull the cable, like you do. (As you probably can’t pull the USB cable in your case either). 

 

^This makes my point: Why implement a subpar system that is basically buffering every other second? What is the point to GBe or beyond for audio playback? You only need 100MB (11.25MB/s) connectivity at that point for any 2 channel PCM or DSD format right?

 

Of you can implement a system that capable of leveraging the network to it's advantage. And Johns eR white paper agrees with me.

 

41 minutes ago, R1200CL said:

So I’m saying you are not comparing things correctly. 

Somehow it goes “totally against your religion” what the EtherRegen is capable of doing. And you just can’t accept it.

 

I believe you still don't understand. You are still buffering if even for only a second. The other day I was watching something on YT. It stopped. I went into my SNMP server and found out that my cable modem stopped responding 45 seconds earlier. I have a rich and historical data-set for all my network gear.

 

 

Please do not assume I'm operating at some form of information deficit or lack of fundamental understanding wrt a boutique 'Audio Switch'.

 

Also this isn't religion. Its 17 years of implementing networking including live broadcast.

 

Here is what I can accept:

 

For $220 I picked up:

 

Cisco 2360 48GBe copper, 4 SPF+ ports $60

Solar Flare PCI-E 8X Gen two 10GBe NIC (two SFP+) for $20

Dell R620 NIC with two 10GBe SFP+ and two copper GBe for $19

FS.COM 10GBe SR LC transceivers for $18 per X 4

MM OM4 Cabling was another $40

Misc shipping...

 

Johns whitepaper also agrees with me here.

 

332MB/s on my Celeron 3150 JRiver system that could queue up an entire 16/44.1 in <2 seconds. I'm unsure how anyone can make these $500-$2000 switches a better SQ proposition than my $220 example.

 

I can also accept a get together were someone demonstrates this blind.

 

41 minutes ago, R1200CL said:

However I wouldn’t mind John posting those promised measurements in the Withe paper thread.

Still in your case, those measurements won’t matter.

Why do you thing the measurement paper has yet to materialize?

 

41 minutes ago, R1200CL said:

 

 

You only need to be concerned about possible jitter in your buffers. 

 

There is no jitter contained in a buffer. Buffer = data at rest.

[plissken]

2 hours ago, The Computer Audiophile said:

You know this is false. Try 1,536 kHz 24 bit. That roughly 73 Mbps. 

 

73Mbps is 9.125MB/s.

 

Or

 

100mbps > 73mbps.

[plissken]

2 hours ago, The Computer Audiophile said:

Audio doesn’t stream like a file copy. 

 

It sure can... Tidal does it. JRiver does it.

 

Why would I go with a vendor that has an algorithm that is popping data CONSTANTLY over a what are now becoming common place multi-rate interfaces of 1-5Gbe over old school CAT5e? Never mind I have 10GBe cards passively cooled that cost $20 plus transceiver costs.

 

I can cherry pick examples just as well as you can. But better yet here's a video on the matter. The point I'm making starts at 1:20. You can see the graphic eq active for an entire minute. With 0 connectivity.

 

 

 

 

 

[plissken]

1 hour ago, bobflood said:

True but likely 768 PCM will be sent in a 32 bit word container with the excess discarded at the receiving endpoint before being passed to the attached DAC at 24 bits except for those DACs that can actually accept a 32 bit word input in which case it will be passed direct with modification. 7 68 PCM is then a little over 49 Mbps (768,000x32x2). It is 1.536Mhz PCM that might not work on a 100 Mbps connection as it will be over 98 Mbps which doesn't leave much headroom for other stuff.

 

If the data rate is indeed 9.125MB/s there is enough overhead for maintenance traffic.

[plissken]

56 minutes ago, The Computer Audiophile said:

 

You’re ignoring the objective facts. 
 

 

 

Actually I'm not. At all. The point I'm making is that you can design a system, if you so wish, with attention paid to selection of products were you can realize as much wire speed as you wish. Often with less expense to esoteric products.

 

Now I do use a Pi 4 and Roipee but prior I was running a system with 10GBe fiber just as an exercise.

[plissken]

12 minutes ago, The Computer Audiophile said:

You claim JRiver plays music like a file copy, all at once. I showed you evidence of it doing the opposite. 

 

No claim about it. JRiver is super flexible and can indeed copy up to 1GB of data. I created a ~480MB file and in less then two seconds I could go network free and even scrub through the track.

 

I even have posted a video around AS here showing exactly that.

 

 

[plissken]

14 minutes ago, The Computer Audiophile said:

Who uses MB when talking network traffic?

 

It seems disingenuous to convert something using 98 out of 100 Mb into 9.125 MB, when nobody uses MB. 
 

Where on Earth is using 98% of one’s bandwidth advisable?

 

It's just a conversion.

 

You  said 73mbps. That's 9.125MB/s.

 

100 - 73 = 27. Or 27% available wire speed. The typical connection should be able to see 90mbps routinely. That's still 13% for over head and maintenance traffic. You wanted to go down this rabbit hole.

 

I can spin up iPerf and simulate this load all day long and show you things like Ping, DNS, Microsoft Discovery Protocol, LLDP, will all function. 

[plissken]

1 hour ago, bobflood said:

True but likely 768 PCM will be sent in a 32 bit word container with the excess discarded at the receiving endpoint before being passed to the attached DAC at 24 bits except for those DACs that can actually accept a 32 bit word input in which case it will be passed direct with modification. 7 68 PCM is then a little over 49 Mbps (768,000x32x2). It is 1.536Mhz PCM that might not work on a 100 Mbps connection as it will be over 98 Mbps which doesn't leave much headroom for other stuff.

 

How much content is natively available at 32/768. For the consumer formats that I know of, and I'm making a point about why you would devise a playback system that is constantly paging out of buffer, I simply stated if that's they case and you really believe that then you don't need anything other than 100Mbit networking.

 

I'll stand by that statement all day long.

 

As a practicality 1Gbe is the defacto standard with multi-rate from 1,2.5,5,10Gbe being readily obtainable.

 

If all you all really want to get into the weeds on this. I've no problem. My cheap ass TP-Link Omada AC1350's get me sub 2ms response round trip and ~38MB/s(304mbps or 304000kbps). So even 32/768 isn't a problem.

 

 

[plissken]

2 minutes ago, The Computer Audiophile said:

You’re way out of your league again. You know the network text book but not how the real world uses audio. Nothing to do with native rate content. It’s about people who upsample. 
 

Your use case of JRiver with USB DAC and loading files into memory is a clap trap. It has zero to do with using JRiver and a DLNA end point. I showed you facts, you refused to believe them. If you don’t believe screenshots, I’m not sure what else to tell you. 

 

I'm not out of my league at all. You didn't mention upsampling AT ALL in the initial post that I'm responding to.

 

Take what I said and disprove:

 

 

I said PCM or DSD format. Now you are bringing upsampling into this. I told you I'm more than capable of going to the mat on this. My advice is take your lumps and move on.

 

I could have quoted the actual 12.5MB/s but I left it at the more realistic 11.25.

[plissken]

6 minutes ago, The Computer Audiophile said:

Your arrogance knows no bounds. 
 

Show me a single network you’ve designed, where you were Ok with 13% overhead, rather than just swallow your pride and agree 1 Gbps was probably a better route. 

 

Oh christ Chris... Here we go:

 

 

You understand the term 'being facetious' correct?

 

I'd say your ego can't take a hammering so you resort to taking stuff entirely out of context. I did give you fair warning. You can either be above the belt or you can resort to what you are resorting to now.

 

[plissken]

14 minutes ago, The Computer Audiophile said:

Show me a single network you’ve designed, where you were Ok with 13% overhead,

 

I know that's not the case with any of my networks. But would you believe it if I told you, that according to one of your sponsors, there are about 3000 happy customers doing just this?

 

[plissken]

4 minutes ago, The Computer Audiophile said:

Last week it took Jussi to explain to you how applications work for you to back off on your assertion that flow control was only used in poor designs and people should move in to new solutions that don’t use it. 

 

I didn't back off an inch. I said I would use, and I do use, other products that don't have that ham-fisted approach. I also said if someone were using said products and they asked for my help in enabling flow control that I most certainly would.

 

If you want to get into this let me know. I can provide a master class to you on traffic policing, shaping, marking, and show you how I can design a network using using these audio endpoint devices with 0 flow control having to be turned on for the switch interface.

[plissken]

5 minutes ago, The Computer Audiophile said:

It just really rubs me the wrong way when you make statements that you may believe are true, but they need much more context and are often not the whole truth. 

 

What rubs me the wrong way:

 

1. You haven't negated one thing I've stated. Period.

2. You said 73mbps and I showed you we are only using 9.125MB/s out of a typically available 11.25MB/s connection and I can objectively prove, and by sticking to the facts, that it won't present a problem for audio playback. We have enough for various maintenance traffic. Now I highly recommend GBe and I don't recommend products that don't hit this spec.

3. You, by your own admission now, have thrown networking products that can leave you with only 13% gas in the tank under the bus.

 

Again I'm comfortable going to the mat.

[plissken]

5 minutes ago, jabbr said:

DSD 1024 requires 100 Mb bandwidth. Native. That without upsampling. Obviously not all music is DSD1024 but there are DACs which accept.

 

Thanks jabbr. This is kind of my point. If you are a DSD 1024 user than 1GBe it is. Period. How much content is there at this format though?

 

5 minutes ago, jabbr said:

Not sue why anyone would limit themselves to 100 Mbe these days.

 

I know of about 3000 people that do.

[plissken]

1 minute ago, The Computer Audiophile said:

Sure, 73 Mbps will work, but you're being disingenuous here because you seem to have no problem throwing flow control under the bus even though it does work. This isn't about what will work. Heck, AAC at 256 will work for many people. It's about being reasonable and seeing that there are many sides to issues and many ways to do things. 

 

I'm aware of many ways to do things. Some more preferable than others. I'm of the opinion of getting SOTA gear that maximizes the network it's riding on. Yes I do think FC is sub-optimal and in agreement that this should be handled by the application. No one died because of enabling flow control. I'm not sure why you are bringing this all up since it has nothing to do with what we are going back and forth over.

[plissken]

11 hours ago, Jud said:

Surely you're aware there are lots of people who do this in audio, whether Chris brought it up or not.

 

I'm not here to discuss the 1000 permutations of audio Jud. Chris said 73mbps. I don't care how you get there. Whether it be native format or upsampling, 73=73 unless you have some maths that I don't know about. I'm not a mind reader either.

 

If you are going to plant your goal post and try to make a point that you are wrong on just admit it and move on.

[plissken]

11 hours ago, Jud said:

I'm also not quite sure what you're arguing about. You seem at one and the same time to be saying 100Mbps is fine, to disdain 3000 people who say 100Mbps is fine, and to be saying more network overhead potential than 100Mbps can give you is desirable. Do you have a point, or do you just like to argue and talk about your network chops?

 

No I don't think 100Mbps is fine. I think is a step backwards. You must not have read my reply to @R1200CL Here you go.

 

And another thing I didn't start this current tit for tat. Chris did. I don't know if he was attempting to try and bring me down a peg or not but I'll let the data speak for itself. He didn't mention any SCR until we were well into it and it wasn't going his way. Flow control was also brought into this as a point of deflection.

 

Hopefully you all have worn yourselves out moving goal posts.

[plissken]

1 hour ago, Miska said:

At 100 Mbps the ratio between active and idle times is worse than at 1 Gbps. And 10 Gbps gives even better active/idle ratio.

 

 

Set policing on an interface and shove a bunch of un-shaped traffic over your CIR and watch your TCP resends sky rocket.

[plissken]

Here's a simple rule to remember:

 

If your transceiver has 850nm you use OM3 or greater (blue cabling)

 

If your transceiver has 1350nm you use OS2 yellow cabling.

 

You also have to make sure the cable is cross over and not straight through. There's a reason the ends are color coded.

[plissken]

7 minutes ago, hlkaye said:

Dumb question.

The OS2 cable I have has yellow end (labelled 2) on left and white (labelled 2) on right on both ends of the cable. Should one end be reversed, I.e. white (1) on left and yellow (2) on right? 

 

Yes. Cables come either straight through or cross over. I had a campus turn up where the cabling vendor ordered 400 straight through. What a PITA that was to snap of the retaining bracket and flip the end.

[plissken]

27 minutes ago, hlkaye said:

Thanks Plissken. Can I pull off the end and reverse it myself or how do I order a patch of OS2 that is crossed over?

 

As I  said I am a novice

 

You most certainly can. I just remove the retention tab and throw it away normally.