On Fri, 29 May 2009 21:46:43 +0200
Jarek Poplawski [off-list ref] wrote:

On Fri, May 29, 2009 at 06:02:39PM +0100, Antonio Almeida wrote:

quoted

On Thu, May 28, 2009 at 10:12 PM, Jarek Poplawski wrote:

quoted

Yes, but according to my assessment there should be "only" 50Mbit
difference for this rate/packet size. Anyway, could you try a testing
patch below, which should add some granularity to this rate table?

Thanks,
Jarek P.
---

 include/net/pkt_sched.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index e37fe31..f0faf03 100644
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h

@@ -42,8 +42,8 @@ typedef u64   psched_time_t;
 typedef long   psched_tdiff_t;

 /* Avoid doing 64 bit divide by 1000 */
-#define PSCHED_US2NS(x)                        ((s64)(x) << 10)
-#define PSCHED_NS2US(x)                        ((x) >> 10)
+#define PSCHED_US2NS(x)                        ((s64)(x) << 6)
+#define PSCHED_NS2US(x)                        ((x) >> 6)

 #define PSCHED_TICKS_PER_SEC           PSCHED_NS2US(NSEC_PER_SEC)
 #define PSCHED_PASTPERFECT             0

It's better! This patch gives more accuracy to HTB. Here some values:
Note that these are boundary values, so, e.g., any HTB configuration
between 377000Kbit and 400000Kbit would fall in the same step - close
to 397977Kbit.

Good news! So it seems there are no other reasons of this inaccuracy
than too coarse granularity, but I have to check this yet. Alas there
is needed something more than this patch, because it probably breaks
other things like hfsc.

Thanks,
Jarek P.

Why would it break hfsc, if it isn't already broken.