Optical Network Configurations

[The Computer Audiophile]

2 minutes ago, plissken said:

 

Chris, your reply is pretty much the point that I, Barrows, Jabbr, have been trying to make. If it's a motion camera they even have something called a frame buffer. Some really high end cameras can store like 1,000,000 per second.

I hear ya. 

 

I think buffers are often discussed without anyone knowing how they are implemented in audio components. Some people think an entire track is stored in a buffer that stores it as data without a clock attached or that in the buffer it's reclocked etc... This just isn't the case in many audio components. 

 

Anyway, I don't want to derail the discussion.

[The Computer Audiophile]

1 minute ago, charlesphoto said:

I got one of those Mikrotik switches once out of curiosity and I can assure you a 1gb SFP works in it. The switch didn't do anything for me so I returned it up the river. 

I had high hopes for the Mikrotik I purchased a while ago, but has the same experience as you. 
 

Happy they work great for others though. They are a bargain. 

[The Computer Audiophile]

1 hour ago, jabbr said:

My objection was with the statement "ALL SFP+ modules will work in SFP cages" 

Is it really necessary to get all whipped up over that? Nobody would suggest ALL and mean ALL. The there’s a product somewhere that won’t work. Nobody reads that and really thinks ALL means ALL ALL the time. 
 

If we need to caveat ALL our speech at ALL times, count me out. 

[The Computer Audiophile]

4 minutes ago, jabbr said:

 

I think that there is too much concern about trying to outthink the network hardware designers regarding jitter. 

 

Every compliant 10Gbe switch has lower jitter than makes any shred of difference in an Ethernet network. You are best off using any 10Gbe switch with 2 RJ-45 outputs. One to each DAC. The Mikrotik works. Its cheap. Use the Mikrotik 10Gbe RJ-45 SFP+ modules or use the 1Gbe RJ-45 SFP modules. You aren't bridging, you are switching. The fitlet2 is a 1Gbe device and there is no expectation that it meets 10Gbe jitter standards... if that even matters.

Does the fitlet2 with SFP+ board do 10GbE?

[The Computer Audiophile]

16 minutes ago, R1200CL said:

A total overkill if you ask me

Come on, since when is that an issue :~)

[The Computer Audiophile]

3 minutes ago, Bertel said:

... and here's a little diagram which hopefully illustrates better what the setup I'm describing above would look like:

Should be fine. 
 

I wish they were called SFP25 rather than 28. Would make more sense given the 25 Gbps speed. 

[The Computer Audiophile]

3 hours ago, plissken said:

 

Modern, and most default, switching is called Store and Forward. It stores the incoming frame and regenerates the frame from scratch and then forwards it on.

 

Jitter as far as Layer 1 only has to do with the transmitter and receiver that are talking and only for that one point to point link.

 

For all you know your HD stream from Tidal, Amazon, or Apple, could be going over multiple different connection types all with their own point to point signal integrity requirements. None of that matters to us because we receive the data Asynch. It's a bit bandwidth intensive and latency insensitive.

 

I teach the CCNA, I'm a dual CCNP and ACEP. I do VOIP, I do medical emergency paging systems, I do casino Sec_Cam's, I do broadcast so live A/V and multi-cast IGMP/PIM are all in my wheelhouse. I just worked with a casino on a 300 camera project that cover all the tables in addition to causeways, entrances, cashiers etc...

 

I love facts :~)

 

Thanks for contributing.

 

It's amazing that music from Qobuz can start playing on my system in less than one second, given how it traverses the internet and many switches to get here. Gotta love it. 

[The Computer Audiophile]

4 minutes ago, plissken said:

 

I've yet to see any switch from any big iron vendor have an external clock input. Doesn't matter if it's Cisco, Juniper, Arista, HPE Aruba, Extreme, Huawei, Brocade etc...

I believe they use switches with external clocks at CERN. 
 

https://white-rabbit.web.cern.ch

[The Computer Audiophile]

Just now, plissken said:

 

You have a CDW or Synnex SKU # for this commercial offering?

I talked to a company selling the switches. I got on to other things and need to get back to them. 
 

You should see the spreadsheets when using these switches :~)

[The Computer Audiophile]

https://sevensols.com/wr-switch-low_jitter/
 

[The Computer Audiophile]

5 minutes ago, jabbr said:

For example the Ravenna protocol / RTP

Like here, where my Merging Anubis was the PTP Master

 

 

[The Computer Audiophile]

You can buy the White Rabbit switch but you have to work through a company the hard way. No add to cart, consumer friendly sales. 

[The Computer Audiophile]

1 hour ago, plissken said:

"Backhaul" is another term for the management vlan that they send any SA, SE, stats, beacon, and other types of traffic. It carries no data traffic. Can be totally L2 frames and most likely is.

 

That's not how I've traditionally seen the term used for WiFi home networks. I'm not saying your incorrect, but I mostly see the term backhaul used when discussing a data path from the AP to the rest of the network and why higher bandwidth or wired Ethernet backhauls are recommended. 

[The Computer Audiophile]

9 minutes ago, Superdad said:

I was not aware that CompuLab had an option for an SFP cage on the Fitlet2. Does not show in the specs or photos and I don’t see a FACET card for it with that option.  Can you provide a link?

Thanks.

https://fit-iot.com/web/product/fc-opln-facet-card-optical-lan/

[The Computer Audiophile]

21 minutes ago, plissken said:

 

I've installed THOUSANDS of 10Gbe and up interfaces and yet to enable flow control to get a link up/up.

 

I'm standing pat with Cisco on this:

 

Flow control is a last resort when you have a vendor that isn't managing traffic up layer. It's a ham-fisted one size fits all solution.

 

Take this case in point: You have a device that serves a few functions including VoiP which would also include E911. You have another app on that device that is a piece of shit app and it doesn't manage it's own data flows. It saturates a link and the only way to deal with the congestion is to enable some ancient, dumb, mechanism on the switch to force the Tx'ing NIC to back the fuck off.

 

Now lets say you need to make an E911 call but you can't get DSCP 24 call control traffic to get you a dial tone because flow control is busy backing off the NIC because of some other poorly thought out application.

 

 

Let's just use real world audio examples here. We have many very low power audio endpoints that will get overrun if even a 1Gbe server sends them data at full speed. It seems like flow control is the best option in this scenario. 

 

 

[The Computer Audiophile]

Just now, plissken said:

 

From a Cisco blog in 2015:

 

The general idea is to let the flow control be managed higher up the stack in the form of congestion control. This can be done by applications, and honestly, should be done by the applications as hardware flow control is not application aware

Isn't that just an opinion on what Cisco prefers? If some of us want an audio endpoint to do as little as possible, it seems like relying on external hardware to be the traffic cop is a good thing. 

[The Computer Audiophile]

3 minutes ago, plissken said:

 

I only work with a bunch of CCIE's, Python Devs, etc.... That's just their opinion too. You place your bets and make your purchases. All I know is I have no flow control enabled for my Pi4 wireless streamers running Ropieee XL and even with 24/192 PCM zero issues and checking PTRG shows 0% packet loss and 0% re-transmits on my lowly $56 TP-Link AP's, over my $60 Netgear GSM 7352v2 ebay switch with my $300 Dell R620 server with 10GBE Fiber that also run's pFSense since it's a 4 port NIC in the server (two fiber, two copper).

 

All network gear for the cost of one slow, un-managed, hot, zero efficacy, 6 port switch. *$528 actually. So less than.

 

 

Again, we should stick in the real world of audio devices. 

 

I have low power audio endpoints that choke with very high data rates from a server. 

 

If I use a crappy network with $56 TP Link APs, that will cause enough slow down to make the endpoints work just fine. Wireless always makes it work because it's slow and has higher latency. 

 

When I connect everything wired without flow control I break it. Enable flow control, fix it. 

 

I'm not talking about any "audio" switch, only audio endpoints that do nothing but audio. CCIEs, Python devs, should really look at specific use cases before making statements. Eat sleep and breathe this stuff for a while, then make an educated statement.

[The Computer Audiophile]

3 minutes ago, plissken said:

 

This^^. Just a few times in the past I've been contacted by PM to help. My suggestion in those instances was to simply return the oR.  Didn't matter what switch vendor we ended up using it was never going to work properly.

 

 

Two very different devices. One has a max network capability of 400Mbps. 

[The Computer Audiophile]

5 minutes ago, plissken said:

 

Chris, I built my first set of speakers, Karlson 1/4 wave folded horns in 1987.

 

CCIE's and Devs would look at solutions and when they see that the only congestion management available on a particular piece of gear is flow control they would keep on looking.  Is that specific use case enough?

 

My crappy $60 switch with multiple $56 1350AC AP's that I get 38MB/s over with no need of technologies from 1994 to make operate? I'll take that all day long. I'll let our relative networking and audio design and engineering abilities speak for themselves.

 

You're waving your hands. This has zero to do with what you built in 1987. I was in 5th grade and watched the Twins win the World Series that year. I'll never forget it :~)

 

Crappy stuff will make low power endpoints work. I've done this time and time again in my testing. Using good stuff is better and is why Roon initially implemented it's own solution to the issue. Roon used to overwhelm low powered endpoints. They connected to my server, ran Wireshark for a while, and decided to change their software so this wouldn't happen. 

 

Others, rely on flow control. An audio server and an audio endpoint can rely on flow control perfectly fine. They only send audio. No E911 calls are going out. 

 

Generalized statements without in the trenches experience with these audio devices aren't the best. I know your network chops. I understand what you're saying. I'm saying that I have experience with the actual devices being used and have used both solutions. 

[The Computer Audiophile]

1 minute ago, plissken said:

 

Well I was just helping those members, and I quote, "should really look at specific use cases ".

 

We did and determined better, more cost effective, solutions that now work.

 

I have no issues with your preferences. The two devices are just very different. It's like my LattePanda Alpha 864S. It's a cool computer. It's far from a purpose built Rendu. Whatever people want to use is cool with me. 

 

If I use flow control, I can get any audio endpoint to work. I don't have to really on a general purpose computer. 

[The Computer Audiophile]

Just now, plissken said:

LOL. You are missing the forest for the tree's.

 

This goes right back to my quote from the Cisco blog. They finally did what they should have done in the first place and implemented congestion control in their own software stack.

 

Roon was saturating end points because their design was broken. Not the endpoints. 

 

It's all a matter of how you look at it. The end result is identical. 

 

If I can offload congestion control to switch hardware, and use any device I wish, that's a win for me. I'm only send audio. All traffic on that interface can be held up. 

[The Computer Audiophile]

Just now, plissken said:

 

You personally have PM'd more than once to actually hop on the phone and remote into a computer to help a member. So why you are here insinuating that I have no experience directly with the devices we are speaking about baffles me.

 

 

Yes, and you were really helpful.

 

You're experience is very limited. You've seen messed up networks with issues. By experience, I'm talking about having several devices on your network, changing configs, running tests, changing configs, running more tests, etc... Also, understanding how the OS is built on the endpoints and what's undesirable and what makes sense to have another piece of hardware do etc...

 

I've done all this. 

[The Computer Audiophile]

To me it comes down to this:

 

1. Use flow control and use any endpoint I want.

 

or 

 

2. Don't use flow control and be limited to using only the endpoints that will work.

 

[The Computer Audiophile]

Just now, plissken said:

 

Unfortunately I can't operate as a consultant in that mode that is relied on for sound technical designs. I'm not about to start here either. We'll each have to call them as we see them.

Two very different worlds. 

 

When someone at home says I want to use endpoint ABC. It's awesome to say OK, let's just enable a feature on the switch that not only works, but was designed for this scenario, and you can use that endpoint. 

 

Your jag about flow control is strange to me. It isn't like I'm telling people to use unpatched Windows XP and hang it out on the internet. I'm saying that a fully supported feature on these switches that was designed to do exactly what we use it for, is a good thing. It gives end users more options. 

[The Computer Audiophile]

4 minutes ago, plissken said:

 

It's shouldn't. When a vendor is relying on tech from 1994 then I have to wonder what else they are incompetents at.

 

IPv4 is from 1981. Works very well.