Re: Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-27 Thread Andy Furniss
Leo Huang wrote:
What you have said makes absolute sense to me. However, I only
"reserved" 136Kbit for the VoIP traffic, there are 44Kbit available
even we assume the 180Kbit is the maximum. Why doesn't HTB allocate
the 44Kbit to the class for ping traffic, which only require rate
4Kbit and 0.5 Kbit?
I don't quite know what you mean here. If there was a queue of ICMP 
traffic then htb would give it 44kbit. If you want icmp times to be 
lower then there are things you can do like setting quantum size on htb 
leafs and setting a define - hysteris in the source code to 0, this 
makes it more accurate.

Andy.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-27 Thread Jason Boxman
On Wednesday 27 April 2005 14:56, Andy Furniss wrote:

> It is very easy to make it look like it though, just start an upload
> while downloading something and watch your down rate fall apart. This is
> TCP and the fact that adsl modems tend to have huge buffers not the
> link. The first thing to do when making a shaping script is priorotise
> empty acks - then uploading doesn't trash your download.

As much.

If you're fully saturating your downstream, too, you're queuing on your ISP 
and then bulk downloading interferes with interactive traffic.

The joys of having an asymmetrical connection, eh?

___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-27 Thread Andy Furniss
Taylor, Grant wrote:
Err, since when is ADSL half duplex ? News to me :)
I think you'll find if you read up on (A)DSL that it is in fact full
duplex. Going from memory, the frequency range from 25Khz up to 1.1Mhz is
broken up into a fairly large number of subcarriers (52 I think ?) and
some subcarriers are used for the downstream direction (the majority in
the case of ADSL, or half of them for SDSL) while the rest are used for
the upstream direction.

*nod*  This is indeed the case.
Because it uses frequency division muliplexing for each carrier to exist
on the line simultaneously there is no need to do any time division
multiplexing between upstream and downstream.

I'm not sure why ADSL is simplex / half duplex as it seems that it 
should be able to be (full) duplex.  I do know that the the types of 
service that have been seen here in my town are indicative of simplex 
traffic.  I don't know if this is a limit that the LEC is putting in 
place or not.  Also many a provider that I've talked to have agreed that 
ADSL in particular is simplex.  If you are talking SDSL the circuit is 
indeed duplex.

Besides, even a normal modem dialup connection is full duplex, it's
unlikely ADSL would take a backwards step from that ;-)

Keep in mind that 33.6 kbps modems download at 33.6 kbps and upload at 
33.6 kbps where as 56 kbps modems download at 56 kbps and upload at 28.8 
kbps.  One reason that ADSL my be simplex is that simplex technology is 
easier to implement and thus has more features or speed on a given 
circuit.  Thus ADSL could be simplex allowing for a wider band for 
download sacrificing some of the upload bandwidth / capabilities.  In a 
residential / small office environment this is typically not a problem.

Again, I have no paperwork in front of me to back this up, just my 
experience and conversations with half a dozen or more people in the ISP 
business.
I've never heard of half duplex adsl - your modem should tell you up and 
down sync rates and that's what you've got.

It is very easy to make it look like it though, just start an upload 
while downloading something and watch your down rate fall apart. This is 
TCP and the fact that adsl modems tend to have huge buffers not the 
link. The first thing to do when making a shaping script is priorotise 
empty acks - then uploading doesn't trash your download.

Andy.
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-27 Thread Taylor, Grant
Err, since when is ADSL half duplex ? News to me :)
I think you'll find if you read up on (A)DSL that it is in fact full
duplex. Going from memory, the frequency range from 25Khz up to 1.1Mhz is
broken up into a fairly large number of subcarriers (52 I think ?) and
some subcarriers are used for the downstream direction (the majority in
the case of ADSL, or half of them for SDSL) while the rest are used for
the upstream direction.
*nod*  This is indeed the case.
Because it uses frequency division muliplexing for each carrier to exist
on the line simultaneously there is no need to do any time division
multiplexing between upstream and downstream.
I'm not sure why ADSL is simplex / half duplex as it seems that it should 
be able to be (full) duplex.  I do know that the the types of service that have 
been seen here in my town are indicative of simplex traffic.  I don't know if 
this is a limit that the LEC is putting in place or not.  Also many a provider 
that I've talked to have agreed that ADSL in particular is simplex.  If you are 
talking SDSL the circuit is indeed duplex.
Besides, even a normal modem dialup connection is full duplex, it's
unlikely ADSL would take a backwards step from that ;-)
Keep in mind that 33.6 kbps modems download at 33.6 kbps and upload at 33.6 
kbps where as 56 kbps modems download at 56 kbps and upload at 28.8 kbps.  One 
reason that ADSL my be simplex is that simplex technology is easier to 
implement and thus has more features or speed on a given circuit.  Thus ADSL 
could be simplex allowing for a wider band for download sacrificing some of the 
upload bandwidth / capabilities.  In a residential / small office environment 
this is typically not a problem.
Again, I have no paperwork in front of me to back this up, just my experience 
and conversations with half a dozen or more people in the ISP business.

Grant. . . .
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-27 Thread Simon Byrnand
> There is always the fact that ADSL is half
> duplex where as SDSL is full duplex.  You would see this as a problem if
> you were trying to download something and upload something at the same
> time.  Your circuit can only do one thing at a time thus somethi
> ng will have to wait.  You will see this if you are able to FTP a large
> file out to a system on the net fast, close to your maximum, yet your VoIP
> (SIP?) traffic will start having problems at less than the maximum rate
> that the physical link can handle.

Err, since when is ADSL half duplex ? News to me :)

I think you'll find if you read up on (A)DSL that it is in fact full
duplex. Going from memory, the frequency range from 25Khz up to 1.1Mhz is
broken up into a fairly large number of subcarriers (52 I think ?) and
some subcarriers are used for the downstream direction (the majority in
the case of ADSL, or half of them for SDSL) while the rest are used for
the upstream direction.

Because it uses frequency division muliplexing for each carrier to exist
on the line simultaneously there is no need to do any time division
multiplexing between upstream and downstream.

Besides, even a normal modem dialup connection is full duplex, it's
unlikely ADSL would take a backwards step from that ;-)

Regards,
Simon


___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-26 Thread Taylor, Grant
What you have said makes absolute sense to me. However, I only
"reserved" 136Kbit for the VoIP traffic, there are 44Kbit available
even we assume the 180Kbit is the maximum. Why doesn't HTB allocate
the 44Kbit to the class for ping traffic, which only require rate
4Kbit and 0.5 Kbit?
Some of this could be do to the fact that an ICMP echo request packet is 
extremely small.  It is quite likely that your ADSL connection has a raw 
throughput of 256 kbps.  On top of the ADSL signal is a signaling protocol, be 
it Frame Relay (older DSL circuits in my town are this) or ATM (newer DSL 
circuits), each have their own protocol overhead as well as minimum packet 
size.  So if you are sending ICMP echo request packets that are very small, 
they will have to be wrapped in the network layer (OSI layer 2) packets and 
transmitted on the ADSL line (OSI layer 1) thus growing in size.  It is quite 
likely that the size of the packets on physical layer are approaching 256 kbps 
and thus heating the physical maximum of your circuit.  There is always the 
fact that ADSL is half duplex where as SDSL is full duplex.  You would see this 
as a problem if you were trying to download something and upload something at 
the same time.  Your circuit can only do one thing at a time thus somethi
ng will have to wait.  You will see this if you are able to FTP a large file 
out to a system on the net fast, close to your maximum, yet your VoIP (SIP?) 
traffic will start having problems at less than the maximum rate that the 
physical link can handle.
Any one care to support or refute this?  I'm mainly going off of what I have 
read and discussed with others.  I'm presently going after CCNA and this is the 
answer that I would give to a client, but if there is something better or there 
is a discussion that is to be had I'm game for it.  Someone please correct me 
as I want to learn more.  ;)

Grant. . . .
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Fwd: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!

2005-04-26 Thread Leo Huang
Oops, forgot to post to the group...

-- Forwarded message --
From: Leo Huang <[EMAIL PROTECTED]>
Date: Apr 27, 2005 10:46 AM
Subject: Re: [LARTC] HTB Weird Shaping Question(Bug?). Please Help!
To: Andy Furniss <[EMAIL PROTECTED]>


Thanks Andy,

What you have said makes absolute sense to me. However, I only
"reserved" 136Kbit for the VoIP traffic, there are 44Kbit available
even we assume the 180Kbit is the maximum. Why doesn't HTB allocate
the 44Kbit to the class for ping traffic, which only require rate
4Kbit and 0.5 Kbit?

Thanks again,
Leo


On 4/27/05, Andy Furniss <[EMAIL PROTECTED]> wrote:
> Leo wrote:
>
> > In the first test, I limit the SUBCLASS_OUTRATE to 200Kbit. Both pings
> > are around 20ms before I start the VoIP services. However, once I start
> > the services, the pings jump up to 1800ms.
> >
> > In the second test, I limit the SUBCLASS_OUTRATE to 180Kbit. The pings
> > jump up to 80ms, which is perfectly acceptable.
> >
> > After a few tests, I noticed that 180Kbit is a magic number, anything
> > exceed that will generate 1800ms pings, and below it is 80ms.
> >
> > In my senario, the weird point is that the determining factor is the
> > ceiling, but not the rate. That's the "rate" for other class doesn't
> > seem to give bandwidth to packets in the corresponding class unless the
> > ceil for the 1:110 is low enough!
> >
> > I attached my script and "tc -s class show" below. I truncated part of
> > the script and the results to make it short.
> >
> > Please shine me a light!
>
> It's because the link is dsl and there are lots of overheads on each
> packet (and they vary with packet size). HTB rates are based on ip
> packet length and with lots of small packets like voip the difference
> can be alot.
>
> The 1800ms latency is not caused by a queue within htb it's in your
> modem/router because it can't send >180kbit ip level for voip.
>
> You can patch HTB and TC to make things perfect - you could set a ceil
> very close to your sync rate then. You need to know exactly what type of
> dsl you are on to find your overhead though. If your modem/router gives
> ATM cell counts you can deduce it from those.
>
> There is a very good thesis and patch info here -
>
> http://www.adsl-optimizer.dk/
>
> Andy.
>
>
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc