Scott Larson wrote:
> We've got 10.0 and 10.1 servers accessing Isilon and Nexenta via NFS
> with Intel 10G gear and bursting to near wire speed with the stock
> MTU/rsize/wsize works as expected. TSO definitely needs to be enabled for
> that performance.
Btw, can you tell us what Intel chip(s) you
Gerrit Kuhn wrote:
> On Thu, 25 Jun 2015 20:49:11 -0400 (EDT) Rick Macklem
> wrote about Re: NFS on 10G interface terribly slow:
>
>
> RM> Recent commits to stable/10 (not in 10.1) done by Alexander Motin
> RM> (mav@) might help w.r.t. write performance (it avoids large writes
> RM> doing synchr
Damien Fleuriot wrote:
> Gerrit,
>
>
> Everyone's talking about the network performance and to some extent NFS
> tuning.
> I would argue that given your iperf results, the network itself is not at
> fault.
>
In this case, I think you might be correct.
However, I need to note that NFS traffic is
Sean,
Here is a cut/paste from a term window:
root@thumper1:~ # pciconf -lvcb
pcib1@pci0:0:1:0: class="0x060400" card=0x chip=0x74581022 rev=0x12
hdr=0x01
vendor = 'Advanced Micro Devices [AMD]'
device = 'AMD-8132 PCI-X Bridge'
class = bridge
subclass = PCI-PCI
cap 07[60] = PCI-X
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/15/15 12:42, Jeremiah Lott wrote:
> I am having trouble using pxeboot with new-ish Intel NICs. We have
> been using pxeboot with Intel NICs as part of our infrastructure
> for a while successfully. Recently, I got some new 2x10G (ixgbe)
> cards
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/20/15 11:14, rondzie...@comcast.net wrote:
> I am using 10.1-RELEASE on a SunFire X4500 (thumper). It has 4 em
> devices, of which only the first two work due to a resource
> failure:
>
> em0: port
> 0xcc00-0xcc3f mem 0xfdae-0xfdaf ir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/07/15 21:01, Nomad Esst via freebsd-net wrote:
> I've recently configured my kernel with the following options
> devicepatm deviceutopia deviceatm options
> NATM options LIBMBPOOL In order to use patm device on my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201127
ex(4) is an old Intel ethernet driver that isn't being actively
maintained. I propose purging it from -current for 11.0 release things.
sean
p.s. will post to -current as well
-BEGIN P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/26/15 04:55, Pushkar Kothavade wrote:
> Dear Members,
>
> To further narrow down the problem, I am evaluating single ixl
> link (Intel Fortville NIC) on FreeBSD platform. Single ixl link is
> _NOT_ a part of Lagg.
>
> *Issue*
>
> Change in M
Dear Members,
To further narrow down the problem, I am evaluating single ixl link
(Intel Fortville NIC) on FreeBSD platform.
Single ixl link is _NOT_ a part of Lagg.
*Issue*
Change in MAC address on a ixl (Intel Fortville NIC) link does not
reflect on NIC.
Ping stops working after change in
Gerrit,
Everyone's talking about the network performance and to some extent NFS
tuning.
I would argue that given your iperf results, the network itself is not at
fault.
In your first post I see no information regarding the local performance of
your disks, sans le NFS that is.
You may want to lo
On Thu, 25 Jun 2015 20:49:11 -0400 (EDT) Rick Macklem
wrote about Re: NFS on 10G interface terribly slow:
RM> Recent commits to stable/10 (not in 10.1) done by Alexander Motin
RM> (mav@) might help w.r.t. write performance (it avoids large writes
RM> doing synchronous writes when the wcommitsize
On Thu, 25 Jun 2015 12:56:36 -0700 Scott Larson wrote
about Re: NFS on 10G interface terribly slow:
SL> We've got 10.0 and 10.1 servers accessing Isilon and Nexenta via
SL> NFS with Intel 10G gear and bursting to near wire speed with the stock
SL> MTU/rsize/wsize works as expected.
That sou
13 matches
Mail list logo
