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: <200901121030.15782.denys@visp.net.lb>
Date:	Mon, 12 Jan 2009 10:30:15 +0200
From:	Denys Fedoryschenko <denys@...p.net.lb>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	Jarek Poplawski <jarkao2@...il.com>,
	Jorge Bastos <mysql.jorge@...imal.pt>, netdev@...r.kernel.org,
	bugme-daemon@...zilla.kernel.org
Subject: Re: [BUG #12364] Re: HTB - very bad precision? HFSC works fine!	2.6.28

On Monday 12 January 2009 09:27:10 Patrick McHardy wrote:
> Jarek Poplawski wrote:
> > On Fri, Jan 09, 2009 at 10:47:11AM -0000, Jorge Bastos wrote:
> >> For my case this has any matter?
> >
> > I guess not: it's about better resolution, so e.g. when 2% matters.
> > And it matters for a desktop box, if you care about responsiveness.
>
> Just wondering since this thread is very hard to follow with all
> the top postings, incorrect timestamps on mails etc. - has there
> been a resolution to this problem?

1000HZ made situation much better. But i'm still debugging the case.
Difficult part, there is many small packets, and i didn't found any reference 
how Cisco count packets. I know that HTB counts with Ethernet header, but 
maybe Cisco catching something else.
One thing i can say, HFSC more precise than HTB for now.
HFSC started to be more precise after changing to 1000HZ, but i had system 
crashed yesterday, while applying new rules. Probably it is old bug with 
timers, which we debugged before. It is rare case now, but seems happened 
yesterday.
But anyway, i will try to test today again, and compare with old results.

In numbers:
Before HFSC was reaching 60-61Mbps, when set 57. Now set 60, and now rarely 
reach 61. Why i'm not happy about that, because it is mrtg results, which is 
averaged by 5 minutes. I understand if there can be short bursts for 61 megs, 
but why average(for long period of time) results become higher?
I think misprecision must vary to both side, when it becomes higher for few 
(milli?)seconds, it must become lower also for same time.
--
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