On Sun, 15 Sep 2024 18:01:07 +0100
Doug Rabson wrote:
> I just did a throughput test with iperf3 client on a FreeBSD 14.1 host with
> an intel 10GB nic connecting to an iperf3 server running in a vnet jail on
> a truenas host (13.something) also with an intel 10GB nic and I get full
> 10GB throug
On Sat, 14 Sep 2024 10:45:03 +0800
Zhenlei Huang wrote:
> The overhead of vnet jail should be neglectable, compared to legacy jail
> or no-jail. Bare in mind when VIMAGE option is enabled, there is a default
> vnet 0. It is not visible via jls and can not be destroyed. So when you see
> bottlenec
On Fri, 13 Sep 2024 08:08:02 -0400
Mark Saad wrote:
> Sad
>Can you go back a bit you mentioned there is a RPi in the mix ? Some of
> the raspberries have their nic usb attached under the covers . Which will
> kill the total speed of things.
>
> Can you cobble together a diagram of what y
Tried both, kernel built with "options RSS" and the following
in /boot/loader.conf
net.isr.maxthreads=-1
net.isr.bindthreads=1
net.isr.dispatch=deferred
Not sure if there are race conditions with these implementations, but
after a few short tests, the epair_task_0 got stuck 100% on CPU and
stayed
I built new kernel with "options RSS" however TCP throughput performance
now decreased from 128 MiB/sec to 106 MiB/sec.
Looks like the problem has shifted from epair to netisr
PID USERNAMEPRI NICE SIZERES STATEC TIMEWCPU COMMAND
12 root-56- 0B 272K CPU3
There seems to be an open bug describing similar issue:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272944
On Thu, 12 Sep 2024 13:25:32 -0400
Paul Procacci wrote:
> You need to define `poor'.
> You need to show `top -SH` while the `problem' occurs.
>
> My guess is packets are getting shuttled between a global taskqueue thread.
> This is the default, or at least I'm not aware of this default being
> c
Hi, I'm using FreeBSD-14.1 and on this particular system I only have a
single physical network interface, so I followed instructions for
networking vnet jails via epair and bridge, e.g.
devel
{
vnet;
vnet.interface = "e0b_devel";
exec.prestart += "/jails/jib addm devel gene
On Wed, 3 Apr 2024 17:28:52 +0200
Michael Tuexen wrote:
> > On 3. Apr 2024, at 15:44, Sad Clouds wrote:
> >
> > I found a bug that is still open from May 2010 and describes the same
> > behaviour that I see with my application:
> >
> > https://bugs.freebsd
I found a bug that is still open from May 2010 and describes the same
behaviour that I see with my application:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845
If this hasn't been fixed over the last 14 years, then I guess I will
add some code to simply ignore ECONNRESET on close(2) for
Hello, I have a client/server networking application that exhibits
TCP socket handling errors. This only happens on FreeBSD, while NetBSD,
Linux, Solaris, etc. all seem to work correctly. I was hoping to get
some advice on what could be the root cause.
I have two processes - client and server, sen
11 matches
Mail list logo
