Date: Mon, 1 Nov 2004 05:50:24 -0800 From: Vincent Poy <vincepoy@gmail.com> To: Nikolay Pavlov <quetzal@roks.biz>, Vincent Poy <vincepoy@gmail.com>, Brian Fundakowski Feldman <green@freebsd.org>, Luigi Rizzo <luigi@freebsd.org>, freebsd-current@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: Traffic Shaping not working correctly after ipfw coverted to use pfil_hooks API Message-ID: <429af92e0411010550628c8a25@mail.gmail.com> In-Reply-To: <20041101132849.GA56525@roks.biz> References: <429af92e041020205510c66168@mail.gmail.com> <4177B899.5EC32F5F@freebsd.org> <429af92e04102114472add0e51@mail.gmail.com> <417835C7.7060808@freebsd.org> <429af92e04102404115bc7bc80@mail.gmail.com> <20041026133043.A24138@xorpc.icir.org> <20041026231745.GE93831@green.homeunix.org> <429af92e041028171979d4bf42@mail.gmail.com> <20041101132849.GA56525@roks.biz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Nikolay:
On Mon, 1 Nov 2004 15:28:49 +0200, Nikolay Pavlov <quetzal@roks.biz> wrote:
> On Thursday, 28 October 2004 at 17:19:43 -0700, Vincent Poy wrote:
> > # Assign outgoing empty/small ACK packets to the high-priority queue
> > ${fwcmd} add 63004 set 0 queue 1 tcp from any to any tcpflags ack out
>
> Dummynet works as well as should, but if I have correctly undestood your
> idea this rule should be something like this:
> ${fwcmd} add 63004 set 0 queue 1 tcp from any to any tcpflags ack out iplen 1-66
Actually, I actually have it as iplen 0-80 so that it prioritizes
empty and small TCP ACK packets including those with a payload. I
know that if I had it as iplen 52 then it is just empty ACK packets
only (no payload). I'm still confused on what uses between 53-80
though since 0-52 would be the empty ACK packets only.
> > It appears that somehow the ACKs were not sent with priority on the
> > upload pipe while downloading which is slowing the download side to
> > less than 33% speed of the pipe.
>
> I think you missundestood appointment of this flag. If you use tcpdump
> you will see, that packet with ack flag in time of uploading often contains
> also the data, instead of simply short answer with acknowledgment. So that
> booster is not correctly adjusted. See my comment above.
For some reason, it is working correctly now when I do a simultaneous
upload/download... it is now running correctly. For the last week
which might just be a coincidence when I did the upgrade to the latest
-CURRENT after 7 months, maybe it was SBC's ATM network or something
that was slowing down the downstream side.
Since these are the results I get:
10485760 bytes sent in 03:08 (54.39 KB/s)
10485760 bytes received in 00:25 (404.29 KB/s)
Before, as I posted. I was getting no more than 200.00 KB/s when I
was download/uploading at the same time but when I download and don't
upload, it was
giving the full 650KB/sec speed.
> > Here are the ipfw pipe and queue's:
> >
> > root@bigbang [5:11pm][/home/vince] >> ipfw pipe show
> > 00001: 400.000 Kbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail
> > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> > q00001: weight 100 pipe 1 50 sl. 1 queues (1 buckets) droptail
> > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
> > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
> > 0 tcp 208.201.244.226/1449 64.12.185.119/80 96816 57368081 39 13603 311
>
> This is just confirmation of my words.
> Hope this help.
One question though is on the ipfw pipe show and ipfw queue show,
isn't the Prot, Source IP/port and Dest IP/port supposed to change
when I have new connections since it stays the same since bootup.
> Best regards,
> Nikolay Pavlov.
>
Cheers,
Vince
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429af92e0411010550628c8a25>