At 12:15 AM 11/13/2006, Scott Long wrote:
Is this with EM_INTR_FAST enabled also?
Yes. Havent done the stock case yet, but will do so later today.
---Mike
___
freebsd-stable@freebsd.org mailing list
Mike Tancsa wrote:
At 12:15 AM 11/13/2006, Scott Long wrote:
Is this with EM_INTR_FAST enabled also?
Yes. Havent done the stock case yet, but will do so later today.
Do you have a comparison with Linux under the same circumstances?
___
At 12:15 AM 11/13/2006, Scott Long wrote:
Is this with EM_INTR_FAST enabled also?
Without it, the 2 streams are definitely lossy on the management interface
---Mike
___
freebsd-stable@freebsd.org mailing list
Mike Tancsa wrote:
At 12:15 AM 11/13/2006, Scott Long wrote:
Is this with EM_INTR_FAST enabled also?
Without it, the 2 streams are definitely lossy on the management interface
---Mike
Ok, and would you be able to test the polling options as well?
Scott
At 12:50 PM 11/13/2006, Ivan Voras wrote:
Mike Tancsa wrote:
At 12:15 AM 11/13/2006, Scott Long wrote:
Is this with EM_INTR_FAST enabled also?
Yes. Havent done the stock case yet, but will do so later today.
Do you have a comparison with Linux under the same circumstances?
I had a disk
Hey. I've got one new machine for testing for 1-2 days... here's some output..
With the latest drivers (cvsup'ed from yesterday)
Send box: 2x Intel Xeon 5110 (1.6GHz), SuperMicro X7-DBE, Intel Pro/1000 MT
Server Adapter
DMESG
CPU: Intel(R) Xeon(R) CPU5110 @ 1.60GHz (1600.01-MHz
Mike Tancsa wrote:
At 12:50 PM 11/13/2006, Ivan Voras wrote:
Mike Tancsa wrote:
At 12:15 AM 11/13/2006, Scott Long wrote:
Is this with EM_INTR_FAST enabled also?
Yes. Havent done the stock case yet, but will do so later today.
Do you have a comparison with Linux under the same
Hi All,
Unfortunately our company hasn't had the resources to help FreeBSD
much over the years, but I do want to say thank you to the folks who
are helping sort out this issue with the em driver.
That Intel gigabit interface is very, very common on server hardware
nowadays and it means a
Should fiddling with the interrupt-coalescing stuff in the em driver
via sysctl be tried?
None of the recent tests in reply to your email indicate any
particular tx/rx threshold settings.
adrian
--
Adrian Chadd - [EMAIL PROTECTED]
___
At 08:45 AM 11/12/2006, Adrian Chadd wrote:
Should fiddling with the interrupt-coalescing stuff in the em driver
via sysctl be tried?
None of the recent tests in reply to your email indicate any
particular tx/rx threshold settings.
I was using whatever is the default. What would you like me
Mike Tancsa wrote:
At 01:42 AM 11/11/2006, Scott Long wrote:
driver. What will help me is if you can hook up a serial console to
your machine and see if it can be made to drop to the debugger while it
is under load and otherwise unresponsive. If you can, getting a process
dump might help
At 11:41 AM 11/12/2006, Scott Long wrote:
Mike Tancsa wrote:
At 01:42 AM 11/11/2006, Scott Long wrote:
driver. What will help me is if you can hook up a serial console to
your machine and see if it can be made to drop to the debugger while it
is under load and otherwise unresponsive. If you
Mike Tancsa wrote:
At 11:41 AM 11/12/2006, Scott Long wrote:
Mike Tancsa wrote:
At 01:42 AM 11/11/2006, Scott Long wrote:
driver. What will help me is if you can hook up a serial console to
your machine and see if it can be made to drop to the debugger while it
is under load and otherwise
At 08:47 PM 11/12/2006, Scott Long wrote:
2. Try compiling in WITNESS and running the test as before, then break
into the debugger as before. Run 'show locks'. I'm not sure how
fruitful this will be, WITNESS might make it unbearably slow.
It was in that kernel already
So you're seeing the
Mike Tancsa wrote:
However, if I turn on fastforwarding, its back to the old behavior with
it locking up. This was with the stock driver. I will try the same test
with
#define EM_FAST_INTR 1
as well as taking out the nfs option from the kernel driver. Anything
else to tune with ?
At 11:05 PM 11/12/2006, Scott Long wrote:
Mike Tancsa wrote:
However, if I turn on fastforwarding, its back to the old behavior
with it locking up. This was with the stock driver. I will try the
same test with
#define EM_FAST_INTR 1
as well as taking out the nfs option from the kernel
Mike Tancsa wrote:
At 11:05 PM 11/12/2006, Scott Long wrote:
Mike Tancsa wrote:
However, if I turn on fastforwarding, its back to the old behavior
with it locking up. This was with the stock driver. I will try the
same test with
#define EM_FAST_INTR 1
as well as taking out the nfs option
At 01:42 AM 11/11/2006, Scott Long wrote:
surprised by your results. I'm still a bit unclear on the exact
topology of your setup, so if could explain it some more in private
email, I'd appreciate it.
Hi,
I made a quick diagram of the test setup that should make it
more clear
At 01:42 AM 11/11/2006, Scott Long wrote:
driver. What will help me is if you can hook up a serial console to
your machine and see if it can be made to drop to the debugger while it
is under load and otherwise unresponsive. If you can, getting a process
dump might help confirm where each CPU
At 05:00 PM 11/9/2006, Mike Tancsa wrote:
At 10:51 AM 11/9/2006, Scott Long wrote:
Mike Tancsa wrote:
At 08:19 PM 11/8/2006, Jack Vogel wrote:
BUT, I've added the FAST_INTR changes back into the code, so
if you go into your Makefile and add -DEM_FAST_INTR you will
then get the taskqueue
On 11/10/06, Mike Tancsa [EMAIL PROTECTED] wrote:
Some more tests. I tried again with what was committed to today's
RELENG_6. I am guessing its pretty well the same patch. Polling is
the only way to avoid livelock at a high pps rate. Does anyone know
of any simple tools to measure end to end
At 05:00 PM 11/10/2006, Jack Vogel wrote:
On 11/10/06, Mike Tancsa [EMAIL PROTECTED] wrote:
Some more tests. I tried again with what was committed to today's
RELENG_6. I am guessing its pretty well the same patch. Polling is
the only way to avoid livelock at a high pps rate. Does anyone know
Mike Tancsa wrote:
At 05:00 PM 11/10/2006, Jack Vogel wrote:
On 11/10/06, Mike Tancsa [EMAIL PROTECTED] wrote:
Some more tests. I tried again with what was committed to today's
RELENG_6. I am guessing its pretty well the same patch. Polling is
the only way to avoid livelock at a high pps
- Original Message -
From: Scott Long [EMAIL PROTECTED]
To: Mike Tancsa [EMAIL PROTECTED]
Cc: freebsd-net freebsd-net@freebsd.org; [EMAIL PROTECTED];
freebsd-stable@freebsd.org; Jack Vogel [EMAIL PROTECTED]
Sent: Saturday, November 11, 2006 8:42 AM
Subject: Re: Proposed 6.2 em
At 08:19 PM 11/8/2006, Jack Vogel wrote:
BUT, I've added the FAST_INTR changes back into the code, so
if you go into your Makefile and add -DEM_FAST_INTR you will
then get the taskqueue stuff.
It certainly does make a difference performance wise. I did some
quick testing with netperf and
Mike Tancsa wrote:
At 08:19 PM 11/8/2006, Jack Vogel wrote:
BUT, I've added the FAST_INTR changes back into the code, so
if you go into your Makefile and add -DEM_FAST_INTR you will
then get the taskqueue stuff.
It certainly does make a difference performance wise. I did some quick
testing
At 08:19 PM 11/8/2006, Jack Vogel wrote:
BUT, I've added the FAST_INTR changes back into the code, so
if you go into your Makefile and add -DEM_FAST_INTR you will
then get the taskqueue stuff.
Not sure why you would want FAST_INTR and polling in at the same
time, but I found that the two are
At 10:51 AM 11/9/2006, Scott Long wrote:
Mike Tancsa wrote:
At 08:19 PM 11/8/2006, Jack Vogel wrote:
BUT, I've added the FAST_INTR changes back into the code, so
if you go into your Makefile and add -DEM_FAST_INTR you will
then get the taskqueue stuff.
It certainly does make a difference
Yes, they are incompatible, I suppose there should be something
that makes it impossible to do, but not building should be a clue :)
Jack
On 11/9/06, Mike Tancsa [EMAIL PROTECTED] wrote:
At 08:19 PM 11/8/2006, Jack Vogel wrote:
BUT, I've added the FAST_INTR changes back into the code, so
if
This patch is an evolution of the last one I sent out. It has
a couple of minor corrections, like a bad forward decl in
the header.
The last patch has had quite a bit of testing and all reports
have been positive. The only complaint was from Gleb who
says he needs to keep his beloved infinite
Without introduced this new patch, can I still use sysctl to maximise its
performance like FAST_INTR?
S
On 11/9/06, Jack Vogel [EMAIL PROTECTED] wrote:
This patch is an evolution of the last one I sent out. It has
a couple of minor corrections, like a bad forward decl in
the header.
The last
On 11/8/06, Sam Wun [EMAIL PROTECTED] wrote:
Without introduced this new patch, can I still use sysctl to maximise its
performance like FAST_INTR?
S
Not sure if I'm understanding you, but let me try.
You cannot attain the same receive performance without
the patch. When I use SmartBits and
32 matches
Mail list logo
