I'm watching top -S -I -s1 -H
This is just more of an observation.. I'm not having a problem with it,
just wondering why it's doing it.. It's almost like most of the system
processes in 'top' are a 3-5 minute average instead of an instant
percentage. If this is intended behavior I simply wanted to know :)
Curiousity Mainly. Also, isn't the emX taskq supposed to be using no
cpu when polling is enabled?
I'm trying to get em interface to take in 500kpps or more but it just
won't do it. The max I can get is close to 400k and then it starts
loading up on errors (out of receive buffers, rx overruns) mainly
because the cpu is near 100% on em0 taskq. :(
We need a SMP em driver for 7.0 :)
No profiling yet... just messing around.. Intel Dual port pci-express
nic , opteron 2212 , 7.0-stable now AMD64
seeing how much it will take before it errors out so I can figure out
something to do with it.. :P
Thanks :)
Paul
[EMAIL PROTECTED] wrote:
At Thu, 26 Jun 2008 23:25:18 -0400,
Paul wrote:
I have a FreeBSD router set up with Full BGP routes and I'm doing some
tests on using it for routing.
7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008
amd64
oddness..:
Use a packet generator to generate random source ips and ports and send
traffic through the router to a destination on the other side, single ip.
What happens is the 'em0 taskq' starts to eat cpu... but the funny
thing is immediately when I start the traffic (say, 100,000 pps) em0
taskq is about 15% cpu.. and then over the course of 2 minutes or so it
climbs to 60% cpu.. This makes no sense.. The packets per second are
continuous and it just routed 100kpps for 60 seconds with less cpu so
why in the world would it slowly climb like that?
It's an observation I suppose and I was hoping if someone could
enlighten me on WHY.. :) I did test it on 3 different machines by the way.
It even does this with just a handful of routes in the routing table , I
tried that too just to rule that out.
I don't remember Freebsd 4/5 doing this??
What are you using to measure the CPU time? Some tools take time to
gather up enough samples. Also, have you tried to do any profiling on
the kernel to see why this might be the case?
http://www.watson.org/~robert/freebsd/netperf/profile/
Best,
George
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"