Changing pfifo packet queue ?

Discussion in 'Tomato Firmware' started by Ernesto Elias, Apr 29, 2013.

  1. Ernesto Elias

    Ernesto Elias Serious Server Member

    Well I've been searching around on Google and came across this command but I do not know if it really does change the pfifo queue instead of holding 256p here it is:
    tc qdisc add dev eth0 root pfifo limit 10

    Please tell me that it does because I've been looking for a way to do so but if not is there a way to do so ?
  2. Porter

    Porter LI Guru Member

  3. Ernesto Elias

    Ernesto Elias Serious Server Member

    Thank you :) and also it's because I've been doing a little research about the queues of the qdiscs and that pfifo had a higher queue than sfq. and also that sfq that some latency spikes because of the perturb time when it re shifts the order. so what I'm trying to do is lower the queue for it to achieve lower latency.
  4. Porter

    Porter LI Guru Member

    I did do a test with comparing sfq and pfifo. The tests with both these qdiscs were terrible. With sfq I got 3400ms of delay on an uplink with 310kbit/s! Without QoS enabled I got 70ms!

    In order for sfq to use a lower queue size you need to change one parameter in /linux/net/sched/sch_sfq.c which is this one: #define SFQ_DEPTH 128. I changed the value to 15 and recompiled.

    After this the test gave me 320ms for my uplink, which was quite ok, especially since the traffic from this test ended up in my lowest class since it used non-standard ports.

    There is one problem: with ADSL-lines upstream and downstream bandwiths are as the name says "asychronous". Lowering the queue depth too much might interfere with your downstream, meaning that you will get lower throughput.

    Unfortunately the sfq queue in Tomato K24 (didn't check K26) can't be told to use different queue szes for inbound and outbound, so you'll have to experiment which value give you good response times, but still acceptable download speeds. There is no "one value fits all" here.

    There seems to be a patch for sfq, which is called esfq put seems to just patch the sfq code so you don't need to change your scripts to "esfq". This patch then allows for the queue depth to be defined separately and some other cool stuff, i.e. more fairness by shaping on a per IP basis, so people who use more http-streams for a download won't get more speed. Great if you have a lot of users.

    The esfq scheduler gets compiled as a module but unfortunately tc obviously didn't get patched correctly because it can't handle the esfq parameters, so right now it's useless.
  5. Ernesto Elias

    Ernesto Elias Serious Server Member

    Lol I can imagine it might went horrible , but hey we got to make do with what we got. :)

    And so what you say is that isn't gonna change the queue size because I found this while googline how to lower packet limits on qdisc and I got this:

    tc qdisc replace dev eth0 root sfq perturb 30 limit 15

    tc qdisc replace dev eth0 root pfifo limit 15

    With that I check my self with the tc -s qdisc command and found that it actually powers the packet limit to 15 instead of 128 or 127 packets. But of course I maybe wrong on this don't quote me on this.

    But I have another question about the perturb timing will it be better to set it higher if you have high speeds of bandwidth?
  6. Porter

    Porter LI Guru Member

    Indeed, sfq does understand limit and I experimented a bit with it. Now my QoS-script has different values for inbound and outbound classes. Outbound 6 and inbound 50, for a 460/4600KBit line. Seems to work so far.

    I really don't know how much processing power perturb requires for reordering, but its obviously neccessary to prevent unfairness. If you set a higher value it's possible that any unfairness remains for a longer time. Can't give you any better advice...
  7. Marcel Tunks

    Marcel Tunks Networkin' Nut Member

    That's a pretty low limit on SFQ. It may give you problems.
    Toastman and the contributors to the QoS development thread may have some insight into this issue.

    It's tempting to reduce the number. Please let us know how it goes!
  8. Porter

    Porter LI Guru Member

    That's an interesting link. I already ended up killing my connectivity by lowering the limit to 2. I'll definitely test some tomorrow by adding some torrents and see how parallel surfing goes.

    Btw: I'm the creator of that QoS development thread. ;)
    Marcel Tunks likes this.
  9. Ernesto Elias

    Ernesto Elias Serious Server Member

    Well I remember seeing a thread about a user wanting the developers if possible to make the packets configurable like sfq and pfifo for QoS and well I tried to do it to set up my own QoS with rules and everything I've managed to get far into it but ran to a snag and because of that experience I grow to show a lot of respect to the person who made QoS so much simpler and believe me I mean simpler. The only reason why I was trying to was to see if I can set the packet limit lower you know for bufferbloat to be good and not cause latency.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice