Re: bandwidth for bkbits.net (good news)

From: Jeff Sipek (jeffpc_at_optonline.net)
Date: 08/31/03

  • Next message: Michael Frank: "2.6.0-test4: Tested the Power Management Update" 
    Date:	Sat, 30 Aug 2003 22:18:37 -0400
To: Andrea Arcangeli <andrea@suse.de>, Pascal Schmidt <der.eremit@email.de>

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Saturday 30 August 2003 21:39, Andrea Arcangeli wrote:
    > On Sun, Aug 31, 2003 at 03:05:37AM +0200, Pascal Schmidt wrote:
    > > On Sat, 30 Aug 2003, Larry McVoy wrote:
    > > >> All you have to do is drop the incoming packets if they exceed
    > > >> a certain bandwidth.
    > > >
    > > > If you think we haven't done that, think again.
    > > >
    > > > We're at the wrong end of the pipe to do that, I'm pretty sure that
    > > > what you are describing simply won't work.
    > >
    > > In a way, you're on the right end of the pipe because the system
    > > that does your traffic shaping is part of the general network, viewed
    > > from the machines behind the shaper.
    > >
    > > Dropping the packets means that the sending side, at least if we're
    > > talking TCP, will throttle its sending rate. But, depending on the
    > > distance in hops to the sender, it may take up to a few seconds for
    > > this to kick in. So I guess that's why it doesn't work for your
    > > VoIP case - the senders don't notice fast enough that they should
    > > slow down.
    >
    > that's because you don't limit the bkbits.net to a fixed rate. If you
    > want to give priorities, it won't work well because it takes time to be
    > effective, but if you rate limit hard both ways it has to work, unless
    > you're under syn-flood ;) The downside is that you will waste bandwith
    > (i.e. you will hurt the bkbits.net service even when you don't use
    > voip), but it will work.

    How about giving something to voip as a hard limit and then using some shaper
    to give it more if needed.

    Jeff.

    - --
    *NOTE: This message is ROT-13 encrypted twice for extra protection*
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.3 (GNU/Linux)

    iD8DBQE/UVsBwFP0+seVj/4RAkmpAJ9YwjdPLZZsdD7fCRDRHyS+JrJnkgCdG/sc
    sr5Mqx5Qii//AQPepCqHDcw=
    =RoPR
    -----END PGP SIGNATURE-----

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Michael Frank: "2.6.0-test4: Tested the Power Management Update"

    Relevant Pages

    • Re: bandwidth for bkbits.net (good news)
      ... outgoing acks and their incoming packets for every connection but voip ... but your voip will work. ... and the reason everything makes perfect sense is that ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: bandwidth for bkbits.net (good news)
      ... Assume the guaranteed bandwidth is much lower ... so voip will take it over as much as it can. ... think it's a matter of "if it works or not", I think it's a matter of ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 50% CPU user usage but top doesnt list any CPU unfriendly task
      ... >> The interesting program you mention is the VoIP application. ... >> multithreaded and is every thread using a little bit of CPU? ... "Debugging is twice as hard as writing the code in the first place. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: bandwidth for bkbits.net (good news)
      ... >> voip), but it will work. ... downside of limiting the bandwith available to bkbits users even when ... software rate limiting with the solution I proposed, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)