Hello,
PROBLEM: transfer speed is ONLY HALF if queue is defined in pf.conf
although queue is 950Mbit (1000Mbit-5%)
pf disabled: 768 Mbits/sec
pf enabled, queue 950Mbit: 337 Mbits/sec
ANALYSIS:
- OpenBSD 4.8 default intallation.
- Test made between OpenBSD 4.8 and Debian Linux.
(between two De
On Tuesday 16 November 2010, Robert Lewandowski wrote:
> Hello,
>
> PROBLEM: transfer speed is ONLY HALF if queue is defined in pf.conf
> although queue is 950Mbit (1000Mbit-5%)
> pf disabled: 768 Mbits/sec
> pf enabled, queue 950Mbit: 337 Mbits/sec
>
> ANALYSIS:
>
> - OpenBSD 4.8 default intallati
W dniu 2010-11-16 16:14, Joel Sing pisze:
The default length for a queue is 50 packets - this only allows you to queue
around 75,000 bytes and the burstiness of TCP slow-start is likely to well
exceed this in your configuration (due to the BDP). I'd suggest increasing
the queue length - also ru
W dniu 2010-11-16 17:04, RLW pisze:
W dniu 2010-11-16 16:14, Joel Sing pisze:
The default length for a queue is 50 packets - this only allows you to
queue
around 75,000 bytes and the burstiness of TCP slow-start is likely to
well
exceed this in your configuration (due to the BDP). I'd suggest
W dniu 2010-11-16 16:14, Joel Sing pisze:
On Tuesday 16 November 2010, Robert Lewandowski wrote:
Hello,
PROBLEM: transfer speed is ONLY HALF if queue is defined in pf.conf
although queue is 950Mbit (1000Mbit-5%)
pf disabled: 768 Mbits/sec
pf enabled, queue 950Mbit: 337 Mbits/sec
ANALYSIS:
- O
What does CPU usage look like when this is happening? is there any other
resources that appear to be constrained?
J
On Wed, Nov 17, 2010 at 3:21 AM, RLW wrote:
> W dniu 2010-11-16 16:14, Joel Sing pisze:
>
>> On Tuesday 16 November 2010, Robert Lewandowski wrote:
>>
>> Hello,
>>>
>>> PROBLEM:
Thanks for all the answers, but the problem still exists.
To sum up:
OpenBSD 4.8 default install
cpu0: Intel(R) Celeron(R) CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 GHz
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
em0 at pci1 dev 0 function 0 "Intel PRO/1000 PT (82572EI)"
W dniu 2010-11-17 22:11, Kenneth Gober pisze:
this is very illuminating. it says that initially, tcp send/receive
window is your bottleneck. when you increase them to 131072, the cpu
becomes your bottleneck and remains that way no matter what else you
tweak (idle drops to 0.0% and stays there).
W dniu 2010-11-18 06:27, Tomas Bodzar pisze:
How about output of 'vmstat -i' and "screen" of default systat (systat vmstat)
r...@router-test (/root)# vmstat -i
interrupt total rate
irq0/clock4836013 100
irq83/em0 2771337
> > this is very illuminating. it says that initially, tcp send/receive
> > window is your bottleneck. when you increase them to 131072, the cpu
> > becomes your bottleneck and remains that way no matter what else you
> > tweak (idle drops to 0.0% and stays there).
> >
> > the next question is, o
W dniu 2010-11-18 13:42, Schvberle Daniel pisze:
So the conclusion might be:
- there is problem with my Intel NIC model/cheapset
- there is problem with em driver
- there is problem with my hardware (I need serwer motherboard with pcie
and pci 64bit 66mhz)
- I need faster CPU than P4 3GHz ??
2010/11/18 RLW :
> there is no tcpbench in packages for 4.8 and for debian linux
Because it's in base: /usr/bin/tcpbench
ciao,
david
W dniu 2010-11-18 16:52, David Coppa pisze:
2010/11/18 RLW:
there is no tcpbench in packages for 4.8 and for debian linux
Because it's in base: /usr/bin/tcpbench
ciao,
david
I removed Intel NIC and run test on broadcom integrated Gbit NIC to see
if there is problem with em driver
bge0
On Thu, Nov 18, 2010 at 05:29:41PM +0100, RLW wrote:
> W dniu 2010-11-18 16:52, David Coppa pisze:
> >2010/11/18 RLW:
> >
> >>there is no tcpbench in packages for 4.8 and for debian linux
> >
> >Because it's in base: /usr/bin/tcpbench
> >
> >ciao,
> >david
> >
>
>
> I removed Intel NIC and run te
W dniu 2010-11-18 17:41, Claudio Jeker pisze:
No the problem is altq. Altq(4) was written when 100Mbps was common and
people shaped traffic in the low megabit range. It seems to hit a wall when
doing hundreds of megabits. Guess someone needs to run a profiling kernel
and see where all that tim
On 2010-11-18, RLW wrote:
> W dniu 2010-11-18 17:41, Claudio Jeker pisze:
>>>
>>
>> No the problem is altq. Altq(4) was written when 100Mbps was common and
>> people shaped traffic in the low megabit range. It seems to hit a wall when
>> doing hundreds of megabits. Guess someone needs to run a pro
W dniu 2010-11-19 00:24, Stuart Henderson pisze:
The "someone" running a profiling kernel to identify the hot spots could be you.
cd /sys/arch//config
config -p
build a kernel from the ../compile/.PROF directory in the usual way
kgmon -b to start profiling
(generate some traffic)
kgmon -h to st
dmesg missing!
Your computer horsepower will definitely affect the maximum bandwith pf
will be able to manage.
El 16/11/2010 12:52, Robert Lewandowski escribiC3:
Hello,
PROBLEM: transfer speed is ONLY HALF if queue is defined in pf.conf
although queue is 950Mbit (1000Mbit-5%)
pf disabled: 76
Hi,
Could somebody include this in the FAQ? I found Daniel Hartmeier
personal page which shows how to get stack trace and line numbers. I
know that the stacktrace info is included somewhere on openbsd.org.
But the way Daniel presented was much better. That particular
presentation or a link should
On Mon, Nov 22, 2010 at 5:34 AM, Amit Kulkarni wrote:
> Hi,
>
> Could somebody include this in the FAQ? I found Daniel Hartmeier
> personal page which shows how to get stack trace and line numbers. I
> know that the stacktrace info is included somewhere on openbsd.org.
> But the way Daniel present
W dniu 2010-11-19 00:24, Stuart Henderson pisze:
On 2010-11-18, RLW wrote:
W dniu 2010-11-18 17:41, Claudio Jeker pisze:
No the problem is altq. Altq(4) was written when 100Mbps was common and
people shaped traffic in the low megabit range. It seems to hit a wall when
doing hundreds of mega
On Thu, Dec 30, 2010 at 01:51:29PM +0100, RLW wrote:
> W dniu 2010-11-19 00:24, Stuart Henderson pisze:
> >On 2010-11-18, RLW wrote:
> >>W dniu 2010-11-18 17:41, Claudio Jeker pisze:
>
> >>>
> >>>No the problem is altq. Altq(4) was written when 100Mbps was common and
> >>>people shaped traffi
W dniu 2010-12-30 14:36, Claudio Jeker pisze:
On Thu, Dec 30, 2010 at 01:51:29PM +0100, RLW wrote:
W dniu 2010-11-19 00:24, Stuart Henderson pisze:
On 2010-11-18, RLW wrote:
W dniu 2010-11-18 17:41, Claudio Jeker pisze:
No the problem is altq. Altq(4) was written when 100Mbps was common
On Thu, Dec 30, 2010 at 8:47 AM, RLW wrote:
>> index %timeself descendents called+selfname index
>> [1] 83.90.00 359.49 sched_idle [1]
>> You spent> 80% in idle. So while forwarding all that traffic the box was
>> mostly idle.
>
> although kernel p
W dniu 2010-12-30 18:47, Ted Unangst pisze:
On Thu, Dec 30, 2010 at 8:47 AM, RLW wrote:
index %timeself descendents called+selfname index
[1] 83.90.00 359.49 sched_idle [1]
You spent>80% in idle. So while forwarding all that traffic the box w
25 matches
Mail list logo
