Controlling the Flow with Flow Control…

[Bob Zelin]

Hi Marc,
we discover different problems as they arise. We never enabled flow control in the past – do you know why ? Because we didnt’ know. As we started dealing with clients that had big projects (hour long shows), we started to see systems stall 25 – 35 minutes into the project. Let me be more specific. You build one of these systems, and you test it. And you play back your 30 second, or 60 second spot, and you work, and you say “wow, this is GREAT, it actually works”. And then you get a client like W.B., and he is playing back a show that is 60 minutes long – it works great, and then stalls at 35 minutes, and he starts to yell at you. So you go “oh my God, what on earth is going on”. And you test, and test, and test, and everything seems ok. But it stops working. And you start discovering latency issues.

Flow control is one of these issues. The buffers clog and after a while, perfectly working systems are no longer perfectly working. So you enable flow control (on both the client and the switch) and the problems go away. These are the typical issues that people that DONT know say “oh – it means nothing” – but they have not suffered thru what I have suffered thru.

This is the difference between a generic managed switch and a switch that supports jumbo frames, dynamic link aggregation AND flow control (like the Small Tree ES4524D). You don’t appreciate these features until you have problems – then all of a sudden, you understand why you are paying $1200 for a switch instead of $400.

Bob Zelin

[Marc Bostrøm]

Hi Bob,

Thanks for your reply. You know… I don’t mind pushing the button, I just want to know why.
I know you, small-tree and others recommend turning flow control on. And I trust the information.
But, I just want to know why….

Earlier today I found this:
“An example of where Ethernet flow control might be used appropriately is at the edge of a network where Gigabit Ethernet attached servers are operating at less than wire speed, and the link only needs to be paused for a short time, typically measured in microseconds. The use of Pause frames to manage this situation may be appropriate under such circumstances.
Unfortunately, Ethernet flow control is commonly misunderstood. It is not intended to address lack of network capacity, or end-to-end network issues. Properly used, Ethernet flow control can be a useful tool to address short term overloads on a single link.”
by: Les Poltrack
Product Line Manager, Gigabit Ethernet Switching
Cisco Systems
https://www.networkworld.com/netresources/0913flow2.html
Be aware the article is 10 years old…

This makes sense, and explains it superficially…
I’ll keep on pushing the button…but I will search for more info on the subject.

Marc Bostrom
-| just another PRO FCP user |-

[Eric Hansen]

i don’t know if i can really add too much insight into what Flow Control IS. but when i received the 48 port Edgecore switch from Small Tree, the first thing they had me do was enable Flow Control. i think they now enable it on all switches they sell before shipping them out.

e

Eric Hansen, The Audio Visual Plumber – http://www.avplumber.com

[Dave Klee]

Hey Marc, I’m not really a networking guy, but here’s what I know about Ethernet flow control:

In a typical network, there are both data senders and data receivers — and, in a TCP network using full-duplex mode with flow control enabled, they listen to each other (kinda). The sender just keeps sending data as fast as it can — until it hears a “PAUSE” command. A PAUSE gets issued by a receiver that can’t keep up. Receivers can’t keep up for a variety of reasons from time to time; it could be that the receiver’s processor is overwhelmed or the receiver’s network connection had too much stuff coming in at one time and/or a buffer got full. Regardless, the receiver issues a PAUSE — telling the sender to wait for just a fraction of a second before sending additional data. That’s flow control. It all centers around those PAUSE commands.

And, while it’s built-in to the TCP protocol, it’s not always turned on or supported by everything on your network. The sender’s network adapter (Ethernet connection) needs to know how to listen for these PAUSE commands and briefly stop sending data. Receivers need to know how to issue these PAUSE commands, and the switch has to know how important these PAUSE commands are to pass along to the data senders.

Flow control does add just a touch of latency. Data senders and switches are, in a way, constantly listening for a PAUSE command rather than just blindly sending data as fast as they can. Before sending a file, there is, in a way, a brief check performed to make sure the receiver is ready to accept the file. And, if a PAUSE command is issued by a receiver, that’s where things can slow down — because the sender actually stops sending to that receiver for a very brief amount of time (we’re talking nanoseconds, literally).

I’ve heard rumors of networks mixed with gigabit (1Gbps) and fast-ethernet (100Mbps) devices getting bogged down by flow control because the slow receivers are constantly telling the data senders (often these are servers) to PAUSE. Similarly, let’s say ten computers with gigabit connections all start sending a big file to a computer with a fast-ethernet connection at the same time. The slow receiver is repeatedly going to tell all those gigabit computers to PAUSE and wait for it to be ready to receive more information.

Anyway, for video-heavy Ethernet networks, flow control is generally pretty helpful. While it might add just a tiny, tiny, tiny fraction of latency, it makes sure that your receivers (clients, desktops and edit suites) aren’t overwhelmed by a sender (server) that’s trying to send stuff too fast. If the receiver wasn’t ready for the data, you might get dropped frames during video playback or worse — bad file copies or corrupted data. The reverse situation is also helpful when your clients or desktops are sending new data to the server (when capturing new video, for example). You want to make sure the data gets written correctly and the server isn’t already busy receiving data from lots of other computers.

However, there are times when flow control is not helpful on an Ethernet network — the most specific one I know of is an Xsan metadata network. In Xsan, a client (edit suite) requests a file over a separate, private Ethernet network that goes directly to the server, and the server returns the requested file to the client over Fibre-Channel. This private, metadata network only handles very small files — only these simple requests. Here, there’s almost no chance any device is overwhelmed by these tiny request files (even if a ton of them come in at the same time), and minimal latency is really your utmost concern. If there is ANY lag in the server receiving your file request, the file won’t be sent over Fibre-Channel by the time you need it. This all happens in tiny fractions of a second — and flow control, as helpful as it is, can get in the way by slowing these requests down just a tiny, tiny bit.

Aside from these specific cases, though, flow control makes your network smarter. It makes sure senders don’t push out data faster than it can be received and minimizes the chance that things get lost in the transfer. The price, in terms of latency, is so small that most people in most situations would never notice.

I hope at least some of that is new / accurate, and I hope everything’s working well on your end!

[Marc Bostrøm]

Hi Dave.

Thank you very much for your reply and explination. It clearede up a few things.
(Sorry for not getting back to you earlier…I have been offline the past few weeks.)

Cheers!

Marc Bostrom
-| just another PRO FCP user |-