Re: bandwidth for bkbits.net (good news)

From: Pascal Schmidt (der.eremit_at_email.de)
Date: 08/31/03

  • Next message: Andre Tomt: "Re: [PATCH] check_gcc for i386" 
    To: Jörn Engel <joern@wohnheim.fh-wedel.de>
Date:	Sun, 31 Aug 2003 00:58:33 +0200

    On Sat, 30 Aug 2003 18:20:11 +0200, you wrote in linux.kernel:

    > In order to control incoming traffic, it is easiest to look at tcp.
    > udp can work similarly, but it doesn't have to. To throttle the
    > stream of tcp packets, you could simply throw away the acks and the
    > sending side will reduce it's speed. So you have to measure one
    > stream and control a related but different one. Maybe this is
    > possible, not sure.

    All you have to do is drop the incoming packets if they exceed
    a certain bandwidth. That will stop the corresponding ack automatically
    since your TCP stack won't even see the packet.

    I'm doing this on my ISDN line to limit the rest of the house to one
    third of the bandwidth even if they're all busy downloading tons of
    warez. I'm paying, I want the bandwidth when I need it. They can get
    it all when there's no traffic for my machine.

    No problem with the HTB queueing discipline.

    [...]
    > Third, there is the problem transition from continuous streams to
    > discrete packets, when bandwidth is low. It doesn't take a huge
    > amount of large packets to create enough latency for your sad VOIP.

    Yes, latency is a problem if you want to saturate your bandwidth. It is
    easy to guarantee some bandwith for latency critical stuff - just
    don't give out that piece of bandwith to something else. Of course,
    then most of the time that piece is wasted... and it doesn't help with
    problems somewhere along the net.

    > And fourth, the possibility of resonance frequency. If measurement
    > and/or shaping intervals are too long and match nicely to the travel
    > time to one of your peers, you are back at point three.

    Dunno about that one. 

    -- 
Ciao,
Pascal
-
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: Andre Tomt: "Re: [PATCH] check_gcc for i386"

    Relevant Pages

    • Many Output Drops in a serial line
      ... configure it to have 70% of bandwidth for this traffics. ... I suppose the Citrix traffics will have at least 70% of bandwidth. ... Router#show policy-map interface s0/1 ... 67471882 packets, 10015898781 bytes ...
      (comp.dcom.sys.cisco)
    • Re: How to start Ethereal capture at network usage threshold?
      ... To monitor bandwidth you must capture ALL packets on the network. ... If you want to monitor between certain times you may need to use Windows Task ...
      (microsoft.public.windows.server.networking)
    • Re: Confused About Net Neutrality
      ... Don't websites pay based on the amount of bandwidth they need ... transmitting those packets both way through their ... BordersBooks look like a more responsive site) because BordersBooks ...
      (comp.dcom.telecom)
    • Re: How do I slow down my network?
      ... > I'm working with a Java client/server app. ... so bandwidth is virtually unlimited. ... > individual packets, so I can't figure out where to insert the delay. ... There is a freeware app on Linux called "nistnet". ...
      (comp.lang.java.programmer)
    • Re: Calculating bandwidth Requirements
      ... know that for UDP packets it's generally around 48 bytes per packet. ... The best way to measure actual bandwidth is to sniff your network using tools ... Divide this by the bitrate of your ... > This would guarantee at least 256k (4 audio connections) for your audio ...
      (microsoft.public.windowsmedia.server)