All of lore.kernel.org
 help / color / mirror / Atom feed
From: DervishD <lartc@dervishd.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Latency/burst problem with HTB
Date: Sat, 05 Nov 2005 15:47:15 +0000	[thread overview]
Message-ID: <20051105154715.GA10117@DervishD> (raw)
In-Reply-To: <20051104101743.GA83@DervishD>

    Hi Toby :)

 * Toby <tobia.conforto@linux.it> dixit:
> DervishD wrote:
> > If I add this as you suggest then it will have the same priority that
> > general traffic.
> It doesn't if you lower general traffic to prio 1 and ftp traffic to
> prio 2, as I'm sure I said somewhere in my other email.

    Which I've done ;)) You said that in the comments of the "tc"
commands (you say that the priorities of the sibling classes should
be lower).
 
> > Would it be because it will go out of the queue *even before* than
> > general ADSL traffic? I think that's the reason, right?
> 
> Yes, that's the idea.

    OK, I understand now. Thanks a lot :)))
 
> Now the only thing left to do is to lower the total rate and ceil
> to 16kbit below the ADSL upload cap (again, read the wondershaper
> documentation to understand why.)

    That's something I learnt even when I didn't know about
wondershaper ;) My ADSL has 300kbit of upload rate, that's why I'm
using 256 and not 300. I want to leave those 44kbit for the other
box. BTW, I didn't notice that the other box was up and running
(running WinDOS) is uploading traffic at almost 10kbps so it is
probably filling the ADSL router buffers :( That may be the reason
why I'm getting poor latency when the ADSL FTP traffic goes above 175
(in fact, I bet the traffic limit is 300kbit-otherboxkbit).

    Unfortunately I cannot shutdown that box by now, and probably I
will need to do my shaping taking into account an upload rate from
the other machine of about 12kbps or something like that. 15kbps will
be better... That leaves a value nearer to 180kbit instead of 256...
Well, I'll try to make the other box upload at a lower rate if I can.

> By the way, I wouldn't use the burst option.

    But it gives me some improvement, why should I get rid of it?
I'm not sure about why it does, but using a burst of 8192-20480 and a
cburst of about the half seems to improve latency a bit. It's just an
illusion? For me it would be great if I could get rid of the burst
and cburst settings, because my tc script will be easier to maintain.

    Thanks a lot for your help, now my tc works much better :))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

      parent reply	other threads:[~2005-11-05 15:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-04 10:17 [LARTC] Latency/burst problem with HTB DervishD
2005-11-05 11:10 ` Toby
2005-11-05 14:42 ` DervishD
2005-11-05 15:17 ` Toby
2005-11-05 15:47 ` DervishD [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051105154715.GA10117@DervishD \
    --to=lartc@dervishd.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.