From mboxrd@z Thu Jan 1 00:00:00 1970 From: "sufcrusher" Date: Tue, 12 Nov 2002 23:11:07 +0000 Subject: Re: [LARTC] Extremely inaccurate results using either TBF or HTB MIME-Version: 1 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01C28AA9.29A7BCC0" Message-Id: List-Id: References: In-Reply-To: To: lartc@vger.kernel.org This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C28AA9.29A7BCC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This worked miracles for me: change /usr/src/linux/include/net/pkt_sched.h PSCHED_CLOCK_SOURCE to PSCHED_CPU if you have a cpu with timestamp counter (TSC) that will give you Mhz timer granularity. (don't forget to recompile of course) Jannes Faber ----- Original Message -----=20 From: Dan Farino=20 To: lartc@mailman.ds9a.nl=20 Sent: Tuesday, November 12, 2002 9:57 AM Subject: [LARTC] Extremely inaccurate results using either TBF or HTB Hi everyone, I am getting extremely inaccurate results from my setup: - RedHat 8.0 on a Compaq ProLiant 1600, dual PII/450, Intel Dual 100 = NIC - I've tried both SMP and non-SMP kernels. - I'm using the updated tc from the HTB home page. - I'm using the HTB that comes with the RH8 kernel. Here's what's happening. If I, for instance: tc qdisc add dev eth2 root tbf rate 1.9mbit buffer 20Kb/8 limit = 15Kb Then my download rate goes at 360,000 bytes/s, which, by my = calculations, is 2.77mbit. I am using Win2k perfmon to test the speed. = The line is flat and the speed is very consistent (consistently *wrong*, = unfortunately.) Immediately after, I do: tc qdisc change dev eth2 root tbf rate 1.8mbit buffer 20Kb/8 = limit 15Kb My download speed is then 243,000 bytes/s, or 1.85mbit. Again, very = flat, consistent line. I have played with the parameters on both TBF and HTB in many = different configurations. I always seem to have a large jump between = 1.8-1.9. I can't find any number between those two that will actually = produce a 2mbit limit. I know 1.85 is close to 2.0, but is this the = expected margin of error? (Then again, 2.77 isn't close to 1.9 at all, = so I hope not!) Has anyone else experienced anything like this? Thank you very much for any help you can provide! Dan Farino Sr. System Engineer Stamps.com, Inc. Santa Monica, CA ------=_NextPart_000_0031_01C28AA9.29A7BCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This worked miracles for = me:

change=20 /usr/src/linux/include/net/pkt_sched.h
PSCHED_CLOCK_SOURCE to = PSCHED_CPU if=20 you have a cpu with timestamp
counter (TSC) that will give you Mhz = timer=20 granularity.

(don't forget to recompile of = course)

Jannes Faber

----- Original Message -----
From:=20 Dan = Farino=20
To: lartc@mailman.ds9a.nl

Sent: Tuesday, November 12, = 2002 9:57=20 AM

Subject: [LARTC] Extremely = inaccurate=20 results using either TBF or HTB

Hi = everyone,

I am getting extremely = inaccurate results from my setup:

- RedHat 8.0 on a = Compaq=20 ProLiant 1600, dual PII/450, Intel Dual 100 NIC

- I=92ve tried both = SMP and=20 non-SMP kernels.

- I=92m using the = updated tc from=20 the HTB home page.

- I=92m using the HTB = that comes=20 with the RH8 kernel.

Here=92s what=92s = happening. If I,=20 for instance:

tc=20 qdisc add dev eth2 root tbf rate 1.9mbit buffer 20Kb/8 limit=20 15Kb

Then my download rate = goes at=20 360,000 bytes/s, which, by my calculations, is 2.77mbit. I am using = Win2k=20 perfmon to test the speed. The line is flat and the speed is very = consistent=20 (consistently *wrong*, = unfortunately=85)

Immediately after, I=20 do:

tc=20 qdisc change dev eth2 root tbf rate 1.8mbit buffer 20Kb/8 limit=20 15Kb

My download speed is = then=20 243,000 bytes/s, or 1.85mbit. Again, very flat, consistent=20 line.

I have played with the = parameters on both TBF and HTB in many different configurations. I = always seem=20 to have a large jump between 1.8-1.9. I can=92t find any number = between those=20 two that will actually produce a 2mbit limit. I know 1.85 is close to = 2.0, but=20 is this the expected margin of error? (Then again, 2.77 isn=92t close = to 1.9 at=20 all, so I hope not!)

Has anyone else = experienced=20 anything like this?

Thank you very much = for any help=20 you can provide!

Dan=20 Farino

Sr. = System=20 Engineer

Stamps.com,=20 Inc.

Santa=20 Monica,=20 CA

------=_NextPart_000_0031_01C28AA9.29A7BCC0-- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/