> "Mike" == Mike Tancsa <[EMAIL PROTECTED]> writes:
Mike> At 12:18 PM 08/10/2004, David Gilbert wrote:
>> Idle_poll is default 1, I'm not positive we tested 0. I don't
>> think there is much idle time here.
Mike> Actually, on RELENG_5, I think the default is now zero.
checked, tho. We did
> "Julian" == Julian Elischer <[EMAIL PROTECTED]> writes:
Julian> David Gilbert wrote:
Julian> there are also changes in B4->B7 that ar related to scheduling
Julian> the packet delivery mechanisms.. They may not make much of a
Julian> difference but...
I will endevour to do cvsup and retest
At 12:18 PM 08/10/2004, David Gilbert wrote:
Idle_poll is default 1, I'm not positive we tested 0. I don't think
there is much idle time here.
Actually, on RELENG_5, I think the default is now zero.
With a releng_5 BETA7 box in between 2 other hosts, with idle_poll set to
the default on zero, usi
David Gilbert wrote:
"Scott" == Scott Long <[EMAIL PROTECTED]> writes:
Scott> Interesting results. One thing to note is that a severe bug in
Scott> the if_em driver was fixed for BETA7. The symptoms of this bug
Scott> include apparent livelock of the machine during heavy xmit
Scott>
> "Daniel" == Daniel Eriksson <[EMAIL PROTECTED]> writes:
Daniel> David Gilbert wrote:
>> Right out of the box, FreeBSD 5.3 (with polling) passed about 200
>> kpps.
Daniel> Was this with debug.mpsafenet enabled and all debugging
Daniel> (WITNESS and such) turned off?
mpsafenet on and all wit
> "Mike" == Mike Tancsa <[EMAIL PROTECTED]> writes:
Mike> At 10:08 AM 08/10/2004, David Gilbert wrote:
>> Right out of the box, FreeBSD 5.3 (with polling) passed about 200
>> kpps. net.isr.enable=1 increased that without polling to about 220
Mike> Did you have kern.polling.idle_poll at 0 or
> "Guy" == Guy Helmer <[EMAIL PROTECTED]> writes:
Guy> The fixed bug in the em driver for BETA7 may significantly help
Guy> (see Scott Long's response prior to mine).
As I replied, I hand-applied these patches. They reduced live lock
(or what my tech calls "chunkyness" --- almost live lock),
David Gilbert wrote:
> Right out of the box, FreeBSD 5.3 (with polling) passed about 200
> kpps.
Was this with debug.mpsafenet enabled and all debugging (WITNESS and such)
turned off?
/Daniel Eriksson
___
[EMAIL PROTECTED] mailing list
http://lists.f
At 10:08 AM 08/10/2004, David Gilbert wrote:
Right out of the box, FreeBSD 5.3 (with polling) passed about 200
kpps. net.isr.enable=1 increased that without polling to about 220
Did you have kern.polling.idle_poll at 0 or 1 ? In my tests a few weeks ago
this seemed to make a difference, but the l
David Gilbert wrote:
During the next week, I will continue testing with full simulated
routing tables, random packets and packets between 350 and 550 bytes
(average ISP out/in packet sizes). I will add to this report then.
If anyone has tuning advice for FreeBSD 5.3, I'd like to hear it.
Three thi
David Gilbert wrote:
The opportunity presented itelf for me to test packet passing ability
on some fairly exotic hardware. The motherboard I really wanted to
test not only had separate memory busses for each cpu, but also had
two separate PCI-X busses (one slot each). To this, I added two
intel p
> "Scott" == Scott Long <[EMAIL PROTECTED]> writes:
Scott> Interesting results. One thing to note is that a severe bug in
Scott> the if_em driver was fixed for BETA7. The symptoms of this bug
Scott> include apparent livelock of the machine during heavy xmit
Scott> load. You might want to up
David Gilbert wrote:
The opportunity presented itelf for me to test packet passing ability
on some fairly exotic hardware. The motherboard I really wanted to
test not only had separate memory busses for each cpu, but also had
two separate PCI-X busses (one slot each). To this, I added two
intel p
The opportunity presented itelf for me to test packet passing ability
on some fairly exotic hardware. The motherboard I really wanted to
test not only had separate memory busses for each cpu, but also had
two separate PCI-X busses (one slot each). To this, I added two
intel pro/1000 gigabit ether
14 matches
Mail list logo