Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote:
How do I investigate and fix this burstiness issue?
Please also show:
sysctl net.isr
sysctl net.inet.ip.intr_queue_maxlen
net.isr.swi_count: 65461359
net.isr.drop: 0
net.isr.queued: 32843752
net.isr.deferred: 0
net
Eugene Grosbein wrote:
Try to increase net.inet.ip.intr_queue_maxlen uptio 4096.
You sure? Packets are never dropped once I add "allow ip from any to
any" before pipes, effectively turning dummynet off. Yet I've doubled it
for starters (50->100) let's see if it works in an hour or so, when i
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote:
How do I investigate and fix this burstiness issue?
Please also show:
sysctl net.isr
sysctl net.inet.ip.intr_queue_maxlen
net.isr.swi_count: 65461359
net.isr.drop: 0
net.isr.queued: 32843752
net.isr.deferred: 0
net
On Mon, Oct 05, 2009 at 10:49:45AM -0700, Julian Elischer wrote:
> >There is a rumour about FreeBSD's shedulers...
> >That they are not so good for 8 cores and that you may get MORE speed
> >by disabling 4 cores if it's possible for your system.
> >Or even using uniprocessor kernel.
> >Only rumour
On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote:
> >>How do I investigate and fix this burstiness issue?
> >
> >Please also show:
> >
> >sysctl net.isr
> >sysctl net.inet.ip.intr_queue_maxlen
>
> net.isr.swi_count: 65461359
> net.isr.drop: 0
> net.isr.queued: 32843752
> net.isr.deferred: 0
rihad wrote:
Julian Elischer wrote:
rihad wrote:
Julian Elischer wrote:
Luigi Rizzo wrote:
Is it possible to know what sessions are losing packets?
Yes, of course, by running ipfw pipe show ;-)
There's one confusing thing, though: net.inet.ip.dummynet.io_pkt_drop
isn't increasing while aro
Julian Elischer wrote:
rihad wrote:
Julian Elischer wrote:
Luigi Rizzo wrote:
Is it possible to know what sessions are losing packets?
Yes, of course, by running ipfw pipe show ;-)
There's one confusing thing, though: net.inet.ip.dummynet.io_pkt_drop
isn't increasing while around 800-1000 p
Julian Elischer wrote:
How do I investigate and fix this burstiness issue?
higher Hz rate?
Hmm, mine is 1000. I'll try bumping it up to 2000 (via
/boot/loader.conf) but since a reboot is required I think it'll have to
wait for a while.
___
freeb
rihad wrote:
Julian Elischer wrote:
Luigi Rizzo wrote:
Taildrop does not really help with this. GRED does much better.
i think the first problem here is figure out _why_ we have
the drops, as the original poster said that queues are configured
with a very large amount of buffer (and i think
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 08:07:18PM +0500, rihad wrote:
What is CPU load in when the load is maximum?
It has 2 quad-cores, so I'm not sure. Here's the output of top -S:
There is a rumour about FreeBSD's shedulers...
That they are not so good for 8 cores and that you ma
Julian Elischer wrote:
rihad wrote:
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote:
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
Still not sure why increasing queue size as high as I want doesn't
completely eliminate drops.
The goa
rihad wrote:
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 05:12:11PM +0500, rihad wrote:
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote:
Luigi Rizzo wrote:
...
you keep omitting the important info i.e. whether individual
pipes have drops, significant queue lenghts an
rihad wrote:
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 04:50:10PM +0500, rihad wrote:
Where has TCP slow-start gone? My router box isn't some application
proxy that starts downloading at full 100 mbit/s thus quickly
filling client's 1 mbit/s link. It's just a router.
While there is no o
rihad wrote:
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote:
Luigi Rizzo wrote:
...
you keep omitting the important info i.e. whether individual
pipes have drops, significant queue lenghts and so on.
Sorry. Almost everyone has 0 in the last Drp column, but some have
Julian Elischer wrote:
Luigi Rizzo wrote:
Taildrop does not really help with this. GRED does much better.
i think the first problem here is figure out _why_ we have
the drops, as the original poster said that queues are configured
with a very large amount of buffer (and i think there is a
mis
rihad wrote:
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote:
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
Still not sure why increasing queue size as high as I want doesn't
completely eliminate drops.
The goal is to make sources of
Luigi Rizzo wrote:
Taildrop does not really help with this. GRED does much better.
i think the first problem here is figure out _why_ we have
the drops, as the original poster said that queues are configured
with a very large amount of buffer (and i think there is a
misconfiguration somewhere
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 08:07:18PM +0500, rihad wrote:
What is CPU load in when the load is maximum?
It has 2 quad-cores, so I'm not sure. Here's the output of top -S:
There is a rumour about FreeBSD's shedulers...
That they are not so good for 8 cores and that you ma
On Mon, Oct 05, 2009 at 08:07:18PM +0500, rihad wrote:
> >What is CPU load in when the load is maximum?
> >
> It has 2 quad-cores, so I'm not sure. Here's the output of top -S:
There is a rumour about FreeBSD's shedulers...
That they are not so good for 8 cores and that you may get MORE speed
by
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote:
How do I investigate and fix this burstiness issue?
Please also show:
sysctl net.isr
sysctl net.inet.ip.intr_queue_maxlen
net.isr.swi_count: 65461359
net.isr.drop: 0
net.isr.queued: 32843752
net.isr.deferred: 0
net
On Mon, Oct 05, 2009 at 07:30:15PM +0500, rihad wrote:
> >>How do I investigate and fix this burstiness issue?
> >
> >Please also show:
> >
> >sysctl net.isr
> >sysctl net.inet.ip.intr_queue_maxlen
>
> net.isr.swi_count: 65461359
> net.isr.drop: 0
> net.isr.queued: 32843752
> net.isr.deferred: 0
> Date: Mon, 05 Oct 2009 10:24:33 +0200
> From: Andre Oppermann
>
> Kevin Oberman wrote:
> > I have a system that is unable to connect to a FreeBSD system due to
> > the odd formatting of the TCP options. The options contains only the
> > timestamp which, if recommendations in RFC1323 are followe
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 06:08:47PM +0500, rihad wrote:
How do I investigate and fix this burstiness issue?
Please also show:
sysctl net.isr
sysctl net.inet.ip.intr_queue_maxlen
net.isr.swi_count: 65461359
net.isr.drop: 0
net.isr.queued: 32843752
net.isr.deferred: 0
On Mon, Oct 05, 2009 at 06:08:47PM +0500, rihad wrote:
> How do I investigate and fix this burstiness issue?
Please also show:
sysctl net.isr
sysctl net.inet.ip.intr_queue_maxlen
Eugene Grosbein
___
freebsd-net@freebsd.org mailing list
http://lists.fr
Eugene Grosbein wrote:
Try to disable net.inet.ip.dummynet.io_fast to see if there is a bug
in 'fast' dummynet mode.
Already tried that, no difference. Interestingly, now I checked sysctls
and found out that net.inet.ip.dummynet.io_pkt_fast counter is still
growing despite io_fast being disabl
On Mon, Oct 05, 2009 at 05:18:29PM +0500, rihad wrote:
> >You've mentioned previously: "The pipes are fine, each normally having
> >100-120 concurrent consumers (i.e. active users)."
> >This IS competition between TCP flows inside each pipe.
> >
> Well, each user gets instantiated with a new copy
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 05:12:11PM +0500, rihad wrote:
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote:
Luigi Rizzo wrote:
...
you keep omitting the important info i.e. whether individual
pipes have drops, significant queue lenghts and so on.
Sorr
On Mon, Oct 05, 2009 at 05:12:11PM +0500, rihad wrote:
> Luigi Rizzo wrote:
> >On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote:
> >>Luigi Rizzo wrote:
> >...
> >>>you keep omitting the important info i.e. whether individual
> >>>pipes have drops, significant queue lenghts and so on.
> >>>
> >
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 04:50:10PM +0500, rihad wrote:
Where has TCP slow-start gone? My router box
isn't some application proxy that starts downloading at full 100 mbit/s
thus quickly filling client's 1 mbit/s link. It's just a router.
While there is no or little compe
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote:
Luigi Rizzo wrote:
...
you keep omitting the important info i.e. whether individual
pipes have drops, significant queue lenghts and so on.
Sorry. Almost everyone has 0 in the last Drp column, but some have above
zero.
On Mon, Oct 05, 2009 at 04:50:10PM +0500, rihad wrote:
> >>Where has TCP slow-start gone? My router box
> >>isn't some application proxy that starts downloading at full 100 mbit/s
> >>thus quickly filling client's 1 mbit/s link. It's just a router.
> >
> >While there is no or little competition
On Mon, Oct 05, 2009 at 04:29:02PM +0500, rihad wrote:
> Luigi Rizzo wrote:
...
> >you keep omitting the important info i.e. whether individual
> >pipes have drops, significant queue lenghts and so on.
> >
> Sorry. Almost everyone has 0 in the last Drp column, but some have above
> zero. I'm not j
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote:
Where has TCP slow-start gone? My router box
isn't some application proxy that starts downloading at full 100 mbit/s
thus quickly filling client's 1 mbit/s link. It's just a router.
While there is no or little com
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote:
Taildrop does not really help with this. GRED does much better.
i think the first problem here is figure out _why_ we have
the drops, as the original poster said that queues are configured
with a very large amount of
On Sun, Oct 04, 2009 at 08:28:59PM +0500, rihad wrote:
> Thanks for the tip. although I took an easier route by simply doing
> "ipfw add allow ip from any to any" before the pipe rules, and the buf
> drop rate instantly became 0. So the problem is dummynet/ipfw.
You should also estimate volume
On Mon, Oct 05, 2009 at 03:20:58PM +0500, rihad wrote:
> >>>Taildrop does not really help with this. GRED does much better.
> >>i think the first problem here is figure out _why_ we have
> >>the drops, as the original poster said that queues are configured
> >>with a very large amount of buffer (a
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote:
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
Still not sure why increasing queue size as high as I want doesn't
completely eliminate drops.
The goal is to make sources of traffic to slo
The following reply was made to PR kern/137776; it has been noted by GNATS.
From: Carlos
To: bug-follo...@freebsd.org,
f...@freebsd.org
Cc:
Subject: Re: kern/137776: [rum] panic in rum(4) driver on 8.0-BETA2
Date: Mon, 5 Oct 2009 12:52:32 +0200
hi list,
I would like to say sorry for my po
Note: to view an individual PR, use:
http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).
The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.
S Tracker
On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote:
> Eugene Grosbein wrote:
> >On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
> >
> >>Still not sure why increasing queue size as high as I want doesn't
> >>completely eliminate drops.
> >
> >The goal is to make sources of traffic to slow
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
Still not sure why increasing queue size as high as I want doesn't
completely eliminate drops.
The goal is to make sources of traffic to slow down, this is the only
way to descrease drops - any finite queue may be o
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 12:04:46PM +0200, Luigi Rizzo wrote:
The goal is to make sources of traffic to slow down, this is the only
way to descrease drops - any finite queue may be overhelmed with traffic.
Taildrop does not really help with this. GRED does much better.
i
On Mon, Oct 05, 2009 at 12:04:46PM +0200, Luigi Rizzo wrote:
> > The goal is to make sources of traffic to slow down, this is the only
> > way to descrease drops - any finite queue may be overhelmed with traffic.
> > Taildrop does not really help with this. GRED does much better.
>
> i think the
On Mon, Oct 05, 2009 at 02:48:29PM +0500, rihad wrote:
> >First switch from taildrop (default) to GRED, it is designed to fight
> >your problem.
>
> red | gred w_q/min_th/max_th/max_p
>Make use of the RED (Random Early Detection) queue
> management algo-
>rithm. w_q
On Mon, Oct 05, 2009 at 05:56:00PM +0800, Eugene Grosbein wrote:
> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
>
> > Oh, I almost forgot... Right now I've googled up and am reading this
> > intro: http://www-rp.lip6.fr/~sf/WebSF/PapersWeb/iscc01.ps
> >
> > So turning to GRED would tur
On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote:
> Oh, I almost forgot... Right now I've googled up and am reading this
> intro: http://www-rp.lip6.fr/~sf/WebSF/PapersWeb/iscc01.ps
>
> So turning to GRED would turn my FreeBSD router from dumb into a smart
> router that knows TCP? I though
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 01:53:20PM +0500, rihad wrote:
As you can see the drops gradually went away completely at about 4:00
a.m., and started coming up at about 10:30 a.m., although at a lower
rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at
10a.m
Eugene Grosbein wrote:
On Mon, Oct 05, 2009 at 01:53:20PM +0500, rihad wrote:
As you can see the drops gradually went away completely at about 4:00
a.m., and started coming up at about 10:30 a.m., although at a lower
rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at
10a.m
On Mon, Oct 05, 2009 at 01:53:20PM +0500, rihad wrote:
> As you can see the drops gradually went away completely at about 4:00
> a.m., and started coming up at about 10:30 a.m., although at a lower
> rate, probably thanks to me bumping "ipfw ... queue NNN" up to 5000 at
> 10a.m. this morning. T
Luigi Rizzo wrote:
On Mon, Oct 05, 2009 at 10:55:21AM +0800, Eugene Grosbein wrote:
On Sun, Oct 04, 2009 at 06:47:23PM +0500, rihad wrote:
sysctls:
kern.ipc.nmbclusters=5
net.inet.ip.dummynet.io_fast=1
I guess you should also try to increase pipes length:
net.inet.ip.dummynet.hash_size=6
Kevin Oberman wrote:
I have a system that is unable to connect to a FreeBSD system due to
the odd formatting of the TCP options. The options contains only the
timestamp which, if recommendations in RFC1323 are followed, are
preceded by two NOP bytes to put the timestamp values on 4 byte
boundarie
51 matches
Mail list logo
