Mailing List Archive

C6800 Sup2T buffering ?
Dear experts
my customer have some multicast flows which are detected sometime with
peaks/latency.

They measure this latency based on protocol financial feed timestamp which
I'm not able to decode (I guess they use stuff like Corvil).

The path from the market datafeed source to the customer is:

Financial market --1Gb -- C6807 VSS SUP2T -- 10 G port-channel WAN --
C6807 VSS SUP2T -- 1 Gbs -- Arista 7150S --1 Gbs -- customer

They report 10-15 ms average latency and sometimes they detect 500-600 ms.

Following the path I do not find anything telling me there are spikes (I
have no drops) and also the customer states no packet loss is detected, but
we suspect buffering/queuing somewhere on C6807 or Arista 7150S.
Since Arista 7150S is low latency I suspect Cisco.

Some questions:
- what do you suggest to check here ? buffers ? qos ? other...
- what I can use to try to decode pcap taken on Arista switch to check if
the latency is really obtained checking protocol market timestamp ?

Thanks in advance for any hint or help.

Cheers
James
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: C6800 Sup2T buffering ? [ In reply to ]
On Wed, 20 May 2020 at 23:45, james list <jameslist72@gmail.com> wrote:

Hey,

> Dear experts
> my customer have some multicast flows which are detected sometime with
> peaks/latency.

> They report 10-15 ms average latency and sometimes they detect 500-600 ms.

I wouldn't put it past measuring error. Is 10-15ms expected? I.e. this
is like 1000km?

However based on just information available, perhaps flows timeout
periodically and hit the control-plane. I think SUP2T like PFC3 before
it punts all mcast, then programs flow in HW, then subsequently
hardware format it. If so, perhaps you can tune with multicast flow
timers.

> - what I can use to try to decode pcap taken on Arista switch to check if
> the latency is really obtained checking protocol market timestamp ?

Several samples, coffee and time.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: C6800 Sup2T buffering ? [ In reply to ]
Thanks ytti
indeed we've PFC4 here:

Mod Sub-Module Model Serial Hw
Status
---- --------------------------- ------------------ ----------- -------
-------
1 Distributed Forwarding Card WS-F6K-DFC4-E SALxxxx 1.2 Ok
2 Distributed Forwarding Card WS-F6K-DFC4-E SALxxx 1.2 Ok
3 Policy Feature Card 4 VS-F6K-PFC4 SALxxx 3.0 Ok
3 CPU Daughterboard VS-F6K-MSFC5 SALxxx 3.0 Ok
5 Distributed Forwarding Card WS-F6K-DFC4-A SALxxx 1.4 Ok

yes it's a long trip the path around 1k km

Cheers


Il giorno gio 21 mag 2020 alle ore 06:41 Saku Ytti <saku@ytti.fi> ha
scritto:

> On Wed, 20 May 2020 at 23:45, james list <jameslist72@gmail.com> wrote:
>
> Hey,
>
> > Dear experts
> > my customer have some multicast flows which are detected sometime with
> > peaks/latency.
>
> > They report 10-15 ms average latency and sometimes they detect 500-600
> ms.
>
> I wouldn't put it past measuring error. Is 10-15ms expected? I.e. this
> is like 1000km?
>
> However based on just information available, perhaps flows timeout
> periodically and hit the control-plane. I think SUP2T like PFC3 before
> it punts all mcast, then programs flow in HW, then subsequently
> hardware format it. If so, perhaps you can tune with multicast flow
> timers.
>
> > - what I can use to try to decode pcap taken on Arista switch to check if
> > the latency is really obtained checking protocol market timestamp ?
>
> Several samples, coffee and time.
>
> --
> ++ytti
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: C6800 Sup2T buffering ? [ In reply to ]
On Wed, 20 May 2020 at 21:45, james list <jameslist72@gmail.com> wrote:
>
> Dear experts
> my customer have some multicast flows which are detected sometime with
> peaks/latency.
>
> They measure this latency based on protocol financial feed timestamp which
> I'm not able to decode (I guess they use stuff like Corvil).
>
> The path from the market datafeed source to the customer is:
>
> Financial market --1Gb -- C6807 VSS SUP2T -- 10 G port-channel WAN --
> C6807 VSS SUP2T -- 1 Gbs -- Arista 7150S --1 Gbs -- customer
>
> They report 10-15 ms average latency and sometimes they detect 500-600 ms.
>
> Following the path I do not find anything telling me there are spikes (I
> have no drops) and also the customer states no packet loss is detected, but
> we suspect buffering/queuing somewhere on C6807 or Arista 7150S.
> Since Arista 7150S is low latency I suspect Cisco.
>
> Some questions:
> - what do you suggest to check here ? buffers ? qos ? other...
> - what I can use to try to decode pcap taken on Arista switch to check if
> the latency is really obtained checking protocol market timestamp ?

Hi James,

Perhaps a good start would be to narrow down where the increase in
latency is coming from.

I'd start by finding a way to packet capture as they come into the
first C6807 VSS SUP2T over the 1G link from the financial market, to
check that the problem is even within your control domain, and then
work backwards along the path from there, making the packet capture
along each link until I find the culprit of the latency spikes.

Cheers,
James.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/