From: "Denys Fedoryshchenko" <denys@visp.net.lb>
To: Jarek Poplawski <jarkao2@o2.pl>
Cc: hadi@cyberus.ca, netdev@vger.kernel.org
Subject: Re: HTB/HSFC shaping precision
Date: Tue, 20 Nov 2007 23:21:02 +0200 [thread overview]
Message-ID: <20071120211258.M55249@visp.net.lb> (raw)
In-Reply-To: <47433CF8.70501@o2.pl>
On Tue, 20 Nov 2007 21:00:56 +0100, Jarek Poplawski wrote
> Denys Fedoryshchenko wrote, On 11/20/2007 10:43 AM:
> ....
>
> > If let's say i will limit bandwidth to 1Mbps, and will try to send
packets
> > will 100Mbps speed, and will check which packets will be dropped.
>
> As a matter of fact, I wonder why you're so afraid of this dropping.
> It's usual method of auto-regulation e.g. for tcp. You've written
> latency isn't so much problem, then slightly overloading ISP's queue
> you'll always get full bandwidth, you've payed for. You didn't write
> what kind of traffic you service, but I doubt you can get rid of
> dropping everywhere: on your HTB etc. queues or on incoming traffic.
If traffic is dropped - it will be resent, a lot of energy will be wasted for
nothing. Same bytes will pass all long way around earth just because i am not
able to manage my QoS box :-)
Plus uplink bandwidth will be used for that, i am using my own protocol(it is
TCP "accelerator" for satellite communications based on NACK and "streaming"
compression, so each resend - it is few bytes more on uplink and additional
delay. Ah yes, even resend over TCP it is more delay, than if it will be
queued for few milliseconds on bottleneck.
Plus if buffer on STM-1 interface way too small - smallest spike will cause
packetlossy, and sitation can be far away from congestion. As result it will
be very difficult to reach maximum bandwidth on such link. And linux box in
this situation is magic box, which can help to save energy, hungry people and
help to use resources efficiently :-)
>
> > [...] This means something wrong or in my shaping tree configuration
> > (that time HTB) or in shaper code. Thats why i try to dig in this things
more
> > deeply.
>
> Did you try to dig at this very nice HTB page?:
> http://luxik.cdi.cz/~devik/qos/htb/
Yes, for sure. Thats what i am reading almost each day, when i dont
understand something clearly. But, my english is far away from good, so
sometimes i just misunderstand something even in good manual.
>
> Regards,
> Jarek P.
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
next prev parent reply other threads:[~2007-11-20 21:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-19 8:55 HTB/HSFC shaping precision Denys Fedoryshchenko
2007-11-19 16:24 ` jamal
2007-11-20 9:43 ` Denys Fedoryshchenko
2007-11-20 20:00 ` Jarek Poplawski
2007-11-20 21:21 ` Denys Fedoryshchenko [this message]
2007-11-21 9:47 ` Jarek Poplawski
2007-11-21 10:31 ` Denys Fedoryshchenko
2007-11-21 15:06 ` jamal
2007-11-22 2:07 ` Ryousei Takano
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=20071120211258.M55249@visp.net.lb \
--to=denys@visp.net.lb \
--cc=hadi@cyberus.ca \
--cc=jarkao2@o2.pl \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).