Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Illegal "rate" when running tcset #54

Closed
ducalpha opened this issue Feb 14, 2017 · 6 comments
Closed

Illegal "rate" when running tcset #54

ducalpha opened this issue Feb 14, 2017 · 6 comments
Labels

Comments

@ducalpha
Copy link

I ran --device eth0 --delay 25 --rate 1M but encountered an error complaining about Illegal rate.
My computer uses Ubuntu 14.04 (kernel 4.4.0) with a gigabit ethernet.

[DEBUG] subprocrunner: tc class add dev eth0 parent 1a1a: classid 1a1a:1 htb rate 1000Gbit
[WARNING] subprocrunner: returncode=1, stderr=Illegal "rate"
Usage: ... qdisc add ... htb [default N] [r2q N]
[direct_qlen P]
default minor id of class to which unclassified packets are sent {0}
r2q DRR quantums are computed as rate in Bps/r2q {10}
debug string of 16 numbers each 0-3 {0}

direct_qlen Limit of the direct queue {in packets}
... class add ... htb rate R1 [burst B1] [mpu B] [overhead O]
[prio P] [slot S] [pslot PS]
[ceil R2] [cburst B2] [mtu MTU] [quantum Q]
rate rate allocated to this class (class can still borrow)
burst max bytes burst which can be accumulated during idle period {computed}
mpu minimum packet size used in rate computations
overhead per-packet size overhead used in rate computations
linklay adapting to a linklayer e.g. atm
ceil definite upper class rate (no borrows) {rate}
cburst burst but for ceil {computed}
mtu max packet size we create rate map for {1600}
prio priority of leaf; lower are served first {0}
quantum how much bytes to serve from leaf at once {use r2q}

TC HTB version 3.3

Fix: It seems that setting the unlimited rate as 1000Gbit is not good on my machine. Changing shaper/htb.py:HtbShaper's __NO_LIMIT = "1000G" to "1G" solved the problem for me.

thombashi added a commit that referenced this issue Feb 15, 2017
@thombashi thombashi added the bug label Feb 15, 2017
@thombashi
Copy link
Owner

@ducalpha
Thank you for your report.

I've made the package 0.7.1-alpha which include your solution to work around the issue temporarily.

Unfortunately, I could not reproduce the problem for now.
Could you tell me the version of iproute2 package that installed in your system?

@ducalpha
Copy link
Author

My iproute2 version is 3.12.0-2ubuntu1 as seen in the dpkg command:

$ dpkg -s iproute2
... Architecture: amd64
Multi-Arch: foreign
Version: 3.12.0-2ubuntu1

I think the best way is to get the maximum speed of the network device instead of hard-coding the __NO_LIMIT value.

@thombashi
Copy link
Owner

thombashi commented Feb 16, 2017

Thank you for your information.

I think the best way is to get the maximum speed of the network device instead of hard-coding the __NO_LIMIT value.

That's what I thought as a solution at first, but I'm not so sure that can be resolved the root cause.
Because of two reasons:

  1. The problem not reproduced in my environment
  2. iproute2 does not check physical network bandwidth when validate the rate (according to my brief survey of iproute2 source code)

Anyway, current fix is a temporal solution. I will try to reproduce the problem by creating an environment same as yours.

@ducalpha
Copy link
Author

Probably I am using an old version of iproute2. Although iproute2 might not validate the rate, the conversion of a very big number like 1Gbit to 1 trillion bits may cause a number overflow, resulting in a negative rate.

@thombashi
Copy link
Owner

Thank you for your comment. You are right.

Old version of iproute2 using 32 bit variable to store rate and failed where the overflow checking.

iproute2/tc/tc_util.c

int get_rate(unsigned int *rate, const char *str)
{
    char *p;
    double bps = strtod(str, &p);
    
    // ....
    
    bps /= 8; /* -> bytes per second */
    *rate = bps;
    /* detect if an overflow happened */
    if (*rate != floor(bps))
        return -1;    // reach this line when the rate is 1000G
    return 0;
}

This limitation was removed by the below commit.

http:https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=8334bb325d5178483a3063c5f06858b46d993dc7

htb: support 64bit rates

Starting from linux-3.13, we can break the 32bit limitation of
rates on HTB qdisc/classes.

Prior limit was 34.359.738.360 bits per second.

This commit applied since iproute2 3.14.0.
I've used iproute2 3.16 or greater in my test environments.
So, the problem was not reproduced.

I'll fix the problem appropriately.
I'm planning that using min value of followings as the no limit value:

  • physical NIC bandwidth
  • rate upper limit (described in the above commit))
    • prevent exceed the rate upper limit when you use 40GbE NIC with iproute2 version<3.14

Change the rate upper limit calculation by iproute2 version will be a more ideal solution. Unfortunately, I do not know the easy way to get iproute2 version (that can be used all of the distributions).

@thombashi
Copy link
Owner

I've fixed the issue at tcconfig 0.7.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants