"Can you explain what I'm looking at in this output . . ."
Sure, it tell us two major things.
First it shows what the ToS/DSCP (packets) and CoS (frame) marking counts are for both port ingress and egress.
Second it shows how many packets/frames were enqueued or dropped within each of the 4 egress queues broken down by groups of packets/frames targeted for a certain drop level treatment in each queue.
First thing to understand with 3750s, again, with QoS enabled, they support 4 egress queues, per port, but sometimes they are referenced as queues 0 to 3 and sometimes as queues 1 to 4 (so, you need to understand which numbering system is being used to insure you're dealing with the same actual queue).
Second, understanding classification into egress queue drop groups, at first (and possible a bit longer), can be confusing to understand.
For example, starting with a ToS/DSCP value of zero/BE, we can "map" such marked packets into our choice of one of the four egress queues (again either numbered 0..3 or 1..4) (oh, and again, remember there are both device defaults, and AutoQoS defaults - but you can override either).
Second, also again, with each egress queue, you "map" such marked packets into a particular drop group, which are distinguished by "threshold1, threshold2 or threshold3". Incidentally threshold1 and threshold2 cannot be larger than threshold3. I.e. thresholds 1 and 2, I recall, need to be <= threshold3, but don't recall whether threshold1 must be <= than threshold2. Usually device defaults, AutoQoS defaults, and Cisco recommendations, have threshold 1 less than 2 which is also less than 3.
So, when a packet marked with ToS/DSCP zero/BE egresses a port, it's counted in the DSCP outgoing bucket for DSCP zero.
If there was port congestion, and the forgoing packet had to be QoS enqueued, it's also counted in the enqueued stats, under the queue and corresponding threshold it was "mapped" to.
If the mapped queue/threshold was full, then the packet/frame is dropped, and that too is counted under the corresponding "mapped" queue/threshold.
The stat, often, of most interest is for drops, and what queue/threshold, in particular, is dropping packets. (BTW, unless only one specific DSCP or CoS is mapped to a specific queue/threshold, we cannot determine which specifically marked packets were dropped.)
However, enqueued stats do reveal congestion, but they don't directly indicate how "bad" the congestion was. (Like does the queue usually contain only a couple of packets/frames or hundreds of packets/frames.)
Also BTW, an interface dropping pings requests/replies (remember, problem can be in either or both directions) will show as missing unsuccessful pings, but an "extensively" delayed ping request/reply, a time-out, I believe, also shows as a unsuccessful ping.
I think it unlikely a packet/frame would be enqueued long enough to trip a "drop" but then again, in your OP we see:
"Success rate is 98 percent (1975/2000), round-trip min/avg/max = 1/6/67 ms"
Your overall average is 6 ms, but minimal time were 1 ms. Further, your maximum (not yet considered a time-out) was 67 ms!
A couple of things you might try, to see if there's a major difference in your ping stats:
Try ping using a max size (i.e. 64k) packet. This will often increase the chances of a "lost" or delayed ping.
And/or ping using a different DSCP value, for example, using minimal sized packets marked with DSCP EF (decimal value 46, or ToS decimal value 184).
Again, unlikely a queued packet would be queued long enough, without being dropped, to time-out, but in somewhere along the path, Ethernet basic flow-control is active, that might push the delay boundary. It can also cause sporadic "slowness". Generally, unless you're using DCB kind of Ethernet flow control - it should be disabled.
