Hi Hrvoje,
nestat -i shows nothing special.
NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls
lo0 33152 Link 91235 091235 0 0
lo0 33152 localhost/1 localhost91235 091235 0 0
lo0 33152
Hi Remi,
Thanks for your answer.
nestat -m is ok, see.
203 mbufs in use:
193 mbufs allocated to data
2 mbufs allocated to packet headers
8 mbufs allocated to socket names and addresses
190/658/6144 mbuf 2048 byte clusters in use (current/peak/max)
0/8/6144 mbuf 4096 byte clusters in use
On 4.11.2014. 21:48, jum...@yahoo.de wrote:
Hi Remi,
Thanks for your answer.
nestat -m is ok, see.
203 mbufs in use:
193 mbufs allocated to data
2 mbufs allocated to packet headers
8 mbufs allocated to socket names and addresses
190/658/6144 mbuf 2048 byte clusters in use
On Tue, Oct 28, 2014 at 10:13:54PM +0100, jum...@yahoo.de wrote:
Hi Andy,
sorry for the delay, but a lot of more important work were between your mail
and this answer ;).
You can set a simple prio on a rule like;
pass proto tcp from $left to $right set prio (1,4)
With PRIQ I mean the
Hi Andy,
sorry for the delay, but a lot of more important work were between your
mail and this answer ;).
You can set a simple prio on a rule like;
pass proto tcp from $left to $right set prio (1,4)
With PRIQ I mean the scheduler priq instead of cbq.
Relevant lines of my current pf.conf
On 2014-10-09, Andy a...@brandwatch.com wrote:
NB; This is the old syntax for queues and I strongly recommend reading
the 3rd edition of The book of PF (A must read for *anyone* new or old
to OpenBSD and PF) :) and using the new syntax
N.B. the oldqueue syntax goes away in 5.6, if you are
Hi,
Just so I understand what you have done, PRIQ is not the same as queuing.
You can set a simple prio on a rule like;
pass proto tcp from $left to $right set prio (1,4)
But this doesn't manage the situations where you have lots of different
types/profiles of traffic on your network.
For
Hi Andy,
This morning I have added Priority Queueing (PRIQ) to the ruleset and
prefer TCP ACK packets over everything else. I can see the queues with
systat queue but the change has no effect on the user experience nor the
throughput.
I have read something about adjust TCP send and receive
Hi Ville,
What I read on the Internet so far about states [1]: The memory counter
shows how often pf tries to insert a state but failed. The reason could be
a hard limit of state entries.
I watched at the memory counter this afternoon and it doesn't increased,
still at 8764.
pfctl -s
On 2 October 2014 23:36, jum...@yahoo.de wrote:
$ sysctl kern.netlivelocks
kern.netlivelocks=2
What does this means? I found something like a deadlock, when two processes
block each other, I'm right?
This is useful information specially under the load. I don't have the
source code available
On 3 October 2014 11:11, Ville Valkonen weezeld...@gmail.com wrote:
On 2 October 2014 23:36, jum...@yahoo.de wrote:
$ sysctl kern.netlivelocks
kern.netlivelocks=2
What does this means? I found something like a deadlock, when two processes
block each other, I'm right?
This is useful
Hi,
I use a OpenBSD based firewall (version 5.2, I know I should upgrade but ...)
between a 8 host cluster of Linux server and 300 clients which will access this
clutser via VNC. Each server is connected with one gigabit port to a dedicated
switch and the firewall has on each site one gigabit
jum...@yahoo.de (Patrick), 2014.10.02 (Thu) 16:32 (CEST):
Hi,
I use a OpenBSD based firewall (version 5.2, I know I should upgrade
but ...) between a 8 host cluster of Linux server and 300 clients
which will access this clutser via VNC. Each server is connected with
one gigabit port to a
Hello Patrick,
On 2 October 2014 17:32, Patrick jum...@yahoo.de wrote:
Hi,
I use a OpenBSD based firewall (version 5.2, I know I should upgrade but ...)
between a 8 host cluster of Linux server and 300 clients which will access
this clutser via VNC. Each server is connected with one
Setup some queues and prioritise your ACK's ;)
The box is fine under the load I'm sure, but you'll still need to
prioritise those TCP acknowledgments to make things snappy when lots of
traffic is going on..
On 02/10/14 17:13, Ville Valkonen wrote:
Hello Patrick,
On 2 October 2014 17:32,
On 2 Oct 2014 at 18:15, Andy wrote:
Setup some queues and prioritise your ACK's ;)
The box is fine under the load I'm sure, but you'll still need to
prioritise those TCP acknowledgments to make things snappy when lots of
traffic is going on..
All these (otherwise valid) suggestions are
On 02-10-2014 17:30, System Administrator wrote:
All these (otherwise valid) suggestions are useless until we know more
about the specific firewall in question -- information best delivered
in the form of dmesg, 'pfctl -si' output and other statistics as
indicated in Ville's response below. I
Hi Andy,
Setup some queues and prioritise your ACK's ;)
Good idea, I will try to implement a Priority Queueing with the old altq.
Best Regards,
Patrick
On Thu, 2 Oct 2014, Andy wrote:
Setup some queues and prioritise your ACK's ;)
The box is fine under the load I'm sure, but you'll still
Hi Ville,
$ pfctl -si
Status: Enabled for 597 days 07:40:45Debug: err
Interface Stats for em0 IPv4 IPv6
Bytes In 30397895135138 4212405499
Bytes Out 358299989496464 64
Packets In
Passed
19 matches
Mail list logo
