All of lore.kernel.org
 help / color / mirror / Atom feed
From: bert hubert ahu@ds9a.nl
To: lartc@vger.kernel.org
Subject: SV: [daniel@netatonce.se: SV: [LARTC] TEQL: 2 Mbit eth1 + 2Mbit eth2 = 1Mbit teql0]
Date: Wed, 11 Oct 2000 10:36:00 +0000	[thread overview]
Message-ID: <marc-lartc-98373938216773@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938216771@msgid-missing>

<PRE>On Tue, Oct 10, 2000 at 06:03:44PM +0200, bert hubert wrote:
&gt;<i> On Tue, Oct 10, 2000 at 04:21:06PM +0200, Daniel Bergqvist wrote:
</I>&gt;<i> &gt; The logs are at <A HREF="http://www.bergqvist.se/teql/.">http://www.bergqvist.se/teql/.</A>
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; The speed is about 1.3Mbit/s.
</I>&gt;<i> 
</I>&gt;<i> There is lots of packetloss. Also, it is obvious from this dump that
</I>&gt;<i> lan_router is sending both over eth1 and eth2, but that the wan router is
</I>&gt;<i> only receiving on eth2, and not on eth1, or that your dump failed.
</I>

On second thought, there is no packet loss. This is expected behaviour, it
appears, see <A HREF="http://www.kernelnotes.de/kt/latest.html:">http://www.kernelnotes.de/kt/latest.html:</A>

Alexey Kuznetsov was critical of this explanation, and said that multipath
routing worked &quot;perfectly when you need to split load on servers talking to
enough large number of clients. Any
     http server is good example.&quot; He added that Andi's suggestion of the
existing eql, teql and bonding devices, would introcude &quot;even worse problem
of strong tcp reordering. Actually,
     experiments show that load balancing works only in the situations, when
congestion window is bounded by 3 packets. If it is not made artificially,
it occurs automatically on each connection
     after some amount of excessive retransmissions. Total single TCP
connection throughput is never better in this case. Actually, it hints to
the thought that &quot;true load blalancing&quot; has to
     involve tracking connections and avoiding reordering TCP packets.&quot;
There was no reply to this, but there was a bit of implementation discussion
elsewhere, along the lines of Andi's
     explanations. 

----

You might consider using google a bit to find out about packet reordering -
packets arrive out of sequence on eth1 and eth2, which the kernel interprets
as packetloss.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet


</PRE>

      parent reply	other threads:[~2000-10-11 10:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-10 14:21 SV: [daniel@netatonce.se: SV: [LARTC] TEQL: 2 Mbit eth1 + 2Mbit eth2 = 1Mbit teql0] Daniel
2000-10-10 16:03 ` bert
2000-10-11 10:36 ` bert [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=marc-lartc-98373938216773@msgid-missing \
    --to=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.