From: Jason Boxman <jasonb@edseek.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SEPARATING VOIP AND SURFING
Date: Tue, 16 Nov 2004 17:08:02 +0000 [thread overview]
Message-ID: <200411161208.02730.jasonb@edseek.com> (raw)
In-Reply-To: <20041109175203.11372.qmail@web41524.mail.yahoo.com>
On Tuesday 16 November 2004 09:53, Andy Furniss wrote:
<snip>
> I would do a bit more work to priorotise dns/empty acks/small tcp etc.
> as well as VOIP, then give them a class with plenty of rate spare and
> make bulk borrow. This would mean that each user would notice a bit less
> the fact they have hardly any bandwidth (if that's the case).
Is it really helpful to initially prioritize all TCP handshake packets into
the highest priority? After you walk through your list of traffic and
reclassify flows based on your QoS policy, handshake packets for flows that
matter ought to be properly accounted for. Likewise for flows that aren't
that interesting. For all other flows only having the handshake prioritized
and all else going to a default class can't be that beneficial?
> Choosing a queue length should really be related to link speed - but you
> can't do this if you have lots of queues whose rate are variable. What
> to choose depends on typical and I suppose worst case traffic situation
> for your LAN.
I have not noticed in any of the available documentation I have found any
discussion on how to choose an appropriate queue length. The shorter the
queue, the sooner applications become aware of a bandwidth bottleneck? I
guess the queue just helps deal with short term busts? What rate was sfq's
128p queue originally targeted at? 100Mbps Ethernet?
<snip>
> I think these differences are too small to be representative. One packet
> could add 12kbit to a counter instantaneously and how you measure can
> decieve. For one really low rate class the way HTB uses DRR to even out
> fairness for different sized packets could, I think cause short term
> variations. P2P traffic is mixed packet size and quite variable
> depending on peers - so recreating behavior for tests may be hard. I
> don't think queue length is involved here.
The difference for that leaf with sfq versus pfifo was pretty consistent. I
should test with different queue lengths for pfifo.
Thanks.
--
Jason Boxman
Perl Programmer / *NIX Systems Administrator
Shimberg Center for Affordable Housing | University of Florida
http://edseek.com/ - Linux and FOSS stuff
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2004-11-16 17:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-09 17:52 [LARTC] SEPARATING VOIP AND SURFING Ricardo Soria
2004-11-15 12:42 ` Andy Furniss
2004-11-16 1:06 ` Ricardo Soria
2004-11-16 1:33 ` Jason Boxman
2004-11-16 14:53 ` Andy Furniss
2004-11-16 17:08 ` Jason Boxman [this message]
2004-11-17 1:15 ` Andy Furniss
2004-11-17 22:36 ` Ricardo Soria
2004-11-18 0:44 ` Andy Furniss
2004-11-18 1:08 ` Rick Marshall
2004-11-23 15:57 ` Ricardo Soria
2004-11-24 19:08 ` Ricardo Soria
2004-11-24 22:19 ` Ricardo Soria
2004-11-24 22:42 ` Rick Marshall
2004-11-25 10:48 ` Andy Furniss
2004-11-25 15:55 ` Andy Furniss
2004-11-28 23:50 ` Ricardo Soria
2004-11-29 21:53 ` Andy Furniss
2004-11-30 2:07 ` Ricardo Soria
2004-11-30 2:39 ` Andy Furniss
2004-11-30 12:23 ` Andy Furniss
2004-12-01 15:16 ` Ricardo Soria
2004-12-01 21:57 ` Andy Furniss
2004-12-06 22:54 ` Ricardo Soria
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=200411161208.02730.jasonb@edseek.com \
--to=jasonb@edseek.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.