Regarding your earlier question "if the interface was being overwhelmed and showing output drops, why would the txload and rxload not be maxed...", looking at your current stats, believe you misunderstand txload and rxload (many do).
An interface is either at 100% (actually transmitting/receiving a frame) or 0%. A tx or rx load of 50%, really means, over some measured time interval, 50% of that time interval's capacity was used. What it doesn't tell us, is how that capacity was used.
In your stats, your measured time interval is 5 minutes, so if txload was 128/255 (50%), was link busy the first two and a half minutes, the latter two and a half minutes, busy for alternating 5 seconds or some other combination?
Where drops and even a low load can go hand-in-hand, consider you have a gig ingress and a gig egress. The gig ingress goes 100% for 1 minute out of 5, i.e. a load (average) of 20%.
Next consider you have a 10g ingress and a gig egress. The 10g ingress goes 100% for 10 seconds. (BTW, if this is the only traffic during the five minutes, you have 10 seconds over 300 seconds, or [about] 3.3%.) What happens on egress?
Well, 10 seconds of 10g is 100 seconds of gig. The gig egress interface needs to buffer about 90 seconds of traffic. Assuming it can, its load average is 100 seconds over 300 seconds, or (about) 33%.
Now consider, egress interface's buffers could only contain about 60 seconds of the 10g's traffic. If so, its load average is 60 seconds over 300 seconds, 20%, and it dropped 40 seconds of the 100 seconds traffic!
I.e. load "only" 20%, but there are drops?! Yup!
Much of my example, isn't real world, except in principle. Default load average time interval, for Cisco, is really 5 minutes, but buffer capacity is measured in milliseconds.
In a burst congestion situation (BTW, you might research "micro burst") additional buffering often will reduce drops and increase throughput. However, in a sustained congestion situation, additional buffering doesn't help, and in some cases, can actually slow effective transfer rate. For sustained congestion, the solution is either provide more bandwidth, or, somehow, better regulate/control flow rates.
Oh, although I used the example of a 10g ingress to gig egress, similar issue with 10 gig ingress to single gig egress. (Anytime ingress has more bandwidth than egress, you've oversubscribed your egress, which can lead to reduced performance. It doesn't always do so, though, because perhaps the 10g ingress is only, on average, used 10% of the time, or only one of the 10 gig ingress interfaces is, on average, actually passing traffic, etc.)
