[c-nsp] Interface drops

[Chris Knipe]

Hi Alan,


> > Now, 14482944 of 548164331323 packets is a mere 0.002%... Hence - should
> > this be a cause of concern?
>
> well yes - that amount of drops leads to huge hit in network performance
> for eg TCP applications
>
> https://fasterdata.es.net/network-tuning/tcp-issues-explained/packet-loss/
>
>
Interesting reading and calculations there :-)  Thnx for the link...




> >
> > #sh int po7
> > Port-channel7 is up, line protocol is up (connected)
> >   Hardware is EtherChannel, address is 001c.b1e8.9627 (bia
> 001c.b1e8.9627)
> >   Members in this channel: Gi2/0/38 Gi2/0/39 Gi2/0/40
>
> 3 members? not a good number for Cisco etherchannel
>
> > Again, here we have a bit more, sitting at 4.592%
>
> ouch.
>
>
> whats downstream of these devices?  got flow-control?   if you have no QoS
> the byffer space on the platform should
> be enough for that amount of traffic MB/s- but what type of traffic is it
> being used by NFS - big packets?   have you enabled
> jumbo frames on the links?
>
>
Dell R450s (Broadcom NetXtreme II), NFSv4 (TCP) and SQL.  No flow control
and no Jumbos.  I've read some very mixed results in terms of jumbo frames
so it's not enabled.  The other reason is that it requires an reboot of the
entire switch stack (thanks Cisco) to enable, which is something that
simple can not be done any time soon.

Various NFS / OS tweaks has been tried already, incl. UDP vs. TCP, and NFS3
fs NFS4.  Even tested SMB3 just for the hell of it, a SCP is slow too (slow
being FAR from 1Gbps, nevermind 3Gbps in the case of multiple TCP
connections)




> > I did bench the servers, and locally on the servers (without using the
> > network), I do get SIGNIFICANTLY better performance (like 10 x
> increase)...
>
> packet loss can cause this massive degradation - see above link
>
>
And this is what I find EXTREMELY annoying.  In terms of ICMP, not one
single dropped packet.  Perhaps I should try with bigger packets - will
check that out.



-- 

Regards,
Chris Knipe