(@Ramblin Tech) Jim, thank you for describing control plane policing, I'm "somewhat" conversant on that, but it's likely to be beneficial to other readers.
FYI, why I was surprised this being so regular, i.e. every 12th packet (which might not be totally true), because there are many possible variables that could impact this in a production environment.
For starters, look at the OP ping stats times, i.e.:
round-trip min/avg/max = 0.803/4.963/87.305 ms
Better than a 100x spread between min and max.
Whenever Cisco devices are processing ping requests, it seems to be processed in software (i.e. control plane) as a low priority task. So much so, Cisco provided RTR (now part of IP SLA), to timestamp arrival of a ping request, so that delay time, sitting on the responding Cisco device, can be mitigated to allow a much more accurate network RTT.
There might also be possible timing issues of how quickly a host transmits the ping requests. (I.e. does pinging program/process send each request back-to-back, or provide some inter ping request pause? [NB: I've noted, when using a long series of ping requests, utilization stats appears higher as you increase ping packet's size, so either there's some pause between ping requests or lower layer overhead isn't being counted.]) Sending host might be interleaving other network traffic for transmission, along with, along the path, the ping requests might be interleaved with other traffic from other hosts.
I.e., because of the above, it's a bit uncertain exactly when each ping request arrives to the host, which could, impact the policer's Tc usage computations.
Possibly, there are relevant considerations about exactly what the CoPP is doing (also possibly, platform specific). For example, is CoPP running an on-going policer timer or does it only start one with the first packet that triggers policing? This can impact how the actual traffic aligns with the policer's Tc boundaries. (NB: should be less of a factor the longer the series of packets is.)
(As example of the above, assume you send a train of packets, That consume just under 100% of two Tcs. If the Tc accounting starts with the first packets, the first Tc will be "over rate" and packets will be dropped. But if first packets arrives just a tad in from the beginning of the first Tc, and the last packet doesn't "overflow" the second Tc, then that packet train will not be impacted. [BTW, this is often why "default" traffic policers tend to provide an actual transmission rate than configured for.])
Also how does the policer account for packets that span a Tc boundary?
What exactly is the policer counting for Tc usage? I.e. packet's bits, frame's bits or actual wire consumption (the latter accounting for Ethernet preamble and SFD). (Oh, also take note how OP reports a 0.4% lost for 56 byte packets, but stats for 1560 byte packets show a 7.9% drop rate. Why the greater than 10x loss rate disparity? So, possibly, some of the possible variables I mention, do make a difference.)
The above issues, I suspect, might cause some "drift" in whether it's always the 12th packet that gets dropped. (Oh, and as to the importance of some of these considerations, consider why some Cisco platforms provide more "advanced" bandwidth consumption algorithms, see, for example, Cisco's deficient round robin queuing variants vs. variants that don't do similar.)
So, in summary, except perhaps in a lab, I would have expected some variance in every X numbered packet being dropped, but it's possible the issues, above, might also have less impact on the larger ping packets being used (another possible issue, are packets being fragmented sent as size 1560? [as DF is set in OP, we might assume they are not, but as DF can be ignored, is it?]) or "every" isn't truly always every.
Regardless, to OP, @balaji.bandi identified the issue. But, whenever there's "issues" with pinging, (especially) Cisco network devices arise, I often mention, it's my understanding, ping was intended mostly as a basic tool to determine if another host is "alive". I.e. unexpected results might not represent any "true" network or host issue.
