2012/10/25 Bob Lee :
> The ixgbe driver supports 10Gb Intel 82598 and 82599 networking
> devices. Tested with
> an Intel E10G41AT2 card, connected two back to back, ping flood, netperf, and
> configured
> in Xen as PCI passthrough (running the same set of tests).
>
> - bob
Could you pro
Recently, was asked to backport the driver to our version of NetBSD5.
I've included
the diff of non-driver files, and a separate diff for the ixgbe driver which is
in CVS,
but not included in the netbsd_5 label.
The ixgbe driver supports 10Gb Intel 82598 and 82599 networking
dev
On Oct 24, 2012, at 5:44 PM, Manuel Bouyer wrote:
> On Wed, Oct 24, 2012 at 04:07:34PM +0200, Manuel Bouyer wrote:
>> Hello,
>> I just got this panic on a NFS server:
>> uvm_fault(0xfe9069ecf468, 0x0, 1) -> e
>> fatal page fault in supervisor mode
>> trap type 6 code 0 rip 804bd391 cs
I tried the same thing:
Creating took 18.6 seconds, deleting 2.4s.
Troughput (dd) is 17.5MB/s.
Probably it's significant that the 2,500 .lock files that svn update creates
are scattered around the directory tree?
> I just did this on my 6.99.14 system and it takes less than 1s:
Did you run iostat -D to examine whether your discs got saturated some seconds
after the command finished?
2012/10/25 Paul Goyette :
> On Thu, 25 Oct 2012, Stephan wrote:
>
>> I always found FFS being slow when creating or deleting many files.
>> For example, on 6.0 with FFSv2 and WAPBL it took 20 sec. to complete
>> this:
>>
>>
>> time seq 1 3 | xargs touch
>
>
> I just did this on my 6.99.14 syste
On Thu, 25 Oct 2012, Stephan wrote:
I always found FFS being slow when creating or deleting many files.
For example, on 6.0 with FFSv2 and WAPBL it took 20 sec. to complete
this:
time seq 1 3 | xargs touch
I just did this on my 6.99.14 system and it takes less than 1s:
# uname -rs
NetBS
2012/10/25 Edgar Fuß :
> Now this is getting weird. I have retried the experiment with neither softdep
> nor log, i.e. with a plain old FFS, and that performs as well as or even
> outperforms WAPL.
> With both a 5.1_STABLE and a 6.0_RELEASE kernel, on a 16k fsbsize FFSv2, the
> svn updates takes ar
Now this is getting weird. I have retried the experiment with neither softdep
nor log, i.e. with a plain old FFS, and that performs as well as or even
outperforms WAPL.
With both a 5.1_STABLE and a 6.0_RELEASE kernel, on a 16k fsbsize FFSv2, the
svn updates takes around 5 seconds with either log
