On 11/23/06, Mike Tancsa <[EMAIL PROTECTED]> wrote:
At 12:43 PM 11/23/2006, Vlad Galu wrote:
> Can you please completely remove the iptables support from your
>Linux configuration, as well as removing support for any packet filter
>in FreeBSD? Also, please enable fast_forwarding.
I did that a
At 12:43 PM 11/23/2006, Vlad Galu wrote:
Can you please completely remove the iptables support from your
Linux configuration, as well as removing support for any packet filter
in FreeBSD? Also, please enable fast_forwarding.
I did that a while ago. See
http://www.tancsa.com/blast.html
On 11/23/06, Mike Tancsa <[EMAIL PROTECTED]> wrote:
At 08:09 AM 11/22/2006, Jeremie Le Hen wrote:
>It would be interesting to know the real performance of Linux as a mere
>router if we want a true comparision with FreeBSD performances.
Re-tested, this time with a LINUX UP kernel and there is no
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
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 circu
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
CPU: Intel(R) Xeon(R) CPU5110 @ 1.60GHz (1600.01-MHz 686-class
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
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: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-net@freebsd.org mailing list
http://lists.freebsd.org/mailma
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?
___
fre
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-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
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 fro
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
driver
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 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 li
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 unr
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 c
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 confi
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 is
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
http:/
ike Tancsa" <[EMAIL PROTECTED]>
Cc: "freebsd-net" ; ;
"Jack Vogel" <[EMAIL PROTECTED]>
Sent: Saturday, November 11, 2006 8:42 AM
Subject: Re: Proposed 6.2 em RELEASE patch
> Mike Tancsa wrote:
> > At 05:00 PM 11/10/2006, Jack Vogel wrote:
> >> On 11
- Original Message -
From: "Scott Long" <[EMAIL PROTECTED]>
To: "Mike Tancsa" <[EMAIL PROTECTED]>
Cc: "freebsd-net" ; <[EMAIL PROTECTED]>;
; "Jack Vogel" <[EMAIL PROTECTED]>
Sent: Saturday, November 11, 2006 8:42 AM
Subj
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 ra
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 kno
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/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 stuff
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
>
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 perfo
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
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.
It certainly does make a difference performance wise. I did some
quick testing with netperf and net
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
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 las
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 fo
34 matches
Mail list logo
