[LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
On Thu, 2006-07-20 at 14:56 +1000, Russell Stuart wrote: > On Wed, 2006-07-19 at 16:50 +0200, Patrick McHardy wrote: > > Please excuse my silence, I was travelling and am still catching up > > with my mails. > > Sorry. Had I realised you were busy I would of > waited. > > > > - As it stands, it doesn't help the qdiscs that use > > > RTAB. So unless he proposes to remove RTAB entirely > > > the ATM patch as it will still have to go in. > > > > Why? The length calculated by my STABs (or something similar) > > is used by _all_ qdiscs. Not only for transmission time calculation, > > but also for statistics and estimators. > > Oh. I didn't see where it is used for the time > calculation in your patch. Did I miss something, > or is that the unfinished bit? > > This is possibly my stumbling block. If you don't remove > RTAB the ATM patch as stands will be needed. Your patch > didn't remove RTAB, and you didn't say it was intended to, > so I presume it wasn't going to. It has gone quiet again. In my mind the one unresolved issue is whether Patrick intended to remove RTAB with his patch. If not, the ATM patch as it stands will have to go in. Patrick - it would be nice to hear from you. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Weird HTB behaviour in 2.6.17
Hello, On 7/28/06, Patrick McHardy <[EMAIL PROTECTED]> wrote: Right, the "problem" is related to TCP segmentation offloading (or GSO in current kernels). The card gets large chunks of data and is responsible for creating MTU-sized packets, which essentially means qdiscs get to see those large chunks of data. You can disable TSO using ethtool (but it will cost you performance) or configure your qdisc appropriately. Thanks a lot. It was exactly that. I turned the tso off and HTB is working properly. How can I know the largest chunk of data the kernel sends to the card, so that I can configure qdisc appropriately? In the last post, Jake Altchill recommended using mtu 16500 in the qdiscs, but I'm not sure whether that's a real or just a big number. Regards. -- Marlon ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] SRR qdisc
Dmitry Labutcky wrote: Hi all, I wrote new qdisc SRR (Simple Round Robin). This is just another reimplementation of round robin packets distributions. I'm not using SQF/ESFQ source code and algorithms in this scheduler. The main goal of this work is not given multistream download managers give all bandwidth resource. Please testing this: http://mordor.strace.net/sched-srr/ Haven't looked yet, but IIRC someone posted a patch on netdev for sfq to do this - possibly used jhash aswell. The man page incorrectly says sfq doesn't use dst port anyway IIRC. It would be nice to have something better than (e)sfq eg for esfq multi level - for user fairness and connection fairness within that. Preferably fair without packet reordering aswell - maybe a bit of a tall order. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Why SFQ?
S.Mehdi Sheikhalishahi wrote: Hello, Why linux users use SFQ as leaf queueing discipline instead of RED and other? We don't all - I guess alot of the examples do though. SFQ does rough fairness for individual connections within a class - nothing else does (well RED a bit). It does have less desireable aspects like perturb causing packet reordering and not using perturb means its less fair between flows. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IFB vs IMQ
Rajesh Mahajan wrote: can u please explain where IFB really place in linux network stack Is iptables rules applicable on it I don't know exactly - as for iptables rules, you can use marks if you are hooking ifb on egress as it's after netfilter. I suppose what's possible depends on your setup and what you need to do. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] questions about HFSC, VoIP and (dynamic) ingress shaping
Daniel Musketa wrote: Hello, I just found the great howto and started shaping my internet connection. The howto's last update is a liitle in the past now so I have some questions about how things are done the best way nowadays ;-) To ensure a stable and low latency voip communication I added an HFSC qdisc to device ppp0 (1 Mbit SDSL). There are two classes (by now): One for SIP and RTP and one for the rest. Question 1: I defined the voip qdisc as tc class add dev ppp0 parent 1:1 classid 1:11 \ hfsc sc umax 1500b dmax 30ms rate 500kbit ul rate 900kbit but "tc -s class show dev ppp0" shows class hfsc 1:11 parent 1:1 sc m1 0bit d 6.0ms m2 50bit \ ul m1 0bit d 0us m2 90bit Where does the "0bit d 6.0ms" come from, (what does the other stuff exactly mean) and what would be a good setting for voip traffic? I still get confused thinking about hfsc and the examples I've seen. I think it's because I can't get away from thinking about what really happens and the numbers like dmax must relate to something other than max delay, which will be related to your setup - hmm I suppose you should change the numbers to fit - see I'm confused again :-) Also the original paper and bsd docs relate to something different to linux hfsc which has link share and upper limit curves (which make it alot more useful). Just take it that any suggestions I make are probably wrong :-) You can specify the settings for a class in two ways and tc shows only one of them. dmax 30ms @ 500 kbit with 1500 packet - the bitrate latency of a 1500 byte packet @ 500kbit is 24ms you say 30 so there is 6ms "spare" so a plot of that curve will 6ms at 0bit and then 500kbit. This is more like I would have for a bulk class - which I would also make ls not rt/sc. Since this is voip I don't think you'll need anything like 1500 byte anyway. For rt/sc you can - as long as you adjust the other curves you can have an m1 of say 1mbit (ie link speed or if you have more than 1 rt link speed/number of rt classes) and an m2 of the long term rate like 500kbit - this I think is how a class for rt traffic should be specified. This qdisc only affects outgoing traffic. But I also want to control incoming packets and keep the isp's queue empty. Question 2: What is the best solution for doing this: ingress qdisc, IMQ, ... (thers's only one link to isp)? Ingress shaping (by which I mean where you are the wrong end of a bottleneck) is not totally doable like egress - depends on link speed, requirements and what the users do to some extent. You will need to sacrifice bandwidth whether you police or shape - say 20% to 50%. You will need to keep buffers (virtual or real fairly short - headdropping would be nicer than tail for real queues, but you can't without hacking code) and waste bandwidth by dropping packets that already used your link (though you can think of these as coming out of what you already sacrificed, you will still be billed/metered if you pay like that). There are other tweaks you can try eg when I had a 500kbit link, getting out of tcp slowstart using connbytes to mark and sending first XkB bulk to a shorter lower rate queue than normal. IFB is an in kernel replacement for IMQ - there are still things you can't do with it or policers eg if you are doing nat and need to get the ingress traffic after it's been denatted by netfilter. Much traffic on this line is UDP traffic (OpenVPN). Question 3: If I do policing on incoming traffic, do UDP transmissions care about dropping and reduce transmit speed? Yes if it's tcp in udp for vpn then it will behave like tcp - for other udp it will be app specific. If I begin to control incoming traffic I only want to drop packets that are non voip traffic. Question 4: Is it possible to control what packets are dropped? Yes - well maybe, if you use policers + actions you can choose what happens to overrate traffic. I think you will need to test what really happens, though - maybe it will work out on average rather than for definate (I am thinking that the overlimits traffic does not get accounted for by meters/ rate estimators). I always want to have enough bandwith for incoming voip traffic. But limiting the other stuff to static 180 kbit only because voip packets could sometimes reach a maximum of 800 kbit sounds not so good. My idea: A script that periodically (or even better: triggered by asterisk) controls the parameters for the ingress shaper (depending on the actual upload traffic produced by voip which could easily be measured with tc). Question 5: Is that possible? Is this necessary at all? Is there already a solution? Could be one way to do it, though it maybe unneccesary depending on what you do eg ifb or policers - in fact I think both could work without scripting. One bonus of scripting would be if you can change things before the new ingress traffic starts - queueing/policing onl
[LARTC] HOWTO: Hello New MAC / DHCP Request - How to spot the presents of a new MAC address...
Sheldon Hearn wrote: I'm sure you could engineer something really impressive, but you could probably get away with a lot less effort by simply tailing whatever dhcpd logs to (possibly /var/log/messages). Yes, that discussion has been had some where... Some research in to dnsmasq and a few emails to the guy who wrote it showed up the answer... You may not need to make any source changes at all: dnsmasq will call a custom script whenever a DHCP lease is created or destroyed: see the --dhcp-script flag in the manpage for details. The MAC address and IP address and name of the host are passed to the script. -- Don Gould www.thinkdesignprint.co.nz - www.tcn.bowenvale.co.nz - www.bowenvale.co.nz - www.hearingbooks.co.nz - SkypeMe: ThinkDesignPrint ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] questions about HFSC, VoIP and (dynamic) ingress shaping
Hello Daniel, > > > > If you don't want to patch the kernel and your machine has only two > > network interfaces you can shape the outgoing traffic to the internal > > interface instead of the incoming traffic to the internal interface. I > > have an example script here: > > > > http://downloads.angulosolido.pt/QoS/HTB_shaper_adv.sh > > > > It uses HTB for shapping though. > > Sorry, I should have explained a little more detailed: (Nearly) all > download traffic is initiated by the machine itself, so I can't use the > "limiting the clients" trick here. Ah... I see... > > > Question 4: Is it possible to control what packets are dropped? > > > > Depends if you know the ports they use. If you know it, you just have to > > mark them accordingly. > > > > For example with skype it's a pain in the ass, > > The only voip traffic (over ppp0) is produced by an asterisk server (on the > same machine). I know all used ports (SIP and RTP) and for outgoing packets > I already mark them with iptables. > So you can match the to the appropriate class. > > > My idea: A script that periodically (or even better: triggered by > > > asterisk) controls the parameters for the ingress shaper (depending on > > > the actual upload traffic produced by voip which could easily be > > > measured with tc). > > > > > > Question 5: Is that possible? Is this necessary at all? Is there > > > already a solution? > > > > I don't think you need this. A setup with HTB solves this problem, since > > each traffic class has a defined RATE as well as a defined CEIL rate, > > which it will take whenever available. > > But then I need IMQ and a patched kernel, right? For the script I pointed you don't need it, because HTB is part of the standard kernel. However for your case, where most of the incoming traffic goes directly to the router machine I think so. If you decide to go that way, take a look at this howto: http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/index.html Boa sorte! Gustavo > > > Best regards > > Gustavo > > Muito obrigado pela sua ajuda ... > Daniel > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] IFB vs IMQ
can u please explain where IFB really place in linux network stack Is iptables rules applicable on it On 7/19/06, Andy Furniss <[EMAIL PROTECTED]> wrote: Rajesh Mahajan wrote: > Is IFB realy replacement of IMQ Mostly - it hooks before/after netfilter though, so if you really need IMQ to hook "in" netfilter (eg. to get denatted addresses on ingress so you can seperate INPUT and FORWARD traffic), you still need IMQ. Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Problem with routing for multiple uplinks/providers using iproute2
serban,thanks for the reply, i dont think thers any irq takin place still i am a newbie so will wish if u chk the two lines which has anythin to do with the eth*169: 723767 725131 723893 724004 IO-APIC-level uhci_hcd:usb2, eth0185: 57275 56839 56322 56789 IO-APIC-level uhci_hcd:usb4, eth1we have made an rc.init file which contains the required command for iproute to be executed and this file gets executed by rc.local.So the rc.init file is,#!/bin/shP1_NET=144.16.129.0/20P2_NET=202.141.12.177/28IF1=eth0IF2=eth1T1=vsnlT2=ernetP1=144.16.141.30P2=202.141.12.177IP1=144.16.129.50IP2=202.141.12.183ip route add $P1_NET dev $IF1 src $IP1 table $T1ip route add default via $P1 table $T1ip route add $P2_NET dev $IF2 src $IP2 table $T2ip route add default via $P2 table $T2ip route del defaultip route add default scope global nexthop via 144.16.141.30 dev eth0 weight 1 nexthop via 202.141.12.178 dev eth1 weight 1ip route add $P1_NET dev $IF1 src $IP1ip route add $P2_NET dev $IF2 src $IP2ip rule add from $IP1 table $T1ip rule add from $IP2 table $T2touch /var/lock/subsys/localecho "keycode 14 = BackSpace" | loadkeyshope this helps in understanding the problemthanks and Regards,MrinalSerban Murariu <[EMAIL PROTECTED]> wrote: could you paste your rc.local?also make sure that your nics are not doing any irq sharing; cat/proc/interrupts and look for a line that states (for example) 5:409350163 XT-PIC eth2, eth1 Heres a new way to find what you're looking for - Yahoo! Answers Heres a new way to find what you're looking for - Yahoo! Answers ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: problem in Route add using netlink
On 31-07-2006 09:03, Jarek Poplawski wrote: ... Of corse you always have to be sure to have the valid route to Cursed! I wish I could "spel" too: http://www.cherwell.org/of_corse_we_can_spel Jarek P. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Re: problem in Route add using netlink
On 25-07-2006 16:59, VijayaLakshmi Seshadri wrote:
Hi all
Iam trying to implement "route add " using netlink. The changes are not
reflected in the routing table. I have given my code and screen shots of
the routing tables.
Can anybody tell me is there any mistake iam making in defining the fields .
or any other mistake iam commiting
thanxs
viji
I had some free time at the weekend - it's probably to late and I
hope you've found this bugs yet, but maybe someone else (like me)
will be looking here some day with similar problem, so here is
what I've found.
Jarek P
CODE
//
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define BUFSIZE 192
struct route_info{
u_int dstAddr;
u_int srcAddr;
u_int gateWay;
charifName[IF_NAMESIZE];
};
void fillRoute (struct route_info *rinfo, const char* dstAddr,
const char* srcAddr, const char* gateway, const char*
ifName)
{
/* Convert from the standrad numbers and dots notation
to binary data */
inet_aton("192.168.51.0", (struct in_addr *)&rinfo->dstAddr);
inet_aton("192.168.51.90", (struct in_addr *)&rinfo->gateWay);
}
Of corse you always have to be sure to have the valid route to
192.168.51.90 on the testing box...
int addAttr (struct nlmsghdr *nlhdr, int maxlen, int type,
void *data, int alen)
{
struct rtattr *rta;
int len = RTA_LENGTH(alen);
if (NLMSG_ALIGN(nlhdr->nlmsg_len) + len > maxlen)
return -1;
rta = (struct rtattr*)((char *)nlhdr +
NLMSG_ALIGN(nlhdr->nlmsg_len));
rta->rta_type = type;
rta->rta_len = len;
memcpy(RTA_DATA(rta), data, alen);
nlhdr->nlmsg_len = NLMSG_ALIGN(nlhdr->nlmsg_len) + len;
return 0;
}
int main()
{
struct nlmsghdr *nlMsg;
struct rtmsg *rtMsg;
char dstAddr[30] ;
char srcAddr[30] ;
char gateway[30] ;
char ifName[30];
char msgBuf[BUFSIZE];
struct route_info rinfo;
int sock, len, msgSeq = 0;
int val, i;
/* Create Socket */
if((sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)) < 0)
perror("Socket Creation: ");
/* Initialize the buffer */
memset(msgBuf, 0, BUFSIZE);
/* point the header and the msg structure pointers into the
buffer */
nlMsg = (struct nlmsghdr *)msgBuf;
rtMsg = (struct rtmsg *)NLMSG_DATA(nlMsg);
/* Fill in the nlmsg header*/
nlMsg->nlmsg_len = NLMSG_LENGTH(sizeof(struct rtmsg)); // Length
ofmessage.
nlMsg->nlmsg_type = RTM_NEWROUTE; // Get
the routes from kernel routing table .
nlMsg->nlmsg_flags = NLM_F_CREATE ; // The message is a
// the flag is needed here
nlMsg->nlmsg_flags = NLM_F_CREATE | NLM_F_REQUEST;
request for dump.
nlMsg->nlmsg_seq = msgSeq++; //
Sequence of the message packet.
nlMsg->nlmsg_pid = getpid(); // PID of
process sending the request.
rtMsg->rtm_family = AF_INET;
rtMsg->rtm_table = RT_TABLE_UNSPEC;
rtMsg->rtm_dst_len = 16;
rtMsg->rtm_src_len = 16;
// this should be address' lenghts in bits so:
rtMsg->rtm_dst_len = 32;
rtMsg->rtm_src_len = 32;
rtMsg->rtm_scope = RT_SCOPE_UNIVERSE;
rtMsg->rtm_type = RTN_UNICAST;
rtMsg->rtm_protocol = RTPROT_UNSPEC;
rtMsg->rtm_flags = RTM_F_NOTIFY;
fillRoute (&rinfo, dstAddr, srcAddr, gateway, ifName);
addAttr (nlMsg, BUFSIZE, RTA_DST,
&rinfo.dstAddr, 4);
addAttr (nlMsg, BUFSIZE, RTA_GATEWAY,
&rinfo.gateWay, 4);
/* Send the request */
if((val = send(sock, nlMsg, nlMsg->nlmsg_len,0 )) < 0){
printf("Write To Socket Failed...\n");
return -1;
}
printf (" No of Bytes sent %d \n", val);
printf (" Value that is sent \n " );
for (i =0 ; i < val ; i ++)
printf ("%u", msgBuf[i]);
printf ("\n");
close(sock);
return 0;
}
//
OUTPUT
[EMAIL PROTECTED] netlink_addroute.c -o addroute
[EMAIL PROTECTED] ./addroute
No of Bytes sent 44
Value that is sent
44000240044294967239880021616101008010429496723242949672085108050429496723242949672085190
//
SCREEN SHOTS
*Routing table before execution of program*
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse
Iface
