Skip site navigation (1)Skip section navigation (2)
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>