All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Intercom - Roberto Ravetti" <rravetti@itc.com.ar>
To: lartc@vger.kernel.org
Subject: [LARTC] Bandwidth Restrictions in Linux
Date: Thu, 23 Jan 2003 21:59:00 +0000	[thread overview]
Message-ID: <marc-lartc-104335929011822@msgid-missing> (raw)

We are ISP and we give Internet Wireless Outdoor Service . The Base Station
works in 802.11b and it is connected with a Linux Mandrake Server that make
NAT.

Besides the linux Server limit the bandwidth of each Wireless Client, per
IP, using an aplication called Traffic Control with CBQ rules. The bandwidth
that we are limit is at 32Kb, 48Kb, 64Kb, 72Kb, 96Kb and 128Kb. We have only
26 clients, son we are limiting only 26 Ip numbers at those bandwith.

My topology wireless is: Linux Server connected directly with an UTP
CrossOver Cable to the AP, and from the AP to the wireless client.

The problem I have with CBQ is that for moments I have delay of aprox. 2 or
3 seconds with pings from the Linux Server to some client that are not
making any traffic and in that moment if I ping from that client to the AP
the delay is only 3ms (that is correct, so the problem is not the wireless
link). In a normal condition the ping between the server and the Client
would must be around 20 ms, as in several times that I ping to a client that
besides it is making traffic and the delay is normal. But sometimes it is
not.

For example:
The following is a ping to a client that has limited to 72Kbps.. in this
moments he is not making any traffic in the internet, the normals delay time
of ping would be around 6 ms... but in stead of look that response time....
The pings varies from 4ms up to 2 seconds... and I promisse you that he is
not trafficking anything..

64 bytes from 192.168.8.18: icmp_seq=0 ttl\x128 time=1.479 sec
64 bytes from 192.168.8.18: icmp_seq=1 ttl\x128 time=1.179 sec
64 bytes from 192.168.8.18: icmp_seq=2 ttl\x128 time=1.329 sec
64 bytes from 192.168.8.18: icmp_seq=4 ttl\x128 time=4.078 msec
64 bytes from 192.168.8.18: icmp_seq=6 ttl\x128 time\x12.622 msec
64 bytes from 192.168.8.18: icmp_seq=7 ttl\x128 time\x10.002 msec
64 bytes from 192.168.8.18: icmp_seq=8 ttl\x128 timea0.729 msec
64 bytes from 192.168.8.18: icmp_seq=9 ttl\x128 timev9.707 msec
64 bytes from 192.168.8.18: icmp_seq\x10 ttl\x128 timex8.533 msec
64 bytes from 192.168.8.18: icmp_seq\x11 ttl\x128 time™2.062 msec
64 bytes from 192.168.8.18: icmp_seq\x12 ttl\x128 time™9.109 msec
64 bytes from 192.168.8.18: icmp_seq\x13 ttl\x128 time=1.184 sec
64 bytes from 192.168.8.18: icmp_seq\x14 ttl\x128 time=1.009 sec
64 bytes from 192.168.8.18: icmp_seq\x15 ttl\x128 time=1.359 sec

So I modify the INI files of the CBQ, and I give her 128Kbps and the pings
now are normal.... 6ms, 4ms, 10ms... The following is the file I modify...

DEVICE=eth1,10mbit,1mbit
RATE\x128Kbit
WEIGHT\x12Kbit
PRIO=5
BOUNDED=yes
ISOLATED=yes
RULE\x192.168.8.11
RULE\x192.168.8.29
RULE\x192.168.8.15
RULE\x192.168.8.14
RULE\x192.168.8.39
RULE\x192.168.8.23
RULE\x192.168.8.18
RULE\x192.168.8.19

You can see I add ip 192.168.8.18 to that list of IP and to that
bandwidth...

May the problem is the variety of bandwith I have or with the lowest
bandwith ( <128Kbps) ...?
May the problem is the amount of connections that CBQ have to control...?
May the problem is saturate of the CBQ's queue ...?
May the problem is some type of hardware problem in the Server (I have a
Pentium III 750Mhz - 128 Mb RAM and 20 Gbyte HHD)...?
Someone told me use HTB or TBF which is better.. can the one be in the
certain thing?

I will thank any kind of comments.

Bye
------------------------------------
Roberto Ravetti
Intercom I.S.P
Gerente de Servicios
mailto: rravetti@itc.com.ar
Te: (54) 3571 427 777
Rio Tercero - Cordoba - Argentina
------------------------------------






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

             reply	other threads:[~2003-01-23 21:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-23 21:59 Intercom - Roberto Ravetti [this message]
2003-01-24  9:08 ` [LARTC] Bandwidth Restrictions in Linux ISC Robert Kryczalo
2003-01-24 15:16 ` Intercom - Roberto Ravetti
2003-01-24 18:57 ` ISC Robert Kryczalo
2003-01-25  8:43 ` ISC Robert Kryczalo
2003-01-27  5:38 ` S Mohan
2003-01-27 14:03 ` Mathieu Deziel
2003-01-27 14:52 ` Tushar Gupta
2003-01-27 15:15 ` Debreczeni Peter

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-104335929011822@msgid-missing \
    --to=rravetti@itc.com.ar \
    --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.