From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SFQ
Date: Wed, 12 Dec 2001 07:50:12 +0000 [thread overview]
Message-ID: <marc-lartc-100814354131080@msgid-missing> (raw)
re: Subject: [LARTC] SFQ working
...
> > Here different flows are distinguished by source & dest addresses and
> > source port.
> >
> > Is this right?
>
> Exactly.
>
> Regards,
>
> bert
I think this is not quite right.
Also dest port, right?
And of course protocol.
And of course lower level (eth) protocol - above applies to IPv4.
and re: > Subject: Re: [LARTC] sfq as solution to "Small ISP problems"
> > > 1: SSH - to be realtime always.
> > I don't think you want this to always be high prio - that includes scp.
>
> your'e right, only the real ssh traffic..
How do you propose to tell the difference between ssh and scp?
...
> > I think what you really want is to prevent large flows from unfairly
> > impacting small ones, and that's what sfq does. Try it and see
> > whether you get the behavior you want.
>
> Oki, I tried it. I defined two classes. "all_in" and "all_out".
> I have 2Mbit full duplex so just to be sure my que isn't ending up in the
> g703 "modem" I defined the classes to 1,900Mbit downstream and 1,000Mbit
> upstream.
> Put SFQ on both classes and tested under heavy load..
I don't understand what these classes are for or what the 2Mbit above
has to do with the 2 and 1 Gbit above.
> > If you're really in the first situation where you just want to give
> > equal service to all who are requesting it then what you really want
> > is a slight variant of sfq. If you look at the code you'll see a hash
> function that takes into consideration source and destination ip
>
> What code exactly ? I am currently using the cbq.init script version 0.6.2 .
Not that code, but kernel source for sfq in net/sched/sch_sfq.c
> > address and port and maybe other stuff. All you want to do is remove
> > all but the source IP (and then perhaps do what you can to prevent
> > source forgery!). That will give fair service among all source IP
> > addresses.
> Take a look at this:
>
> Right now my bandwidth looks like this:
>
> Total Rates: 2170.6 kbits/s
> 517.6 packets/sec
>
> Incoming rates: 1769.4 kbits/s
> 261.4 packets/sec
>
> Outgoing rates: 401.2 kbits/sec
> 256.2 packets/sec
>
> Well, we have a full duplex 2Mbit connection so this should not be a
> problem.
> Eventhough, we, based on a 265 packets test, have 28% packet loss witch is
> not good.
If you're not using up your bandwidth I don't see why you're dropping.
Do you understand that?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
next reply other threads:[~2001-12-12 7:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-12 7:50 Don Cohen [this message]
2001-12-12 9:31 ` [LARTC] SFQ bert hubert
2003-11-26 15:02 ` Martin Krejcirik
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-100814354131080@msgid-missing \
--to=don-lartc@isis.cs3-inc.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.