All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.