From: Daniel Bergqvist daniel@netatonce.se
To: lartc@vger.kernel.org
Subject: SV: SV: [daniel@netatonce.se: SV: [LARTC] TEQL: 2 Mbit eth1 + 2Mbit eth2 = 1Mbit teql0]
Date: Wed, 11 Oct 2000 12:22:58 +0000 [thread overview]
Message-ID: <marc-lartc-98373938216774@msgid-missing> (raw)
<PRE>Now I understand why it doesn't work.
I will look into it and try to find a solution.
Thanks for all help
Daniel
><i> -----Ursprungligt meddelande-----
</I>><i> Från: <A HREF="mailto:lartc-admin@mailman.ds9a.nl">lartc-admin@mailman.ds9a.nl</A>
</I>><i> [mailto:<A HREF="mailto:lartc-admin@mailman.ds9a.nl">lartc-admin@mailman.ds9a.nl</A>]För bert hubert
</I>><i>
</I>><i> On second thought, there is no packet loss. This is expected behaviour, it
</I>><i> appears, see <A HREF="http://www.kernelnotes.de/kt/latest.html:">http://www.kernelnotes.de/kt/latest.html:</A>
</I>><i>
</I>><i> Alexey Kuznetsov was critical of this explanation, and said that multipath
</I>><i> routing worked "perfectly when you need to split load on servers
</I>><i> talking to
</I>><i> enough large number of clients. Any
</I>><i> http server is good example." He added that Andi's suggestion of the
</I>><i> existing eql, teql and bonding devices, would introcude "even
</I>><i> worse problem
</I>><i> of strong tcp reordering. Actually,
</I>><i> experiments show that load balancing works only in the
</I>><i> situations, when
</I>><i> congestion window is bounded by 3 packets. If it is not made artificially,
</I>><i> it occurs automatically on each connection
</I>><i> after some amount of excessive retransmissions. Total single TCP
</I>><i> connection throughput is never better in this case. Actually, it hints to
</I>><i> the thought that "true load blalancing" has to
</I>><i> involve tracking connections and avoiding reordering TCP packets."
</I>><i> There was no reply to this, but there was a bit of implementation
</I>><i> discussion
</I>><i> elsewhere, along the lines of Andi's
</I>><i> explanations.
</I>><i>
</I>><i> ----
</I>><i>
</I>><i> You might consider using google a bit to find out about packet
</I>><i> reordering -
</I>><i> packets arrive out of sequence on eth1 and eth2, which the kernel
</I>><i> interprets
</I>><i> as packetloss.
</I>><i>
</I>><i> Regards,
</I>><i>
</I>><i> bert hubert
</I>><i>
</I>><i> --
</I>><i> PowerDNS Versatile DNS Services
</I>><i> Trilab The Technology People
</I>><i> 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
</I>><i>
</I>><i> _______________________________________________
</I>><i> LARTC mailing list / <A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A>
</I>><i> <A HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc">http://mailman.ds9a.nl/mailman/listinfo/lartc</A> HOWTO:
</I><A HREF="http://ds9a.nl/2.4Routing/">http://ds9a.nl/2.4Routing/</A>
</PRE>
reply other threads:[~2000-10-11 12:22 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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-98373938216774@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.