Re: [LARTC] SFQ

Re: [LARTC] SFQ

[Don Cohen]

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/

Re: [LARTC] SFQ

[bert hubert]

On Tue, Dec 11, 2001 at 11:50:12PM -0800, Don Cohen wrote:

>  > > 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?

	 case __constant_htons(ETH_P_IP):
        {
                struct iphdr *iph = skb->nh.iph;
                h = iph->daddr;
                h2 = iph->saddr^iph->protocol;
                if (!(iph->frag_off&htons(IP_MF|IP_OFFSET)) &&
                    (iph->protocol = IPPROTO_TCP ||
                     iph->protocol = IPPROTO_UDP ||
                     iph->protocol = IPPROTO_ESP))
                        h2 ^= *(((u32*)iph) + iph->ihl);
                break;
	}

In case of ipv4:
	destination address
	source address
	ip protocol 
	source port/dest port tuple

I missed the fact that the first 4 octects of the IP sub-protocol header
were include in (u32).

> 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?

Read the HOWTO. Scp doesn't set the 'minimum delay' flag.

Regards,

bert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
Trilab                                 The Technology People
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet

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

[LARTC] SFQ

[Martin Krejcirik]

Hi,

could anybody enlighten me how SFQ is supposed to work, please ?

Consider this simple script:

tc qdisc add dev eth0 root handle 1: htb default 1 r2q 10 
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1Mbit ceil 1Mbit

tc qdisc add dev eth0 parent 1:1 sfq perturb 120
#tc qdisc add dev eth0 parent 1:1 pfifo limit 100

tc filter add dev eth0 parent 1:0 protocol ip prio 200 u32 \
   match ip dst 192.168.1.1 flowid 1:1

tc filter add dev eth0 parent 1:0 protocol ip prio 200 u32 \
   match ip dst 192.168.1.2 flowid 1:1


A single class limited to 1Mbit, sfq or pfifo attached to it and two 
filters.

I try to send some traffic from localhost to above two IPs, but I see 
absolutely no difference, whether I use sfq or pfifo qdisc. I thought 
when I send say 1.2Mbit UDP to 192.168.1.1, then ping to 192.168.1.2 
should be low (go through the other queue), but this is not happening.

Or when I send 5Mbit/s to one IP and then try ftp to the other, I get 
almost nothing through, I thought this was that was SFQ supposed to prevent ?

Could anybody describe some scenario, where I can see difference between 
sfq and fifo, please ?

thanks,
bye
__________________________________________________
Martin Krejcirik <mk@krej.cz>, PGP KeyID: B030351D



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