Re: bandwidth for bkbits.net (good news)

From: Jörn Engel (joern_at_wohnheim.fh-wedel.de)
Date: 08/31/03

  • Next message: Dan Kegel: "LMbench as gcc performance regression test?"
    Date:	Sun, 31 Aug 2003 08:30:20 +0200
    To: Pascal Schmidt <der.eremit@email.de>
    
    

    On Sun, 31 August 2003 00:58:33 +0200, Pascal Schmidt wrote:
    >
    > 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.

    You've cut away the part where I explained that you don't want to
    throw away the incoming packet. Yes, the stupid approach works, but
    it is still stupid.

    > 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.

    But latency just went boom. On your side, your packets will come out
    quickly because the queue is short. But on your ISP's side, there is
    a single queue for both your and the warez' traffic. Your packets
    will get thrown away just as much, as theirs.

    > 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...

    This works if your latency requirements are moderate or the pipe is
    big. Assume 5ms and ISDN and you have a window of 400 Bytes roughly.
    Each time you happen to receive 400 Bytes of packets at the same time,
    you hear a pause. A single large packet is more than that. Oops!

    For Larry's T1 line, the numbers naturally go up, but it still doesn't
    take a huge amount of packets.

    > and it doesn't help with problems somewhere along the net.

    Compared to ISDN or T1, the net usually has big pipes and people tend
    to care about low latency, so that problem doesn't even exist compared
    with the receiving end.

    Jörn

    -- 
    Simplicity is prerequisite for reliability.
    -- Edsger W. Dijkstra
    -
    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: Dan Kegel: "LMbench as gcc performance regression test?"

    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)