IPTV multicast dropping packets

[welisson]

Hi guys,I have been working with IPTV for one year, so, all switch involved in this topology are x460, in this network I have mpls and vr created, nonetheless the multicast traffic is going through a specific VR with pim enabled.Everything is working properly, where on the main switch I have 2x460 in stack and two 10g ports going to other switch and 6 gigabit port going to another x460, in both case I have LACP enabled.
So, the curious situation that sometimes I can see some channels get a little bit checkered for some seconds, once it means that some dropped packed happened, but it just happens over traffic that is going through gigabit ports.In order for trying to solve this issue, we changed the SFP, optical patch cords, added more giga ports, increase the buffer ports to 100%, and with these stuff we could improve the transmission but not eliminated it in definitive.what we could notice that, sometime is still being logged some drop packets in these gigabit interfaces, where is causing this bad experience.I have tried to do a lot of thing to finished this dropped packets off. I could decrease the number of this incidents but not eliminated.I've been thinking that it could be the cpu process when using a gigaport where these are shared with the main cpu, different of 10g modules where they have a specific module to process all over the traffic.
Would someone get the same experience using x460 (not G2)? how would you solve this issue?
Tks

[welisson]

Erik, tks.
So, in this case my matter is not being over 10Giga ports and so just 1gigabit ports.But about this article is quite interest to reading.
tks

[welisson]

I'm supposing it wouldn't work for me, cause my distance between this both switch both "SiteA(main+stack 2x460) and siteB(just x460)" is around 5km, and this cable there is a limitation at most 10m.

[Eric_Burke]

I read that but it sounded like you were still using SFP. It's possible (someone here may know for sure) that a DAC would work in a 1GB SFP port. I too thought the numbers were interesting. That's a huge difference when you're down in the nanosecond range!

[Eric_Burke]

Not sure if it would help (this is a bit out of left field). If the ports are SFP+, consider using a DAC (twinax) cable instead. My understanding is that the overhead on these ports is an order of magnitude less than fiber xcvr's. Not sure if that's possible in this series but might be worth a shot.

As a side note, here's the specs that make me suggest this. I'd (oddly enough) just read this yesterday and was surprised by the differences. ~~~~~~~~~~~~~~

Comparing Latency

The 10GBase-T PHY standard uses block coding to enable data to pass through the cable without error. The block encoding requires reading the data block into the transmitter PHY, running a mathematical function on the data, and sending the encoded data over the link. The opposite happens at the receiving end. The standard specifies 2.6 microseconds for the transmit-receive pair, and the size of the data block indicates that the wait time cannot be improved by approximately 2.0 microseconds per link. The SFP+ DAC cable uses simpler electronics without the need for code blocks. Typical latency is about 300 nanoseconds per link.



By comparison, we find that SFP+ DAC provides lower latency, but 10GBASE-T and SFP+ fiber cabling provides higher latency

[welisson]

Idk but I've been thinking that this switch is not being able to deal with this sort of traffic, with traffic mixed using gigabit interfaces.