dropping packets is one of the two ways a shaper can slow down inbound traffic. dropped packets are not inherently bad for TCP traffic. unless you have an actual performance issue here, you are (IMO) spending a lot of time to try (futilely) to solve an intractable problem.
He's having the same problem I'm having. It's dropping packets when there is no congestion and well below the max pipe bandwidth. In order for my ~30mb connection to be fully utilized I have to tell the shaper I have a 40mb connection. If I set it to 35mb it drops packets and maxes me out at 25mb. If I set to 30mb I max out at about 17/18mb.
It's dropping packets when I'm using a paltry 64kb bandwidth on the "high priority" queue, but if traffic gets routed to the "others" low priority queue no packets get dropped. It's functioning in reverse, and shaping (dropping) far too early.
Also, if I try to set the upper limit on the root queue, it is 100% ineffective. I could set upper limit to be 1mb and it will still allow 30mb to cross on the wire. (yes, I've tested for both directions.) The shaper is pretty much not functioning correctly.
lastly, there are other ways to shape download - by delaying packet delivery which will cause the app to back off. see http://www.netequalizer.com/tsfaq.htm