Yes, if you like various ms pauses of your backbone then enable flow control.
I hope you don't run VoIP or have gamer customers! ;) On Nov 7, 2016 10:19 AM, "Judd Dare" <[email protected]> wrote: > Not an expert at this level of switching, but my understanding, as your > suggesting is to enable Flow Control on the ports, possibly more on the 1G > ports because they are the bottle neck. If the 10G port is receiving full > speed and passing on to a 1G port which can't pass fast enough, then the > buffers fill up instantly. > > If flow control is enabled, it will signal to the 10G port that the > buffers are full and things should pause while the 1G port catches up. > > I've read similar examples between Netonix and AirFibers. I forget which > devices needed the flow control enabled on the switch, but it seems like it > was the slower port, thus allowing the slow port to signal when their > buffers were full. > > I don't remember exactly which devices should have flow control enabled to > avoid the problems, but this sounds like one of those cases. > > Definitely interested in better understanding what to do here. > > On Mon, Nov 7, 2016 at 8:52 AM, Fred Goldstein <[email protected]> wrote: > >> On 11/7/2016 10:40 AM, Josh Reynolds wrote: >> >> Negative, layer2 flow control is an axe when you need a scalpel. Turn it >> off everywhere! >> >> Layer3 has automatic mechanisms to help handle bandwidth saturation, and >> packet loss is part of that process. Furthermore, proper ToS/DSCP queueing >> is equally important. >> >> >> Well, technically no, Layer 3 has NO mechanisms to deal with capacity. It >> was a known issue among the network working group members in 1973 and a >> known issue in 1974 when TCP v1 was written, but the team had turned over >> by 1978 when TCP/IPv4 came out, and that group forgot about it until 1986 >> when things fell apart. The temporary short-term not very good fix was in >> layer 4 (TCP Slow Start) and that doesn't even apply to all streaming, >> though many do cooperate. Of course it was "good enough", so 30 years later >> it is taken as gospel. TCP/IP is the *chabuduo *of protocol stacks. >> >> There could be issues with using flow control on the Ethernet port, but >> really flow control should have been part of every layer. Loss should >> generally be localized. >> >> On Nov 7, 2016 9:36 AM, "Judd Dare" <[email protected]> wrote: >> >>> So you're saying, make sure Flow Control is enabled on the ports? >>> >>> On Mon, Nov 7, 2016 at 8:22 AM, Josh Reynolds <[email protected]> >>> wrote: >>> >>>> Microbursts causing buffer drops on egress ports to non-10G capable >>>> destinations. The switch wants to send data at a rate faster than the 1G >>>> devices can take it in, so it has to buffer it's data on those ports. >>>> Eventually those buffers fill up, and it taildrops traffic. TCP flow >>>> control takes over and eventually slows the transfer rate by reducing >>>> window size. It doesn't matter if its only sending 100M of data, its the >>>> RATE that it is sending the data. >>>> >>>> On Nov 7, 2016 8:58 AM, "TJ Trout" <[email protected]> wrote: >>>> >>>>> I have a 10G switch that is switching everything of mine at my NOC, >>>>> including peers, router wan, router lan, uplink to tower, etc >>>>> >>>>> During peak traffic periods ~2gbps I'm seeing 1% packet loss and >>>>> throughput will drop to 0 for just a second and resume normal for a few >>>>> minutes before dropping back to zero for just a second. doesn't seem to be >>>>> affecting the wan side of my router which connects to peers through the >>>>> same switch. Doesn't happen during the day with low periods of traffic. >>>>> >>>>> I've enabled / disabled STP, Flow control. >>>>> >>>>> I believe I've isolated it to not be a single port, possibly have a >>>>> bad switch but that seems hard to believe... >>>>> >>>>> Port isn't flapping, getting small amounts of fcs errors on receive >>>>> and lots of length errors but i think those shouldn't be a problem? >>>>> >>>>> It's an IBM G8124 10G switch >>>>> >>>>> Ideas? >>>>> >>>>> _______________________________________________ >>>>> Wireless mailing list >>>>> [email protected] >>>>> http://lists.wispa.org/mailman/listinfo/wireless >>>>> >>>>> >>>> _______________________________________________ >>>> Wireless mailing list >>>> [email protected] >>>> http://lists.wispa.org/mailman/listinfo/wireless >>>> >>>> >>> >>> _______________________________________________ >>> Wireless mailing list >>> [email protected] >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> >> >> _______________________________________________ >> Wireless mailing >> [email protected]http://lists.wispa.org/mailman/listinfo/wireless >> >> >> >> -- >> Fred R. Goldstein k1io fred "at" interisle.net >> Interisle Consulting Group >> +1 617 795 2701 >> >> >> _______________________________________________ >> Wireless mailing list >> [email protected] >> http://lists.wispa.org/mailman/listinfo/wireless >> >> > > _______________________________________________ > Wireless mailing list > [email protected] > http://lists.wispa.org/mailman/listinfo/wireless > >
_______________________________________________ Wireless mailing list [email protected] http://lists.wispa.org/mailman/listinfo/wireless
