QoS the next generation

Discuss the technical details of Gargoyle and ongoing development

Moderator: Moderators

User avatar
braveheartleo
Posts: 47
Joined: Sun Dec 13, 2009 9:50 am

Re: QoS the next generation

Post by braveheartleo »

Code: Select all

root@OpenWrt:~# tc -s class show dev imq0
class hfsc 1: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 2

class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 1000Mbit ul m1 0bit d 0us m2 460000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 860 work 2673085 bytes level 1

class hfsc 1:2 parent 1:1 leaf 8009: ls m1 0bit d 0us m2 250000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:3 parent 1:1 leaf 800a: ls m1 0bit d 0us m2 500000Kbit
 Sent 2674953 bytes 3039 pkt (dropped 52, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 11p requeues 0
 period 860 work 2673085 bytes level 0

class hfsc 1:4 parent 1:1 leaf 800b: ls m1 0bit d 0us m2 250000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class red 8009:1 parent 8009:

class red 800a:1 parent 800a:

class red 800b:1 parent 800b:


So it seems to be the case that the torrent and http downloads are interfering with each other. However, in my connection list is a different case. Where torrent connections are listed, under Qos UP/ Qos DOWN they are marked correct for their class. And they are incrementing.

Here are my rules:

Qos UP:
Rule 1: Dest Ports: 10000-65535
Class: Bulk

Http goes to default class Normal

Qos DOWN:
Rule 1: Src Ports: 10000-65535
Class: Bulk

Http goes to default class Normal

Another note: after a while, some bytes began passing through my Bulk class as indicated by:

Code: Select all

root@OpenWrt:~# tc -s class show dev imq0
class hfsc 1: root
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 2

class hfsc 1:1 parent 1: ls m1 0bit d 0us m2 1000Mbit ul m1 0bit d 0us m2 460000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 6568 work 45541009 bytes level 1

class hfsc 1:2 parent 1:1 leaf 8009: ls m1 0bit d 0us m2 250000Kbit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 0 level 0

class hfsc 1:3 parent 1:1 leaf 800a: ls m1 0bit d 0us m2 500000Kbit
 Sent 45497085 bytes 48759 pkt (dropped 575, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 2p requeues 0
 period 6580 work 45495545 bytes level 0

class hfsc 1:4 parent 1:1 leaf 800b: ls m1 0bit d 0us m2 250000Kbit
 Sent 45464 bytes 865 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 period 790 work 45464 bytes level 0

class red 8009:1 parent 8009:

class red 800a:1 parent 800a:

class red 800b:1 parent 800b:

root@OpenWrt:~#


But still Status->Connection List shows that torrent connections are marked properly as Bulk / Bulk under Qos Up / Qos Down. So where do you think lies the problem? If conntrack shows correct matches, then why does tc not show that packets are passing thru their class?

Does connmark happen first before being passed to the imq target? If so then this may explain why conntrack is correct and why tc is inaccurate. Maybe therein lies the problem.

pbix
Developer
Posts: 1372
Joined: Fri Aug 21, 2009 5:09 pm

Re: QoS the next generation

Post by pbix »

Hmm,

Not sure why the classification is not happening correctly for you. It seems to be a problem but again not related to the controller we are testing. I will investigate but if you could find another way to classify that does work we could continue working on the task at hand.

Does you Bittorrent program have a way to constrain source ports? Normally there is no requirements on source ports and they are almost random numbers. Not useful for classification.

"tc" shows the classes and is definitive. CONNTRACK show marks which should lead to proper classification but apparently does not.
I will try and reproduce the conntrack problem. Please work on getting the classification correct.
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

User avatar
braveheartleo
Posts: 47
Joined: Sun Dec 13, 2009 9:50 am

Re: QoS the next generation

Post by braveheartleo »

Thank you for your assessment on the situation.

I can't think of any other reason why my rule for torrents wouldn't work. I only use one torrent client and is guaranteed to open random ports above 10000. Also I have surveyed my connection list and none of the remote IPs open ports below 10000.

I don't use layer7 filters for bittorrent because as I recall from the l7-filter.sourceforge.net site, they work slow and do not guarantee matching. I have tried it and found some connections not being marked properly.

Also, I only setup such ruleset because I want to test out right away the new congestion control. Under normal use I don't do torrenting, although I will leave such rule defind to limit bw when triggered.

I have upnp enabled, if that helps. For the next test however I will try to disable upnp and open a port on the router where torrent connections to my system will commence.

I will try to make classification work however I can and report back with results.

pbix
Developer
Posts: 1372
Joined: Fri Aug 21, 2009 5:09 pm

Re: QoS the next generation

Post by pbix »

braveheartleo,

I did some basic testing using Src ports and download QoS. The traffic seems to get market correctly and sent to the correct class on my router so no problem.

Which bittorrent client are you using? I will try and use it to see if I can reproduce your situation.
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

User avatar
braveheartleo
Posts: 47
Joined: Sun Dec 13, 2009 9:50 am

Re: QoS the next generation

Post by braveheartleo »

I have updated my rules as follows:

Code: Select all

qos up:
Application Protocol: BitTorrent   Bulk            
Source Port: 1024-65535, Destination Port: 10000-65535   Bulk

Http set to default class Normal

qos down:
Application Protocol: BitTorrent   Bulk            
Source Port: 10000-65535, Destination Port: 1024-65535

Http set to default class Normal


And I have run both http and torrent download for several minutes. qosmon.status shows some bytes passing the Bulk class but nothing much to activate the class, thus activte congestion control.

Code: Select all

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 450 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 3, BW bps (filtered): 450187
ID 8005, Active 0, Backlog 0, BW bps (filtered): 122

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 452 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 5, BW bps (filtered): 452208
ID 8005, Active 0, Backlog 0, BW bps (filtered): 166

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 452 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 5, BW bps (filtered): 452208
ID 8005, Active 0, Backlog 0, BW bps (filtered): 166

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 454 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 4, BW bps (filtered): 453860
ID 8005, Active 0, Backlog 0, BW bps (filtered): 150

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 454 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 4, BW bps (filtered): 453860
ID 8005, Active 0, Backlog 0, BW bps (filtered): 150

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 444 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 2, BW bps (filtered): 443886
ID 8005, Active 0, Backlog 0, BW bps (filtered): 135

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 444 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 2, BW bps (filtered): 443886
ID 8005, Active 0, Backlog 0, BW bps (filtered): 135

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 441 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 0, BW bps (filtered): 441542
ID 8005, Active 0, Backlog 0, BW bps (filtered): 160

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 441 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 0, BW bps (filtered): 441542
ID 8005, Active 0, Backlog 0, BW bps (filtered): 160

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 442 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 0, BW bps (filtered): 442692
ID 8005, Active 0, Backlog 0, BW bps (filtered): 144

root@OpenWrt:~#
root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 444 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 0, BW bps (filtered): 444555
ID 8005, Active 0, Backlog 0, BW bps (filtered): 130

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 449 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 2, BW bps (filtered): 448914
ID 8005, Active 0, Backlog 0, BW bps (filtered): 117

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 449 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 2, BW bps (filtered): 448993
ID 8005, Active 0, Backlog 0, BW bps (filtered): 105

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 449 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 2, BW bps (filtered): 448993
ID 8005, Active 0, Backlog 0, BW bps (filtered): 105

root@OpenWrt:~# cat /tmp/qosmon.status
State: FREE
Link limit: 460 (kbps)
Fair Link limit: 414 (kbps)
Link load: 451 (kbps)
Ping: off
Filtered ping: 78 (ms)
Ping time limit: 286 (ms)
Classes Active: 1
ID FFFF, Active 0, Backlog 0, BW bps (filtered): 0
ID 8003, Active 0, Backlog 0, BW bps (filtered): 0
ID 8004, Active 1, Backlog 3, BW bps (filtered): 451841
ID 8005, Active 0, Backlog 0, BW bps (filtered): 94


root@OpenWrt:~#


But my connection list tells a different story. Where torrent connections are concerned, I see Bulk/Bulk matched pairs under Qos Up/Qos Down. With http download, Normal/Normal. I have monitored this list and did not see irregular pairs like Bulk/Normal or Normal/Bulk. While conntrack says one thing, tc shows otherwise, puzzling. :?

I'm using utorrent 2.0.3. I have disabled upnp and opened a port for torrent connections.

Oh and one other thing, even though in my rules list I have specified to match first using layer7 application filter, my connection list do not indicate anything under L7 proto column. I can confirm that xt_layer7 module is loaded with lsmod

Code: Select all

root@OpenWrt:~# lsmod |grep layer7
xt_layer7              10736  1
nf_conntrack           39408 18 nf_nat_tftp,nf_conntrack_tftp,nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,xt_layer7,ipt_MASQUERADE,iptable_nat,nf_nat,xt_CONNMARK,xt_helper,xt_conntrack,xt_connmark,xt_connbytes,xt_NOTRACK,xt_state,nf_conntrack_ipv4
x_tables                9088 53 ebt_arpnat,ebt_redirect,ebt_mark,ebt_vlan,ebt_stp,ebt_pkttype,ebt_mark_m,ebt_limit,ebt_among,ebt_802_3,ebtables,xt_IMQ,ipt_weburl,ipt_webmon,ipt_timerange,xt_iprange,xt_HL,xt_hl,xt_MARK,ipt_ECN,xt_CLASSIFY,xt_time,xt_tcpmss,xt_statistic,xt_mark,xt_length,ipt_ecn,xt_DSCP,xt_dscp,xt_string,xt_layer7,ipt_bandwidth,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,iptable_nat,xt_CONNMARK,xt_recent,xt_helper,xt_conntrack,xt_connmark,xt_connbytes,xt_NOTRACK,xt_state,ipt_REJECT,xt_TCPMSS,ipt_LOG,xt_comment,xt_multiport,xt_mac,xt_limit,ip_tables,xt_tcpudp


Any chance of a misconfiguration on my part?

pbix
Developer
Posts: 1372
Joined: Fri Aug 21, 2009 5:09 pm

Re: QoS the next generation

Post by pbix »

Faced with these situation I follow the advice of Napolean and divide and conquer. That is remove everything from QoS I could. For example, turn off the active controller, turn off Upload QoS, disable the L7layer matching. Also go from three to two download classes. Turn off every optional feature I could.

The goal is to come up with the simplest possible setup that will show conntrack marking one way and class activity not agreeing.

Then cat the following to a file and attach to your forum post.
/proc/net/ip_conntrack
iptables -vnl -t mangle
tc filter show dev imq0
tc class show dev imq0

We are concentrating on the download direction. At this point there is evidence that a mistake on your part is responsible for your situation. It seems there is a bug in here somewhere.
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

User avatar
braveheartleo
Posts: 47
Joined: Sun Dec 13, 2009 9:50 am

Re: QoS the next generation

Post by braveheartleo »

Thanks for the time troubleshooting this with me.

I'll call this one out a bug, unless my matching rule logic sucked :lol:, but here's the result of the commands you asked for.

First let me say a couple of things about my setup:
1. I do not have quotas.
2. I do not have restrictions.
3. I have webmon enabled and running.
4. I have upnp disabled and not running.
5. I have a one ddns rule for opendns.
6. I have a port forwarded to my pc for testing torrent.
7. All other options in webif I left untouched, save for a couple of dhcp and network config edits for my network address setup.

Here's what I did prior to reporting:
1. I removed layer7 rules from Qos up and down.
2. I reduced class service for Qos down to two.
3. I left bittorrent rule for matching bulk traffic in Qos down.
4. I disabled congestion control, then saved.
5. I left Qos up disabled while Qos down enabled, then rebooted.
6. I started both http and torrent downloads, leaving them running for 5 mins. to gather enough data.

Here is the file you ask. I have masked out my public IP. Hope this helps. :)
Last edited by braveheartleo on Fri Aug 06, 2010 12:47 pm, edited 1 time in total.

pbix
Developer
Posts: 1372
Joined: Fri Aug 21, 2009 5:09 pm

Re: QoS the next generation

Post by pbix »

Opps, I forgot to specify the "-s" in the tc command.

tc -s filter show dev imq0
tc -s class show dev imq0

If possible run again with these but if not can you at least confirm that even in this simplified state only one class of the two you have is seeing the bytes?
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM

User avatar
braveheartleo
Posts: 47
Joined: Sun Dec 13, 2009 9:50 am

Re: QoS the next generation

Post by braveheartleo »

Qos down is working! When both http and torrent downloads are running, the torrent doesn't hog the bw so my http download remains fast. :) Now when I stop http the torrent picks up pace. Nice.

Also, I'm seeing significant bytes passing both classes using tc -s class show dev imq0. Where if I stop http, then the bulk class increases work bytes counters while the normal class remains idle with few counter increments.

Given that qos down matching works as expected. I proceeded to enable qos up, leaving congestion control disabled still, then rebooted.

Redoing the test, I now see that my problem might have something to do with the qos up, because tc now shows too few bytes passing the bulk class, so the normal class keeps increasing counters even though with http download stopped. I investigated further and did an iptables -t mangle -vnL and here's the result

Code: Select all

root@OpenWrt:~# iptables -t mangle -vnL
Chain PREROUTING (policy ACCEPT 16965 packets, 7328K bytes)
 pkts bytes target     prot opt in     out     source               destination
10110 6752K qos_ingress_imq  all  --  eth0.2 *       0.0.0.0/0            0.0.0.0/0

Chain INPUT (policy ACCEPT 1188 packets, 84666 bytes)
 pkts bytes target     prot opt in     out     source               destination
   90 16966 qos_ingress  all  --  eth0.2 *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 15752 packets, 7225K bytes)
 pkts bytes target     prot opt in     out     source               destination
 9998 6716K qos_ingress  all  --  eth0.2 *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 1339 packets, 219K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 17084 packets, 7443K bytes)
 pkts bytes target     prot opt in     out     source               destination
 5752  506K qos_egress  all  --  *      eth0.2  0.0.0.0/0            0.0.0.0/0 

Chain qos_egress (1 references)
 pkts bytes target     prot opt in     out     source               destination
 5752  506K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x2
 3587  390K MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:1024:65535 dpts:10000:65535 MARK set 0x3
  658 43674 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:1024:65535 dpts:10000:65535 MARK set 0x3
 5752  506K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save mask 0x7f

Chain qos_ingress (2 references)
 pkts bytes target     prot opt in     out     source               destination
10087 6733K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x200
 6742 2852K MARK       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp spts:10000:65535 dpts:1024:65535 MARK set 0x300
  786  560K MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spts:10000:65535 dpts:1024:65535 MARK set 0x300
10087 6733K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK save mask 0x7f00

Chain qos_ingress_imq (1 references)
 pkts bytes target     prot opt in     out     source               destination
10110 6752K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore
10110 6752K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore mask 0x7f00
10109 6752K IMQ        all  --  *      *       0.0.0.0/0            0.0.0.0/0           IMQ: todev 0


So is the problem indeed in the qos up section? My connection list shows Bulk/Bulk under Qos up/Qos down for torrent connections.

Post Reply