On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote:
> Hi everyone!
>
> I hope this is the right place to ask.
>
> I've got a IPFW ruleset that looks like this:
>
> cmd=ipfw
> bottleneck_bandwidth=100Mbit/s
> in_if="em0"
>
> $cmd pipe 500 config bw $bottleneck_bandwidth
> $cmd ad
On March 4, 2009 11:17 pm Sebastian Mellmann wrote:
> >> > Is there any chance to change this clock tick to a lower value?
> >> > I think it's the 'HZ=' option in the kernel config isn't it?
> >>
> >> yes. i believe there is a tunable (so you don't need to rebuild
> >> the kernel) but i do not reme
On Thu, 5 Mar 2009, Sebastian Mellmann wrote:
> > > If I configure another rule (or like 10 more rules) that matches the
> > > packet, I can see the delay increasing.
> > > For example a delay of ~20ms, when I configure 10 pipes.
> > > Am I doing something wrong?
> >
> > Configuring more
> > > Also, without using a separate pipe for either traffic direction, you're
> > > using 'half-duplex' mode, as well described in ipfw(8) TRAFFIC SHAPING.
>
> Paired pipes will speed things up. Maybe not noticeably for pings (call
> and response work half-duplex) but for esp TCP it could be
On Thu, 5 Mar 2009, Sebastian Mellmann wrote:
> > Paired pipes will speed things up. Maybe not noticeably for pings (call
> > and response work half-duplex) but for esp TCP it could be considerable.
>
> How does this "pairing" of pipes work?
> Couldn't find any documentation about it?
Per
On Wed, 4 Mar 2009, Luigi Rizzo wrote:
> On Wed, Mar 04, 2009 at 08:17:05PM +0100, Sebastian Mellmann wrote:
> > Hi everyone!
> >
> > I hope this is the right place to ask.
> >
> > I've got a IPFW ruleset that looks like this:
> >
> > cmd=ipfw
> > bottleneck_bandwidth=100Mbit/s
> > in_
On Fri, Mar 06, 2009 at 04:23:29PM +1100, Ian Smith wrote:
...
> Which led me to take my own medicine and reread the dummynet sections in
> ipfw(8) at 7.1-RELEASE:
>
> delay ms-delay
> Propagation delay, measured in milliseconds. The value is
> rounded to the next multiple of the clo
>> Secondly, apropos Sebastian's experience, should this say "The value
>> (even if 0) is rounded to the next multiple of the clock tick .." ?
>> ^^^
>
> 0 is rounded to 0 so that's not an issue.
> The delay Sebastian is seeing comes from the babdnwidth limitation,
> which is causing a non
On Fri, Mar 06, 2009 at 08:06:50AM +0100, Sebastian Mellmann wrote:
>
> >> Secondly, apropos Sebastian's experience, should this say "The value
> >> (even if 0) is rounded to the next multiple of the clock tick .." ?
> >> ^^^
> >
> > 0 is rounded to 0 so that's not an issue.
> > The delay
