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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ