All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dan Farino" <DFarino@Stamps.com>
To: lartc@vger.kernel.org
Subject: RE: [LARTC] Extremely inaccurate results using either TBF or HTB
Date: Wed, 13 Nov 2002 07:06:09 +0000	[thread overview]
Message-ID: <marc-lartc-103717127014080@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103709153501207@msgid-missing>

Stef,

I solved my problem by changing PSCHED_CLOCK_SOURCE to PSCHED_CPU in
/usr/src/linux/include/net/pkt_sched.h

My graph is now a nice smooth diagonal line as I increase the bandwidth
in increments as I did before.

Thanks for you help on this one. You site has been a tremendous help in
getting me up and running.

Take care,

Dan Farino
Sr. System Engineer
Stamps.com, Inc.
Santa Monica, CA


-----Original Message-----
From: Stef Coene [mailto:stef.coene@docum.org] 
Sent: Tuesday, November 12, 2002 10:07 AM
To: Dan Farino; lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Extremely inaccurate results using either TBF or
HTB

On Tuesday 12 November 2002 17:58, Dan Farino wrote:
> Hi Stef,
>
> Thanks for the reply! However, I think the gap is way too large to be
> explained by overhead, etc.
>
> Here are the results from some other tests. I started with:
> tc qdisc add dev eth2 root tbf rate 1.9mbit buffer 20Kb/8 limit 15Kb
>
> Here are the average transfer rates measured over approx 20 seconds
> (again according to PerfMon) as I change the "1.9mbit" to other values
> while performing a large download:
>
> Mbit	Kb/s
> -----	------
> 2.5	360
> 2.0	360
> 1.9	360
> 1.8	240
> 1.5	240
> 1.4	240
> 1.3	180
> 1.2	180
>
> The lines really are that flat. There is nothing resembling the graphs
> on your site. Mine has the low-res, stair-step effect that you can see
> by graphing the above numbers.
>
> I can't seem to find any "mbit" number that will actually produce a
cap
> at exactly 2mbit.
>
> I will try a both different type NIC and Debian at some point today.
What NIC are you using ?

> Thanks for your help!
No problem.  I can send you my scripts that I use the record the
bandwidth 
usage.  Some of them can be found on www.docum.org.  Basically, I create
a 
iptables chain for each traffic stream I want to monitor.  I record the 
counters each second and calculates the bandwdith.  
I have some scripts that executes a htb script, starts the needed flows,

calculates the bandwidth, if the bandwidth is stable : record the
bandwidth, 
restart the proces with a different setting.
After some time, you have it for each rate so you can create a nice
graph.


Stef

-- 

stef.coene@docum.org
 "Using Linux as bandwidth manager"
     http://www.docum.org/
     #lartc @ irc.oftc.net

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2002-11-13  7:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-12  8:57 [LARTC] Extremely inaccurate results using either TBF or HTB Dan Farino
2002-11-12 16:09 ` Stef Coene
2002-11-12 16:58 ` Dan Farino
2002-11-12 18:07 ` Stef Coene
2002-11-12 23:11 ` sufcrusher
2002-11-13  7:02 ` Dan Farino
2002-11-13  7:06 ` Dan Farino [this message]
2002-11-13  8:21 ` Stef Coene

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=marc-lartc-103717127014080@msgid-missing \
    --to=dfarino@stamps.com \
    --cc=lartc@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.