From: Corey Hickey <bugfood-ml@fatooh.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] doubt about esfq
Date: Tue, 18 Dec 2007 20:17:54 +0000 [thread overview]
Message-ID: <47682AF2.7080305@fatooh.org> (raw)
In-Reply-To: <beb91d720712170502u6a56507v776d5e0b9566b871@mail.gmail.com>
Salatiel Filho wrote:
> In esfq README i have:
>
> Depth sets the number of slots. If the number of active flows is greater
> than the number of slots, flows will end up sharing slots and ESFQ will no
> longer be fair. If you anticipate more than 128 concurrently active flows,
> you should use a larger depth and probably a larger divisor (see below).
>
> If you expect there to be far fewer than 128 concurrent flows, you may
> want to use a lower depth in order to benefit from slightly better latency
> (because limit can then be lower as well).
>
>
>
> I am just curious, 128 active flows would mean [in ESFQ] 128 different
> IPs if i hash for ip dst ? or would it be 128 connections.
> For example let`s say i download from my machine using some download
> accelerator and put 128 parallel connections[ theorically of course :)
> ] , so would i be using all slots or just one ?
Maybe. I had to re-read your message a couple times, and I'm not sure I
completely understand your question. In any case, you didn't specify
whether you are using ESFQ on the LAN interface or the WAN interface of
your router.
Scenario 1: downloading from 128 different IPs
hash dst on LAN interface:
puts all packets in a single slot--after all, the destination IP is
that of your workstation. This approach would only be useful if
other workstations on your LAN were downloading as well, since their
packets would go in other slots.
hash dst on WAN interface:
divides packets into 128 different slots[1], since the destination
IPs are those of the servers from which you are downloading. Note,
however, that if you're only downloading, these packets would be
"empty ACKs", which are quite small. Unless your upstream bandwidth
is severely limited (or in heavy use for other reasons), the ACK
packets would not need any special consideration. This approach is
more useful for if you are actually uploading data and you want the
outbound traffic to be allocated fairly among the remote hosts.
Scenario 2: downloading from one IP, with 128 connections
hash dst on LAN interface:
puts all packets on a single slot (same as in scenario 1).
hash dst on WAN interface:
puts all packets in a single slot, since there is only one remote
host to which the packets are going.
From what I've written, you may gather that using "hash dst" is not of
much use for distributing inbound traffic to a single workstation. If
that is really what you need to do, then you can look into "hash src".
[1] This is subject to the limitations of the hash function, and there
may be collisions that result in slots being shared. See the "divisor"
and "perturb" parameters.
-Corey
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2007-12-18 20:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-17 13:02 [LARTC] doubt about esfq Salatiel Filho
2007-12-18 20:17 ` Corey Hickey [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=47682AF2.7080305@fatooh.org \
--to=bugfood-ml@fatooh.org \
--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.