As per the comments, we found that the scheduler can significantly undershoot the target rate, particularly if tc_period is set to a low value, the packet size is large and the bitrate is fairly low.  As examples, testing with tc_period = 10ms, packet size of 1538 bytes and both pipe and TC bitrates set to 1875000 bytes/s (1.5Mbps) we saw the target rate undershot by ~20%.

The problem appears to be in grinder_credits_update, where TC credits are refreshed.  Because the update simply sets the tc_credits to tc_credits_per_period, any residual credits are lost.  In our test scenario, tc_period is 10ms, and so tc_credits_per_period is 1875.  This means that in each tc_period the scheduler only sends one 1538 byte packet and the residual 337 bytes of credit are lost on the next refresh.  This means we send 100 packets per second, whereas we would expect either 121 or 122 packets per second.

It's not clear if the behaviour is intentional and the choice of 10ms for tc_credit is a poor one.  It seems sensible not to let TC credit grow unbounded when it is not being used, but isn't that the purpose of the tb_size parameter?  If this is intentional then it means shaping at the TC is very different to shaping at the pipe or subport levels.