On 06/21/2013 01:46 PM, Remy Mudingay wrote: > All correct except that you need to classify from the prio class to the leaf qdisc, which in your case is tbf. > I strongly recommend testing this further. I did test it now. It seems to be a discrepancy between my kernel and my userland tools. I tested it on a debian stable stock kernel, now. and things behave as they should. > 1. Create the prio qdisc with priomap but without attaching leaf qdisc's to the prio classes. I see differentiation. > 2. Then test again by attaching qdiscs to your prio class. I see differentiation, also with qdiscs in my prio classes, and even without classification rules. > 3. Finally test using your current setup but include classification rules. Don't matter anymore. I know that I've been fooled by tc :) > Test 1 and 3 will both work. > > Remy. Even Test 2 worked. Thank you for your help. Wolfgang > > Sent from my iPhone > > On Jun 21, 2013, at 11:09, Wolfgang Hennerbichler <wogri@xxxxxxxxx> wrote: > >> On Jun 21, 2013, at 11:03 , Remy Mudingay <remy.mudingay@xxxxxxxxx> wrote: >> >>> Thanks for providing more info. >>> Firstly, the checksum error stems from tcp offloading on the local interface (wan0). >> >> Thank you. I didn't know about TOE and it's implication before. >> >>> However, the prio qdisc does require the addition of filters when attaching qdisc's to prio classes. Take a look at the following example : >>> >>> http://d3s.mff.cuni.cz/~ceres/sch/osy/text/ch06s02s04.html >> >> wow. Did I misunderstand the prio-qdisc? >> from man tc-prio >> >> CLASSIFICATION >> Three methods are available to PRIO to determine in which band a packet will be enqueued. >> … >> with the priomap >> Based on the packet priority, which in turn is derived from the Type of Service assigned to the packet. >> >> The priomap maps the priority of a packet to a class. The priority can either be set directly from userspace, or be >> derived from the Type of Service of the packet. >> >> Determines how packet priorities, as assigned by the kernel, map to bands. Mapping occurs based on the TOS octet of the >> packet, which looks like this: >> … >> >> to me it seems to be the case that the prio-qdisc would be intelligent enouth to priorize for me. >> >> >>> Remy >>> On Jun 21, 2013, at 7:42, Wolfgang Hennerbichler <wogri@xxxxxxxxx> wrote: >>> >>>> >>>> -- >>>> http://www.wogri.at >>>> >>>> On Jun 21, 2013, at 05:11 , Remy Mudingay <remy.mudingay@xxxxxxxxx> wrote: >>>> >>>>> Hi Wolfgang, >>>>> >>>>> Can you post the output from 'tc -s class dev wan0' and also include >>>>> all filters for matching scp, ssh and telnet. >>>> >>>> Hi Remy, >>>> >>>> tc -s class show dev wan0 >>>> class prio 1:1 parent 1: leaf 10: >>>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> class prio 1:2 parent 1: leaf 20: >>>> Sent 97189 bytes 678 pkt (dropped 11, overlimits 409 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> class prio 1:3 parent 1: leaf 30: >>>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>>> backlog 0b 0p requeues 0 >>>> class tbf 20:1 parent 20: >>>> >>>> (this is after doing some fiddling with an interactive ssh session). >>>> There are no filters (neither tc nor iptables mangles), as far as I've understood prio should priorize according to it's priomap. >>>> >>>> here's a tcpdump: >>>> >>>> 05:39:28.048426 IP (tos 0x10, ttl 64, id 60303, offset 0, flags [DF], proto TCP (6), length 52) >>>> x.x.x.x.50356 > y.y.y.y.22: Flags [.], cksum 0x545e (incorrect -> 0xc7ca), seq 0, ack 433, win 653, options [nop,nop,TS val 31327537 ecr 1639911627], length 0 >>>> >>>> oh. and maybe this is my issue: i see an incorrect checksum here on all those packets. maybe this is causing the troubles. is there a chance that this is happening because my interface is bridged? hm. I wonder how to deal with this (the actual communication works, btw). >>>> >>>> Wolfgang >>>> >>>>> Cheers, >>>>> >>>>> Remy >> -- http://www.wogri.com -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
