Re: iproute2-2.6.20-070313 bug ?
Denys wrote: Possible i discovered bug, but maybe specific to my setup. In your sources (tc/tc_core.h) i notice #define TIME_UNITS_PER_SEC10 When i change it to #define TIME_UNITS_PER_SEC 100.0 (it was value before in sources) everythign works fine. Otherwise tbf not working at all, it is dropping all packets. Did anyone test new iproute2 with tbf? Yes, please send the commands you use. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Dear Sir Already i sent. I will copy here also Normal patched by me iproute2 /sbin/tc qdisc del dev ppp0 root /sbin/tc qdisc add dev ppp0 root handle 1: prio /sbin/tc qdisc add dev ppp0 parent 1:1 handle 2: tbf buffer 1024kb latency 500ms rate 128kbit peakrate 256kbit minburst 16384 /sbin/tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip dst 0.0.0.0/0 flowid 2:1 tc(patched) monitor output deleted qdisc prio 1: dev ppp0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc prio 1: dev ppp0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc tbf 2: dev ppp0 parent 1:1 rate 128000bit burst 1024Kb peakrate 256000bit minburst 16Kb lat 500.0ms filter dev ppp0 parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:1 match / at 16 VISP-Office ~ #cat /proc/net/psched 0001 0001 000f4240 03e8 Now running tc2, it is stock version /sbin/tc2 qdisc del dev ppp0 root /sbin/tc2 qdisc add dev ppp0 root handle 1: prio /sbin/tc2 qdisc add dev ppp0 parent 1:1 handle 2: tbf buffer 1024kb latency 500ms rate 128kbit peakrate 256kbit minburst 16384 /sbin/tc2 filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip dst 0.0.0.0/0 flowid 2:1 Monitor output: deleted qdisc prio 1: dev ppp0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc prio 1: dev ppp0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc tbf 2: dev ppp0 parent 1:1 rate 128000bit burst 1024Kb peakrate 256000bit minburst 16Kb lat 500.0ms filter dev ppp0 parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:1 match / at 16 VISP-Office ~ #cat /proc/net/psched 0001 0001 000f4240 03e8 Sure when i run tc2 - i see in stats, when it stopped (tc - normal, tc2 - buggy): VISP-Office ~ #tc -s qdisc show dev ppp0 qdisc ingress : Sent 184893 bytes 2311 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 7765 bytes 64 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 64p requeues 0 qdisc tbf 2: parent 1:1 rate 128000bit burst 4294932937b peakrate 256000bit minburst 16Kb lat 4.2s Sent 7765 bytes 64 pkt (dropped 0, overlimits 64 requeues 0) rate 0bit 0pps backlog 0b 64p requeues 0 VISP-Office ~ #tc2 -s qdisc show dev ppp0 qdisc ingress : Sent 186423 bytes 2324 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 8677 bytes 77 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 77p requeues 0 qdisc tbf 2: parent 1:1 rate 128000bit burst 4294932937b peakrate 256000bit minburst 16Kb lat 4.2s Sent 8677 bytes 77 pkt (dropped 0, overlimits 77 requeues 0) rate 0bit 0pps backlog 0b 77p requeues 0 I wish this will be enough information. Thanks for your help! On Thu, 22 Mar 2007 12:23:03 +0100, Patrick McHardy wrote Denys wrote: Possible i discovered bug, but maybe specific to my setup. In your sources (tc/tc_core.h) i notice #define TIME_UNITS_PER_SEC10 When i change it to #define TIME_UNITS_PER_SEC 100.0 (it was value before in sources) everythign works fine. Otherwise tbf not working at all, it is dropping all packets. Did anyone test new iproute2 with tbf? Yes, please send the commands you use. -- Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Denys wrote: /sbin/tc2 qdisc del dev ppp0 root /sbin/tc2 qdisc add dev ppp0 root handle 1: prio /sbin/tc2 qdisc add dev ppp0 parent 1:1 handle 2: tbf buffer 1024kb latency 500ms rate 128kbit peakrate 256kbit minburst 16384 /sbin/tc2 filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip dst 0.0.0.0/0 flowid 2:1 That is an incredible huge buffer value. qdisc tbf 2: parent 1:1 rate 128000bit burst 4294932937b peakrate 256000bit minburst 16Kb lat 4.2s And it causes an overflow. The limit for the TBF burst value with nanosecond resolution is ~ 4 * rate (10^9 * burst / rate 2^32 needs to hold), resoluting in a worst-case latency of 4 seconds. I think this limit is in the reasonable range. Your configuration results in a worst-case queuing delay of 64s, and I doubt that you really want that. Obviously its not good to break existing configurations, but I would argue that this configuration is broken. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Please don't remove CCs. Denys wrote: 1024kb (if i am not wrong 1Mbyte) is huge? For me it is ok, as soon as i have RAM. Its not about the memory, its about the resulting queueing delay. If you buffer packets for 64 seconds the sender will retransmit them and you end up wasting bandwidth. Another thing, it is working well with old tc. Just really if i have plenty of RAM's and i want 32second buffer, why i cannot have that, and if i see it is really possible before? I know it worked before. But I can't think of a reason why anyone would want a buffer that large. Why do you want to queue packets for up to 64 seconds? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Dear sir Sorry, i forgot to CC other members of discussion. 1024kb (if i am not wrong 1Mbyte) is huge? For me it is ok, as soon as i have RAM. Another thing, it is working well with old tc. Just really if i have plenty of RAM's and i want 32second buffer, why i cannot have that, and if i see it is really possible before? Possible i am misunderstanding something... In real world i am seeing reasonable to have much bigger buffers, especially if there is no problem in resources (RAM, timer resolution, CPU). For example, as i remember we had failure on one of our STM-1, and Cisco's on Teleglobe was buffering about 20-30seconds of data without major packetloss. Another thing, why i was using buffer, and possible i use it wrong: For example customer have 128Kbit/s account, and i want to give him burst to open web-pages fast (256Kbit/s), but if he use bandwidth non-stop, he will pass this buffer, and will be throttled back to 128Kbit/s. Now seems i cannot give such functionality. On Thu, 22 Mar 2007 14:09:06 +0100, Patrick McHardy wrote Denys wrote: /sbin/tc2 qdisc del dev ppp0 root /sbin/tc2 qdisc add dev ppp0 root handle 1: prio /sbin/tc2 qdisc add dev ppp0 parent 1:1 handle 2: tbf buffer 1024kb latency 500ms rate 128kbit peakrate 256kbit minburst 16384 /sbin/tc2 filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip dst 0.0.0.0/0 flowid 2:1 That is an incredible huge buffer value. qdisc tbf 2: parent 1:1 rate 128000bit burst 4294932937b peakrate 256000bit minburst 16Kb lat 4.2s And it causes an overflow. The limit for the TBF burst value with nanosecond resolution is ~ 4 * rate (10^9 * burst / rate 2^32 needs to hold), resoluting in a worst-case latency of 4 seconds. I think this limit is in the reasonable range. Your configuration results in a worst-case queuing delay of 64s, and I doubt that you really want that. Obviously its not good to break existing configurations, but I would argue that this configuration is broken. -- Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
On Thu, 22 Mar 2007 14:23:01 +0100, Patrick McHardy wrote Please don't remove CCs. Denys wrote: 1024kb (if i am not wrong 1Mbyte) is huge? For me it is ok, as soon as i have RAM. Its not about the memory, its about the resulting queueing delay. If you buffer packets for 64 seconds the sender will retransmit them and you end up wasting bandwidth. Another thing, it is working well with old tc. Just really if i have plenty of RAM's and i want 32second buffer, why i cannot have that, and if i see it is really possible before? I know it worked before. But I can't think of a reason why anyone would want a buffer that large. Why do you want to queue packets for up to 64 seconds? Seems i misunderstand how it works. If i am not wrong, till buffer available, bandwidth will be given on peakrate speed, and when buffer is empty - on rate speed. I am wrong? At least it was working like this before. -- Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Denys wrote: Another thing, it is working well with old tc. Just really if i have plenty of RAM's and i want 32second buffer, why i cannot have that, and if i see it is really possible before? I know it worked before. But I can't think of a reason why anyone would want a buffer that large. Why do you want to queue packets for up to 64 seconds? Seems i misunderstand how it works. If i am not wrong, till buffer available, bandwidth will be given on peakrate speed, and when buffer is empty - on rate speed. I am wrong? No, I got confused, sorry about that. Your configuration allows bursts up to 64 seconds long. I guess there's nothing wrong with that. I already asked Stephen to revert that patch, it was not meant to be included yet, unfortunately it made it into the release. Even more unfortunate is that it looks like we need larger types in the ABI to properly support nano-second resolution. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Hi again On Thu, 22 Mar 2007 14:43:43 +0100, Patrick McHardy wrote Denys wrote: Another thing, it is working well with old tc. Just really if i have plenty of RAM's and i want 32second buffer, why i cannot have that, and if i see it is really possible before? I know it worked before. But I can't think of a reason why anyone would want a buffer that large. Why do you want to queue packets for up to 64 seconds? Seems i misunderstand how it works. If i am not wrong, till buffer available, bandwidth will be given on peakrate speed, and when buffer is empty - on rate speed. I am wrong? No, I got confused, sorry about that. Your configuration allows bursts up to 64 seconds long. I guess there's nothing wrong with that. I already asked Stephen to revert that patch, it was not meant to be included yet, unfortunately it made it into the release. Even more unfortunate is that it looks like we need larger types in the ABI to properly support nano-second resolution. Thanks sir for your great help and great software and sorry that i took time, by not enough good explanation. -- Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
On Thu, 22 Mar 2007 14:09:06 +0100 Patrick McHardy [EMAIL PROTECTED] wrote: Denys wrote: /sbin/tc2 qdisc del dev ppp0 root /sbin/tc2 qdisc add dev ppp0 root handle 1: prio /sbin/tc2 qdisc add dev ppp0 parent 1:1 handle 2: tbf buffer 1024kb latency 500ms rate 128kbit peakrate 256kbit minburst 16384 /sbin/tc2 filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 match ip dst 0.0.0.0/0 flowid 2:1 That is an incredible huge buffer value. qdisc tbf 2: parent 1:1 rate 128000bit burst 4294932937b peakrate 256000bit minburst 16Kb lat 4.2s And it causes an overflow. The limit for the TBF burst value with nanosecond resolution is ~ 4 * rate (10^9 * burst / rate 2^32 needs to hold), resoluting in a worst-case latency of 4 seconds. I think this limit is in the reasonable range. Your configuration results in a worst-case queuing delay of 64s, and I doubt that you really want that. Obviously its not good to break existing configurations, but I would argue that this configuration is broken. tc should check for overflows and doesn't. Do you want to make a patch for the obvious cases? -- Stephen Hemminger [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iproute2-2.6.20-070313 bug ?
Stephen Hemminger wrote: tc should check for overflows and doesn't. Do you want to make a patch for the obvious cases? I agree. I'll take care of it once I'm done with my patches for 2.6.22. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
iproute2-2.6.20-070313 bug ?
Possible i discovered bug, but maybe specific to my setup. In your sources (tc/tc_core.h) i notice #define TIME_UNITS_PER_SEC10 When i change it to #define TIME_UNITS_PER_SEC 100.0 (it was value before in sources) everythign works fine. Otherwise tbf not working at all, it is dropping all packets. Did anyone test new iproute2 with tbf? -- Virtual ISP S.A.L. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
