Re: [WISPA] Wichita KS

[Zach Mann]

I just forwarded to my contact in Wichita.  Will let you know what he comes
back with.

-Zach

On Mon, Nov 7, 2016 at 1:52 PM, Mike Francis 
wrote:

> Can anyone service this location?
>
> 1855 Innovation Blvd Wichita Ks 67260
>
> Thank you,
> --
> John Michael Francis II
> JMF Solutions, Inc
> Wavefly - Internet Voip Cloud
> INC 5000 #2593
> CRN Fast Growth #105
> 251-517-5069
> http://jmfsolutions.net
> http://wavefly.com
>
> "People are unreasonable, illogical, and self-centered. Love them
> anyway. If you do good, people may accuse you of selfish motives. Do
> good anyway. If you are successful, you may win false friends and true
> enemies. Succeed anyway. The good you do today may be forgotten
> tomorrow. Do good anyway. Honesty and transparency make you vulnerable.
> Be honest and transparent anyway. What you spend years building may be
> destroyed overnight. Build anyway. People who really want help may
> attack you if you help them. Help them anyway. Give the world the best
> you have and you may get hurt. Give the world your best anyway." By:
> Mother Teresa
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Do you recognize this tower?

[Marco Coelho]

tower leg part numbers are marked:  8807379-1 880380-1 880382-1 881569-1
NO pics yet

On Mon, Nov 7, 2016 at 2:47 PM, Josh Luthman 
wrote:

> No pictures
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
> On Mon, Nov 7, 2016 at 3:46 PM, Marco Coelho  wrote:
>
>>
>> I'm looking at a tower (self supporter) which mechanically looks like one
>> of my Rohn SSV towers.  There is not a tower part number plate on the
>> tower, but the legs are marked:
>>
>> 880379-1
>> 880380-1
>> 880381-1
>> 880382-1
>> 881569-1
>>
>> Ideas?
>>
>>
>>
>> --
>> Marco C. Coelho
>> Argon Technologies Inc.
>> POB 875
>> Greenville, TX 75403-0875
>> 903-455-5036
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>


-- 
Marco C. Coelho
Argon Technologies Inc.
POB 875
Greenville, TX 75403-0875
903-455-5036
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Do you recognize this tower?

[Josh Luthman]

No pictures


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Mon, Nov 7, 2016 at 3:46 PM, Marco Coelho  wrote:

>
> I'm looking at a tower (self supporter) which mechanically looks like one
> of my Rohn SSV towers.  There is not a tower part number plate on the
> tower, but the legs are marked:
>
> 880379-1
> 880380-1
> 880381-1
> 880382-1
> 881569-1
>
> Ideas?
>
>
>
> --
> Marco C. Coelho
> Argon Technologies Inc.
> POB 875
> Greenville, TX 75403-0875
> 903-455-5036
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

[WISPA] Do you recognize this tower?

[Marco Coelho]

I'm looking at a tower (self supporter) which mechanically looks like one
of my Rohn SSV towers.  There is not a tower part number plate on the
tower, but the legs are marked:

880379-1
880380-1
880381-1
880382-1
881569-1

Ideas?



-- 
Marco C. Coelho
Argon Technologies Inc.
POB 875
Greenville, TX 75403-0875
903-455-5036
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

[WISPA] Wichita KS

[Mike Francis]

Can anyone service this location?

1855 Innovation Blvd Wichita Ks 67260

Thank you,
-- 
John Michael Francis II
JMF Solutions, Inc
Wavefly - Internet Voip Cloud
INC 5000 #2593
CRN Fast Growth #105
251-517-5069
http://jmfsolutions.net
http://wavefly.com

"People are unreasonable, illogical, and self-centered. Love them 
anyway. If you do good, people may accuse you of selfish motives. Do 
good anyway. If you are successful, you may win false friends and true 
enemies. Succeed anyway. The good you do today may be forgotten 
tomorrow. Do good anyway. Honesty and transparency make you vulnerable. 
Be honest and transparent anyway. What you spend years building may be 
destroyed overnight. Build anyway. People who really want help may 
attack you if you help them. Help them anyway. Give the world the best 
you have and you may get hurt. Give the world your best anyway." By: 
Mother Teresa
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

So, a bit of back story on this...

It's kind of "my fault" that the AF line has flow control :P

At Performant Networks we decided to do some RFC2544 testing of AirFibers
(with Chuck watching via a Sykpe call). Turns out they didn't like that too
much. Once they added flow control, there was much less packet loss, and
higher throughput.

That said, that is a very demanding test. We fully saturated the radio link
as much as physically possible until they fell over. These are 750Mbps
radios (AF24) with very small buffers to keep latency low - which means
when trying to push a gig of the smallest possible packets through the
radio, you are absolutely going to have drops.

On Nov 7, 2016 12:36 PM, "Judd Dare"  wrote:

> Just to follow up on this.  I'm working on a network at the moment,
> diagnosing port issues on the Netonix. We had some bad crimps (I'm 6000
> miles away) and we've been seeing some CRC errors and intermittent
> connection loss on AF5x links.  Pretty sure it's the ethernet connections
> and finally getting 1G connections instead of 100M like we've had the last
> few weeks.
>
> Anyway, while in the Netonix, I notice the UBNT 100M AP's are running at
> 100M with flow control negotiated by default.  The AF5x's are not flow
> control enabled and are running at GigE.  I won't claim this is optimal,
> because I still haven't fine tuned this network, work in progress.
>
> But there is a thread here where UBNT chimed in and said they suggest flow
> control on AF5x, etc.
>
> I think the need for flow control may vary by switch manufacturer and
> ethernet chipset as well as by implementation from the vendor.  So YMMV,
> try some FC and see what happens.
>
> https://community.ubnt.com/t5/airFiber/Flow-Control-is-Off/m-p/1157296
>
> On Mon, Nov 7, 2016 at 9:50 AM, Josh Reynolds 
> wrote:
>
>> In addition, imagine the following scenario:
>>
>> 8 port switch at a tower. Gigabit Ethernet port. 7 ports on the switch,
>> all have 100Mbps links to APs.
>>
>> Buffer architecture is a shared memory design, with say 4MB available.
>>
>> Do the math. The buffer on that switch is going to fill up very quickly,
>> increasing latency across the board with tons of retransmissions upstream
>> due to the lost data.
>>
>> Sadly, this is every switch in the WISP space!
>>
>> Switches are needed in this scenario that:
>> (A) Are managed
>> (B) have sufficient per port buffers
>> (C) are dscp / tos aware
>> [Optionally]
>> (D) support buffer monitoring via SNMP, including queue drops
>>
>> On Nov 7, 2016 10:39 AM, "Josh Reynolds"  wrote:
>>
>>> I would agree, but sadly WISP networks are full of 100Mbps links AND a
>>> ton of variable bandwidth ptp and ptmp links.
>>>
>>> You will have to buffer to have any kind of meaningful throughput,
>>> otherwise Bandwidth Delay Product calculations will drive your throughout
>>> into the dirt.
>>>
>>> Buffer BLOAT is bad. Buffering is not inherently bad, and is often
>>> necessary.
>>>
>>> On Nov 7, 2016 10:35 AM, "Fred Goldstein"  wrote:
>>>
 On 11/7/2016 11:05 AM, Josh Reynolds wrote:

 Sorry, correction layer 4. TCP slow start and window sizing.

 Allowing l2 to control your drops in a willy nilly fashion though is
 not a good idea... And random "pauses" on your backbone is also a poor 
 idea.

 The idea is to smooth out the flow end to end; it's the big bursts that
 cause trouble.

 I'm of the opinion that WISP networks likely need to move to deep
 buffer data center switch designs, simply because of the number of variable
 speed links.


 No, I prefer the opposite. Bufferbloat is bad! The math shows that you
 basically don't need a buffer bigger than 10 packets or so. But with QoS
 classmarking, you may need multiple buffers.

 On Nov 7, 2016 9:53 AM, "Fred Goldstein"  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 

Re: [WISPA] Switch causing packet loss?

[Judd Dare]

Just to follow up on this.  I'm working on a network at the moment,
diagnosing port issues on the Netonix. We had some bad crimps (I'm 6000
miles away) and we've been seeing some CRC errors and intermittent
connection loss on AF5x links.  Pretty sure it's the ethernet connections
and finally getting 1G connections instead of 100M like we've had the last
few weeks.

Anyway, while in the Netonix, I notice the UBNT 100M AP's are running at
100M with flow control negotiated by default.  The AF5x's are not flow
control enabled and are running at GigE.  I won't claim this is optimal,
because I still haven't fine tuned this network, work in progress.

But there is a thread here where UBNT chimed in and said they suggest flow
control on AF5x, etc.

I think the need for flow control may vary by switch manufacturer and
ethernet chipset as well as by implementation from the vendor.  So YMMV,
try some FC and see what happens.

https://community.ubnt.com/t5/airFiber/Flow-Control-is-Off/m-p/1157296

On Mon, Nov 7, 2016 at 9:50 AM, Josh Reynolds  wrote:

> In addition, imagine the following scenario:
>
> 8 port switch at a tower. Gigabit Ethernet port. 7 ports on the switch,
> all have 100Mbps links to APs.
>
> Buffer architecture is a shared memory design, with say 4MB available.
>
> Do the math. The buffer on that switch is going to fill up very quickly,
> increasing latency across the board with tons of retransmissions upstream
> due to the lost data.
>
> Sadly, this is every switch in the WISP space!
>
> Switches are needed in this scenario that:
> (A) Are managed
> (B) have sufficient per port buffers
> (C) are dscp / tos aware
> [Optionally]
> (D) support buffer monitoring via SNMP, including queue drops
>
> On Nov 7, 2016 10:39 AM, "Josh Reynolds"  wrote:
>
>> I would agree, but sadly WISP networks are full of 100Mbps links AND a
>> ton of variable bandwidth ptp and ptmp links.
>>
>> You will have to buffer to have any kind of meaningful throughput,
>> otherwise Bandwidth Delay Product calculations will drive your throughout
>> into the dirt.
>>
>> Buffer BLOAT is bad. Buffering is not inherently bad, and is often
>> necessary.
>>
>> On Nov 7, 2016 10:35 AM, "Fred Goldstein"  wrote:
>>
>>> On 11/7/2016 11:05 AM, Josh Reynolds wrote:
>>>
>>> Sorry, correction layer 4. TCP slow start and window sizing.
>>>
>>> Allowing l2 to control your drops in a willy nilly fashion though is not
>>> a good idea... And random "pauses" on your backbone is also a poor idea.
>>>
>>> The idea is to smooth out the flow end to end; it's the big bursts that
>>> cause trouble.
>>>
>>> I'm of the opinion that WISP networks likely need to move to deep buffer
>>> data center switch designs, simply because of the number of variable speed
>>> links.
>>>
>>>
>>> No, I prefer the opposite. Bufferbloat is bad! The math shows that you
>>> basically don't need a buffer bigger than 10 packets or so. But with QoS
>>> classmarking, you may need multiple buffers.
>>>
>>> On Nov 7, 2016 9:53 AM, "Fred Goldstein"  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"  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 
> 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

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

In addition, imagine the following scenario:

8 port switch at a tower. Gigabit Ethernet port. 7 ports on the switch, all
have 100Mbps links to APs.

Buffer architecture is a shared memory design, with say 4MB available.

Do the math. The buffer on that switch is going to fill up very quickly,
increasing latency across the board with tons of retransmissions upstream
due to the lost data.

Sadly, this is every switch in the WISP space!

Switches are needed in this scenario that:
(A) Are managed
(B) have sufficient per port buffers
(C) are dscp / tos aware
[Optionally]
(D) support buffer monitoring via SNMP, including queue drops

On Nov 7, 2016 10:39 AM, "Josh Reynolds"  wrote:

> I would agree, but sadly WISP networks are full of 100Mbps links AND a ton
> of variable bandwidth ptp and ptmp links.
>
> You will have to buffer to have any kind of meaningful throughput,
> otherwise Bandwidth Delay Product calculations will drive your throughout
> into the dirt.
>
> Buffer BLOAT is bad. Buffering is not inherently bad, and is often
> necessary.
>
> On Nov 7, 2016 10:35 AM, "Fred Goldstein"  wrote:
>
>> On 11/7/2016 11:05 AM, Josh Reynolds wrote:
>>
>> Sorry, correction layer 4. TCP slow start and window sizing.
>>
>> Allowing l2 to control your drops in a willy nilly fashion though is not
>> a good idea... And random "pauses" on your backbone is also a poor idea.
>>
>> The idea is to smooth out the flow end to end; it's the big bursts that
>> cause trouble.
>>
>> I'm of the opinion that WISP networks likely need to move to deep buffer
>> data center switch designs, simply because of the number of variable speed
>> links.
>>
>>
>> No, I prefer the opposite. Bufferbloat is bad! The math shows that you
>> basically don't need a buffer bigger than 10 packets or so. But with QoS
>> classmarking, you may need multiple buffers.
>>
>> On Nov 7, 2016 9:53 AM, "Fred Goldstein"  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"  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 
 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"  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
>> 

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

I would agree, but sadly WISP networks are full of 100Mbps links AND a ton
of variable bandwidth ptp and ptmp links.

You will have to buffer to have any kind of meaningful throughput,
otherwise Bandwidth Delay Product calculations will drive your throughout
into the dirt.

Buffer BLOAT is bad. Buffering is not inherently bad, and is often
necessary.

On Nov 7, 2016 10:35 AM, "Fred Goldstein"  wrote:

> On 11/7/2016 11:05 AM, Josh Reynolds wrote:
>
> Sorry, correction layer 4. TCP slow start and window sizing.
>
> Allowing l2 to control your drops in a willy nilly fashion though is not a
> good idea... And random "pauses" on your backbone is also a poor idea.
>
> The idea is to smooth out the flow end to end; it's the big bursts that
> cause trouble.
>
> I'm of the opinion that WISP networks likely need to move to deep buffer
> data center switch designs, simply because of the number of variable speed
> links.
>
>
> No, I prefer the opposite. Bufferbloat is bad! The math shows that you
> basically don't need a buffer bigger than 10 packets or so. But with QoS
> classmarking, you may need multiple buffers.
>
> On Nov 7, 2016 9:53 AM, "Fred Goldstein"  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"  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 
>>> 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"  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
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless


>>>
>>> ___
>>> Wireless mailing list
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>>
>>
>> ___
>> Wireless mailing 
>> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>>
>> --
>>  Fred R. Goldstein  k1iofred "at" interisle.net
>>  Interisle Consulting Group
>>  +1 617 795 2701
>>
>> ___ Wireless mailing list
>> Wireless@wispa.org 

Re: [WISPA] Switch causing packet loss?

[Fred Goldstein]

On 11/7/2016 11:05 AM, Josh Reynolds wrote:


Sorry, correction layer 4. TCP slow start and window sizing.

Allowing l2 to control your drops in a willy nilly fashion though is 
not a good idea... And random "pauses" on your backbone is also a poor 
idea.


The idea is to smooth out the flow end to end; it's the big bursts that 
cause trouble.


I'm of the opinion that WISP networks likely need to move to deep 
buffer data center switch designs, simply because of the number of 
variable speed links.





No, I prefer the opposite. Bufferbloat is bad! The math shows that you 
basically don't need a buffer bigger than 10 packets or so. But with QoS 
classmarking, you may need multiple buffers.


On Nov 7, 2016 9:53 AM, "Fred Goldstein" > 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" > 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
> 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" > 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
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless



___
Wireless mailing list
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless




___
Wireless mailing list
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless




___
Wireless mailing list
Wireless@wispa.org 

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

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"  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  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"  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 
>>> 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"  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
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
 ___
 Wireless mailing list
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless


>>>
>>> ___
>>> Wireless mailing list
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>>
>>
>> ___
>> Wireless mailing 
>> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>>
>> --
>>  Fred R. Goldstein  k1iofred "at" interisle.net
>>  Interisle Consulting Group
>>  +1 617 795 2701
>>
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> 

Re: [WISPA] Switch causing packet loss?

[Judd Dare]

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  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"  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 
>> 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"  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
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless


>>> ___
>>> Wireless mailing list
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>>
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>
> ___
> Wireless mailing 
> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>
>
>
> --
>  Fred R. Goldstein  k1iofred "at" interisle.net
>  Interisle Consulting Group
>  +1 617 795 2701
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

Sorry, correction layer 4. TCP slow start and window sizing.

Allowing l2 to control your drops in a willy nilly fashion though is not a
good idea... And random "pauses" on your backbone is also a poor idea.

I'm of the opinion that WISP networks likely need to move to deep buffer
data center switch designs, simply because of the number of variable speed
links.

On Nov 7, 2016 9:53 AM, "Fred Goldstein"  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"  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 
>> 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"  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
 Wireless@wispa.org
 http://lists.wispa.org/mailman/listinfo/wireless


>>> ___
>>> Wireless mailing list
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>>
>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>
> ___
> Wireless mailing 
> listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless
>
>
>
> --
>  Fred R. Goldstein  k1iofred "at" interisle.net
>  Interisle Consulting Group
>  +1 617 795 2701
>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Fred Goldstein]

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" > 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
> 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" > 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
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless



___
Wireless mailing list
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless




___
Wireless mailing list
Wireless@wispa.org 
http://lists.wispa.org/mailman/listinfo/wireless




___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless



--
 Fred R. Goldstein  k1iofred "at" interisle.net
 Interisle Consulting Group
 +1 617 795 2701

<>___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Adair Winter]

I've recently been looking at arista switches to do something similar.
Wonder how they would act?

On Nov 7, 2016 8:58 AM, "TJ Trout"  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
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

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.

On Nov 7, 2016 9:36 AM, "Judd Dare"  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 
> 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"  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
>>> Wireless@wispa.org
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>>
>>>
>> ___
>> Wireless mailing list
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Judd Dare]

So you're saying, make sure Flow Control is enabled on the ports?

On Mon, Nov 7, 2016 at 8:22 AM, Josh Reynolds  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"  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
>> Wireless@wispa.org
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>>
> ___
> Wireless mailing list
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

Re: [WISPA] Switch causing packet loss?

[Josh Reynolds]

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"  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
> Wireless@wispa.org
> http://lists.wispa.org/mailman/listinfo/wireless
>
>
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

[WISPA] Switch packet loss

[TJ Trout]

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?

Thanks
___
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless

[WISPA] Switch causing packet loss?

[TJ Trout]

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
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless