Hi,
I use the patch
(http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate
the packet scheduling on ATM/ADSL link and i think I''ve found a bug.
I tried to write to the author but he didn''t answer me.
I work on a Linux 2.6.17 with the iproute2-2.6.18-061002 package.
I change the type of the cell_align char to short of the struct
tc_ratespec in the file pkt_sched.h (in the include/linux/ directories
of iproute package and the kernel source) :
struct tc_ratespec
{
unsigned char cell_log;
unsigned char __reserved;
unsigned short feature; /* Always 0 in pre-atm patch kernels */
- char cell_align; /* Always 0 in pre-atm patch kernels */
- unsigned char __unused;
+ short cell_align; /* Always 0 in pre-atm patch kernels */
unsigned short mpu;
__u32 rate;
};
The results are much better and with my tests, it works very nicely.
If it can help someone,
Edouard.
On Wed, 2007-07-25 at 15:14 +0200, Edouard Thuleau wrote:> I use the patch > (http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate > the packet scheduling on ATM/ADSL link and i think I''ve found a bug. > I tried to write to the author but he didn''t answer me.Sorry. :( I have now.> I work on a Linux 2.6.17 with the iproute2-2.6.18-061002 package. > I change the type of the cell_align char to short of the struct > tc_ratespec in the file pkt_sched.h (in the include/linux/ directories > of iproute package and the kernel source) : > > struct tc_ratespec > { > unsigned char cell_log; > unsigned char __reserved; > unsigned short feature; /* Always 0 in pre-atm patch kernels */ > - char cell_align; /* Always 0 in pre-atm patch kernels */ > - unsigned char __unused; > + short cell_align; /* Always 0 in pre-atm patch kernels */ > unsigned short mpu; > __u32 rate; > }; > > The results are much better and with my tests, it works very nicely. > > If it can help someone,I can''t see how that would change things as the cell align always lies within the range -7..0. The only thing that springs to mind is perhaps you aren''t using i386, and your CPU doesn''t sign extend char''s??? What CPU are you using?
Hi, 2007/7/26, Russell Stuart <russell-tcatm@stuart.id.au>:> On Wed, 2007-07-25 at 15:14 +0200, Edouard Thuleau wrote: > > I use the patch > > (http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate > > the packet scheduling on ATM/ADSL link and i think I''ve found a bug. > > I tried to write to the author but he didn''t answer me. > > Sorry. :( I have now.Thanks for your answer.> > > I work on a Linux 2.6.17 with the iproute2-2.6.18-061002 package. > > I change the type of the cell_align char to short of the struct > > tc_ratespec in the file pkt_sched.h (in the include/linux/ directories > > of iproute package and the kernel source) : > > > > struct tc_ratespec > > { > > unsigned char cell_log; > > unsigned char __reserved; > > unsigned short feature; /* Always 0 in pre-atm patch kernels */ > > - char cell_align; /* Always 0 in pre-atm patch kernels */ > > - unsigned char __unused; > > + short cell_align; /* Always 0 in pre-atm patch kernels */ > > unsigned short mpu; > > __u32 rate; > > }; > > > > The results are much better and with my tests, it works very nicely. > > > > If it can help someone, > > I can''t see how that would change things as the cell align > always lies within the range -7..0. The only thing that > springs to mind is perhaps you aren''t using i386, and your > CPU doesn''t sign extend char''s??? What CPU are you using? >Yes I use an ARM big-endian architecture, it''s my problem. I understood now. If we put a short, the patch works for all architecture, no ? Thanks.
Hi ! (Sorry for my bad english...)> I use the patch > (http://ace-host.stuart.id.au/russell/files/tc/tc-atm/) for accurate > the packet scheduling on ATM/ADSL link and i think I''ve found a bug.I use it too, this patch is great! :o) But, with TBF, both burst and limit parameters are "affected" by the patch (or I clearly missed something). tc qdisc add dev eth1 root handle 1:0 tbf rate 100kbit \ burst 1514b limit 1514b mpu 64 atm overhead -4 tc qdisc add dev eth1 parent 1:1 handle 10:0 pfifo Before the patch (without "atm overhead -4"), using PPPoA + VC/Mux and MSS set to 1438, TBF was working normally. Just after the patch (with "atm overhead -4"), it stopped working : packets were blocked until I raise up burst and limit to 1696 (32 * 53). In this case Linux sees 1492 bytes packets on eth1 (1438 + 20 IP + 20 TCP + 14 Ethernet) Same effect with a lower MSS : burst and limit must be set to 742b (14 * 53) when MSS = 574. Pretty sure I do not unsterdand something... and wondering why I cannot set set burst/limit to 628b (only for TCP streams). To get mimimal burst/limit values, an extra atm cell is needed : mss = 1150 eth1 packet = 1204b (1150 + 40 + 14) modem packet = 1200b ( 1150 + 40 + 2 PPP + 8 AAL5) Atm cells = 25 (1200 / 48) Add one cell... and... min burst/limit = 1378 ( 26 * 53 ) TBF rate also seems to be affected: I currently have it set to 159kbit on a 128kbits upstream link and it works like a charm! :o) This is not really a problem (if it works, don''t touch it) but I would like to understand... Thanks! Philippe