netdev - Re: HTB/HSFC shaping precision

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20071120211258.M55249@visp.net.lb>
Date:	Tue, 20 Nov 2007 23:21:02 +0200
From:	"Denys Fedoryshchenko" <denys@...p.net.lb>
To:	Jarek Poplawski <jarkao2@...pl>
Cc:	hadi@...erus.ca, netdev@...r.kernel.org
Subject: Re: HTB/HSFC shaping precision

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.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html