Best information I could find the device has aggregate 5MB of buffers, 5MB/10Gbps is 4ms. But any other port using buffers is going to compete for those.
If you just have 1 ingress port and 1 egress port and they are same rate, no buffering should be needed. But maybe you have lot of 1GE ingresses? Unfortunately I've not ran this platform so I cannot offer platform specific advice. Maybe time for CTAC case. On 18 March 2018 at 23:02, Sergey S. <[email protected]> wrote: > Hi, Saku! > > There is only one more 10G port (ingress) in the same VLAN. > > > > > On 03/18/2018 11:47 AM, Saku Ytti wrote: >> >> Hey Sergey, >> >> >> Your intuition seems right. My initial guess as well would be that >> these are consequence of microbursts. So any effort to understand >> buffer utilisation is needed to exclude or prove that. >> >> >> Do you have ingress ports operating at 100GE or do you have multiple >> 10GE ingress ports competing for that 10GE egress port? >> >> >> On 18 March 2018 at 00:52, Sergey S. <[email protected]> wrote: >>> >>> Hi, >>> >>> I'm running NXOS 7.0(3)I5(2) on N3K-C3064PQ-10GE. >>> >>> Output discards counter is gradually incrementing on one 10G port despite >>> it >>> not being oversubscribed in those moments of time. >>> >>> If I look at "sh hardware internal interface asic counters module 1" >>> these >>> drops are displayed as QOS Tx Drops. >>> >>> I've tried setting up "hardware profile buffer info port-threshold" even >>> to >>> the lowest values (e. g., 1%) to figure out if there is a problem with >>> QoS >>> queues, however there isn't any information in "sh hardware internal >>> buffer >>> info pkt-stats port-log" (most likely I don't understand the concept of >>> buffer monitoring and/or it's totally unrelated to my issue). >>> >>> There isn't any special QoS configuration on the switch. It is just as >>> follows: >>> >>> policy-map type network-qos jumbo >>> class type network-qos class-default >>> mtu 9216 >>> system qos >>> service-policy type network-qos jumbo >>> >>> Not sure whether this gives some clue, anyway, the port in the subject is >>> connected to a large broadcast domain (Internet Exchange Point). >>> >>> Thank you for any hint! >>> >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> > -- ++ytti _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
