Re: PPPoE problem: "Too many LQR packets lost"
Mike Tancsa wrote: On Sat, 24 Jul 2004 20:42:01 -0700, in sentex.lists.freebsd.net you wrote: Seriously though, mine was a very ugly hack to get things working again for me. Most of the DSL aggregators here are Juniper ERXes which do not play nice with FreeBSD's PPPoE. any thoughts as to why? FreeBSD's pppoe is going through a little development at the moment.. Now would be a good time to get it fixed.. Hi, Simple LCP echos work just fine, but when using LQR things "break". There are debug logs posted in the archives when I first figured out what was broken. If you need another copy I am happy to post again. certainly it would be useful. rather than taking potsots at the archive hoping to catch it.. pppoe is tricky because the responsibility for errors os split between the pppoe module and the ppp module.. ---Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
On Mon, 26 Jul 2004, Don Bowman wrote: > From: Luigi Rizzo [mailto:[EMAIL PROTECTED] > > On Mon, Jul 26, 2004 at 01:18:46PM -0700, Kelly Yancey wrote: > > ... > > > Out of curiousity, what sort of testing did you do to > > arrive at these > > > settings? I did some testing a while back with a SmartBits > > box pumping > > > packets through a FreeBSD 2.8Ghz box configured to route > > between two em > > > gigabit interfaces; I found that changing the burst_max and > > each_burst > > > parameters had almost no effect on throughput (maximum 1% > > difference). > > > > fast boxes are pci-bus limited, not CPU limited(*) so > > changing the burst > > size (which basically amortizes some CPU costs) has little if any > > effect. > > The PCI-X bus will probably be 64-bit 133MHz in this case, > the limit moves up to the P64H2 hub for large packets, > to the CPU for small packets. Polling becomes quite > critical to prevent livelock. > Sorry, I should be been more clear. Polling certainly stopped livelock under extreme load, however I never found much difference whether the burst size was small or large. I was wondering if it was just the nature of my test and if in other environments the burst_max and each_burst knobs have a greater affect. Kelly -- Kelly Yancey - [EMAIL PROTECTED],FreeBSD.org} - [EMAIL PROTECTED] FreeBSD, The Power To Serve: http://www.freebsd.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: device polling takes more CPU hits??
On Mon, 26 Jul 2004, Luigi Rizzo wrote: > On Mon, Jul 26, 2004 at 01:18:46PM -0700, Kelly Yancey wrote: > ... > > Out of curiousity, what sort of testing did you do to arrive at these > > settings? I did some testing a while back with a SmartBits box pumping > > packets through a FreeBSD 2.8Ghz box configured to route between two em > > gigabit interfaces; I found that changing the burst_max and each_burst > > parameters had almost no effect on throughput (maximum 1% difference). > > fast boxes are pci-bus limited, not CPU limited(*) so changing the burst > size (which basically amortizes some CPU costs) has little if any > effect. > > (*) this doesn't mean that the box cannot livelock, as depending on > the traffic on the bus, the CPU might stall for long intervals > waiting for bus transactions to complete, and becomes unable to > do anything at all. So you might still need polling. > > cheers > luigi > Oh, I found polling to be vastly superior to interrupts under load on the test machine. Not only did it avoid livelock, the throughput was about 10Mbps higher for small (64-byte) frames. I just didn't find much difference whether I used small burst sizes versus large burst sizes. It may have had to do with the fact that both the sending and receiving interfaces were gigabit em cards and were polling (no interrupts from the NICs at all). Kelly -- Kelly Yancey - [EMAIL PROTECTED],FreeBSD.org} - [EMAIL PROTECTED] Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ecartis command results: -- Attached file included as plaintext by Ecartis --
Request received for list 'xml-tech' via request address. >> The message could not be delivered Unknown command. >> Content-Transfer-Encoding: base64 Unknown command. >> Content-Disposition: attachment; Unknown command. >> filename="=?utf-8?B?VklSVVNfREVURUNURURfQU5EX1JFTU9WRURfaWNteg==?= Unknown command. >> =?utf-8?B?a2NtLnppcF9WSVJJTkZPLlRYVA==?=" Unknown command. >> 77u/MDcvMjcvMjAwNCAwMDoyMjo1NiBPcmlnaW5hbCBhdHRhY2htZW50IChpY216a2NtLnppcCkg Unknown command. >> d2FzIERlbGV0ZWQuICBBIHZpcnVzIHdhcyBkZXRlY3RlZCBhbmQgcmVtb3ZlZCBmcm9tIHRoZSBv Unknown command. >> cmlnaW5hbCBhdHRhY2htZW50LiAgWW91IGNhbiBzYWZlbHkgc2F2ZSBvciBkZWxldGUgdGhpcyBy Unknown command. >> ZXBsYWNlbWVudCBhdHRhY2htZW50Lg== Unknown command. --- Ecartis v1.0.0 - job execution complete. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
From: Luigi Rizzo [mailto:[EMAIL PROTECTED] > On Mon, Jul 26, 2004 at 01:18:46PM -0700, Kelly Yancey wrote: > ... > > Out of curiousity, what sort of testing did you do to > arrive at these > > settings? I did some testing a while back with a SmartBits > box pumping > > packets through a FreeBSD 2.8Ghz box configured to route > between two em > > gigabit interfaces; I found that changing the burst_max and > each_burst > > parameters had almost no effect on throughput (maximum 1% > difference). > > fast boxes are pci-bus limited, not CPU limited(*) so > changing the burst > size (which basically amortizes some CPU costs) has little if any > effect. The PCI-X bus will probably be 64-bit 133MHz in this case, the limit moves up to the P64H2 hub for large packets, to the CPU for small packets. Polling becomes quite critical to prevent livelock. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
From: James [mailto:[EMAIL PROTECTED] > > I have two boxes behind em0 that I can use to generate > 250kpps to another vlan > within em0 card as a test, so that bge0 is not involved in > the stress test. > Even when doing so, CPU load climbs higher with device > polling turned on. > Opened up systat, etc to check the interrupts, and em0 is > generating 0 > interrupts with device polling on (as obvious), but general > interrupt load > climbs rock high.. so I don't know what's causing it to > climb. Cleared the > firewall rules as well as a test... no difference :( > > Oh also, just FYI, each vlan interface has link0 set, since > em(4) supports > hardware 802.1q tag/detagging. > The CPU time during the 'polling' is charged to interrupt, even though it occurs during softclock. That's why you see 0 interrupts, but high CPU usage in interrupt. Did u try lowering the 'register' access? --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: device polling takes more CPU hits??
On Mon, Jul 26, 2004 at 01:18:46PM -0700, Kelly Yancey wrote: ... > Out of curiousity, what sort of testing did you do to arrive at these > settings? I did some testing a while back with a SmartBits box pumping > packets through a FreeBSD 2.8Ghz box configured to route between two em > gigabit interfaces; I found that changing the burst_max and each_burst > parameters had almost no effect on throughput (maximum 1% difference). fast boxes are pci-bus limited, not CPU limited(*) so changing the burst size (which basically amortizes some CPU costs) has little if any effect. (*) this doesn't mean that the box cannot livelock, as depending on the traffic on the bus, the CPU might stall for long intervals waiting for bus transactions to complete, and becomes unable to do anything at all. So you might still need polling. cheers luigi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Out of Office AutoReply: Returned mail: see transcript for details
Thank you for your message. I will be out of the office from July 26 to August 6 on a business trip with limited access to my messages. This could cause a delay in the reply of your message. Thank you for your patience and best regards Antonio Moreno Supply Chain Program Manager Europe, Middle East and Africa Image and Printing Group Hewlett Packard Española, S.L. Av. Graells, 501 E-08174 Sant Cugat del Valles (Barcelona) Tel. (+34) 93 582 6070 www.hp.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
On Mon, 26 Jul 2004, Don Bowman wrote: > kern.polling.burst: 1000 > kern.polling.each_burst: 80 > kern.polling.burst_max: 1000 > kern.polling.idle_poll: 1 > kern.polling.poll_in_trap: 0 > kern.polling.user_frac: 5 > kern.polling.reg_frac: 120 > kern.polling.short_ticks: 29 > kern.polling.lost_polls: 55004 > kern.polling.pending_polls: 0 > kern.polling.residual_burst: 0 > kern.polling.handlers: 4 > kern.polling.enable: 1 > kern.polling.phase: 0 > kern.polling.suspect: 50690 > kern.polling.stalled: 25 Out of curiousity, what sort of testing did you do to arrive at these settings? I did some testing a while back with a SmartBits box pumping packets through a FreeBSD 2.8Ghz box configured to route between two em gigabit interfaces; I found that changing the burst_max and each_burst parameters had almost no effect on throughput (maximum 1% difference). That was completely contrary to expectations and would love to hear how I could improve my test setup to see how changing those values are supposed to affect performance. Thanks, Kelly -- Kelly Yancey - [EMAIL PROTECTED],FreeBSD.org} - [EMAIL PROTECTED] "The information of the people at large can alone make them the safe as they are the sole depositary of our political and religious freedom." -- Thomas Jefferson to William Duane, 1810. ME 12:417 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: device polling takes more CPU hits??
Don, > Hmm, this is more interesting. > Since you are SMP, and using POLLING, i assume you did > like me and commented out the !POLLING in SMP #error statement. Yep. Otherwise kernel won't compile ;-) > You definitely want the halt on idle. The polling in idle > doesn't work anyway, so try disabling it. Yea, I made sure cpu_idle_hlt set to 1, and also made sure polling.idle_poll is set to 0. Then turned on device polling again.. CPU load again goes higher.. I then tried setting burst_max to 1000 and each_burst to 80, hence duplicating the parameters you are using on your system. The CPU load then went down, but its still not any lower than running it w/o device polling at all (meaning, device polling still isn't working properly). I have two boxes behind em0 that I can use to generate 250kpps to another vlan within em0 card as a test, so that bge0 is not involved in the stress test. Even when doing so, CPU load climbs higher with device polling turned on. Opened up systat, etc to check the interrupts, and em0 is generating 0 interrupts with device polling on (as obvious), but general interrupt load climbs rock high.. so I don't know what's causing it to climb. Cleared the firewall rules as well as a test... no difference :( Oh also, just FYI, each vlan interface has link0 set, since em(4) supports hardware 802.1q tag/detagging. Thanks! -J -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
From: Marko Zec [mailto:[EMAIL PROTECTED] > On Monday 26 July 2004 17:35, Don Bowman wrote: > > > [EMAIL PROTECTED] sysctl machdep.cpu_idle_hlt > > > machdep.cpu_idle_hlt: 1 > > > At least on -STABLE, machdep.cpu_idle_hlt setting is ignored > / irrelevant when > both kern.polling.enable and kern.polling.idle_poll are set. > Hmm, this is more interesting. Since you are SMP, and using POLLING, i assume you did like me and commented out the !POLLING in SMP #error statement. You definitely want the halt on idle. The polling in idle doesn't work anyway, so try disabling it. James, not sure if you saw the rest of my email with my params: > kern.polling.burst: 1000 > kern.polling.each_burst: 80 > kern.polling.burst_max: 1000 > kern.polling.idle_poll: 0 > kern.polling.poll_in_trap: 0 > kern.polling.user_frac: 5 > kern.polling.reg_frac: 120 > kern.polling.short_ticks: 29 > kern.polling.lost_polls: 55004 > kern.polling.pending_polls: 0 > kern.polling.residual_burst: 0 > kern.polling.handlers: 4 > kern.polling.enable: 1 > kern.polling.phase: 0 > kern.polling.suspect: 50690 > kern.polling.stalled: 25 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[CFR] if_xl.c and if.c null pointer dereferences
Hi,
A couple of days ago I was handed a new machine with a 3Com 905B card.
Before remembering the PNP OS option in the BIOS, I stumbled across a
couple of null pointer dereferences leading to kernel panics when
FreeBSD 4.10-STABLE could not map the card's resources and attempted to
"clean up" the driver state before it had enough state to begin with.
Attached are two patches, one to if_xl.c and one to if.c, which avoid
"cleaning up" data at pointers that have not been initialized yet.
Although this will not happen in normal operation, there's no need for
the kernel to panic instead of simply reporting that it could not get
the PCI resources it needs :)
G'luck,
Peter
--
Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED]
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If this sentence were in Chinese, it would say something else.
Index: src/sys/net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.195
diff -u -r1.195 if.c
--- src/sys/net/if.c22 Jun 2004 20:13:25 - 1.195
+++ src/sys/net/if.c9 Jul 2004 14:27:49 -
@@ -516,6 +516,8 @@
int s;
int i;
struct domain *dp;
+ struct ifnet *iter;
+ int found;
EVENTHANDLER_INVOKE(ifnet_departure_event, ifp);
/*
@@ -582,9 +584,11 @@
/* We can now free link ifaddr. */
- ifa = TAILQ_FIRST(&ifp->if_addrhead);
- TAILQ_REMOVE(&ifp->if_addrhead, ifa, ifa_link);
- IFAFREE(ifa);
+ if (!TAILQ_EMPTY(&ifp->if_addrhead)) {
+ ifa = TAILQ_FIRST(&ifp->if_addrhead);
+ TAILQ_REMOVE(&ifp->if_addrhead, ifa, ifa_link);
+ IFAFREE(ifa);
+ }
/*
* Delete all remaining routes using this interface
@@ -616,7 +620,14 @@
#endif /* MAC */
KNOTE(&ifp->if_klist, NOTE_EXIT);
IFNET_WLOCK();
- TAILQ_REMOVE(&ifnet, ifp, if_link);
+ found = 0;
+ TAILQ_FOREACH(iter, &ifnet, if_link)
+ if (iter == ifp) {
+ found = 1;
+ break;
+ }
+ if (found)
+ TAILQ_REMOVE(&ifnet, ifp, if_link);
IFNET_WUNLOCK();
mtx_destroy(&ifp->if_snd.ifq_mtx);
IF_AFDATA_DESTROY(ifp);
Index: src/sys/pci/if_xl.c
===
RCS file: /home/ncvs/src/sys/pci/if_xl.c,v
retrieving revision 1.178
diff -u -r1.178 if_xl.c
--- src/sys/pci/if_xl.c 9 Jul 2004 02:28:23 - 1.178
+++ src/sys/pci/if_xl.c 9 Jul 2004 14:26:45 -
@@ -3169,7 +3169,8 @@
sc->xl_cdata.xl_rx_chain[i].xl_mbuf = NULL;
}
}
- bzero(sc->xl_ldata.xl_rx_list, XL_RX_LIST_SZ);
+ if (sc->xl_ldata.xl_rx_list != NULL)
+ bzero(sc->xl_ldata.xl_rx_list, XL_RX_LIST_SZ);
/*
* Free the TX list buffers.
*/
@@ -3183,7 +3184,8 @@
sc->xl_cdata.xl_tx_chain[i].xl_mbuf = NULL;
}
}
- bzero(sc->xl_ldata.xl_tx_list, XL_TX_LIST_SZ);
+ if (sc->xl_ldata.xl_tx_list != NULL)
+ bzero(sc->xl_ldata.xl_tx_list, XL_TX_LIST_SZ);
ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
}
pgpbbx68WwxEJ.pgp
Description: PGP signature
Re: device polling takes more CPU hits??
Hi Don,
> That's a pretty high HZ, here's what i have:
> kern.clockrate: { hz = 2500, tick = 400, tickadj = 1, profhz = 1024, stathz
> = 128 }
Hmm... I'll try setting it to 2500 later this week during maint. window for
customers behind that box. It's weird b/c I have another box with devpolling
that has 4000 as its HZ and has no problems.
Thanks,
-J
> I have the same box spec as you, only with em (bge doesn't
> support polling, but it has its own interrupt coalescer that works...
> you can tune that in the if_bge.h I think, there's some comments).
> I'm doing ~800Kpps with polling. My polling params are below.
> > [EMAIL PROTECTED] sysctl kern.polling
> > kern.polling.burst: 150
> > kern.polling.each_burst: 5
> > kern.polling.burst_max: 150
> > kern.polling.idle_poll: 1
> > kern.polling.poll_in_trap: 1
> > kern.polling.user_frac: 50
> > kern.polling.reg_frac: 20
> > kern.polling.short_ticks: 4909
> > kern.polling.lost_polls: 11464
> > kern.polling.pending_polls: 0
> > kern.polling.residual_burst: 0
> > kern.polling.handlers: 1
> > kern.polling.enable: 1
> > kern.polling.phase: 0
> > kern.polling.suspect: 10249
> > kern.polling.stalled: 3
> >
> > [EMAIL PROTECTED] sysctl machdep.cpu_idle_hlt
> > machdep.cpu_idle_hlt: 1
> >
>
> kern.polling.burst: 1000
> kern.polling.each_burst: 80
> kern.polling.burst_max: 1000
> kern.polling.idle_poll: 1
> kern.polling.poll_in_trap: 0
> kern.polling.user_frac: 5
> kern.polling.reg_frac: 120
> kern.polling.short_ticks: 29
> kern.polling.lost_polls: 55004
> kern.polling.pending_polls: 0
> kern.polling.residual_burst: 0
> kern.polling.handlers: 4
> kern.polling.enable: 1
> kern.polling.phase: 0
> kern.polling.suspect: 50690
> kern.polling.stalled: 25
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
James JunTowardEX Technologies, Inc.
Technical LeadNetwork Design, Consulting, IT Outsourcing
[EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
From: James [mailto:[EMAIL PROTECTED]
> Hi Don,
> [EMAIL PROTECTED] sysctl kern.clockrate
> kern.clockrate: { hz = 4000, tick = 250, tickadj = 1, profhz
> = 1024, stathz = 128 }
That's a pretty high HZ, here's what i have:
kern.clockrate: { hz = 2500, tick = 400, tickadj = 1, profhz = 1024, stathz
= 128 }
I have the same box spec as you, only with em (bge doesn't
support polling, but it has its own interrupt coalescer that works...
you can tune that in the if_bge.h I think, there's some comments).
I'm doing ~800Kpps with polling. My polling params are below.
>
> [EMAIL PROTECTED] sysctl kern.polling
> kern.polling.burst: 150
> kern.polling.each_burst: 5
> kern.polling.burst_max: 150
> kern.polling.idle_poll: 1
> kern.polling.poll_in_trap: 1
> kern.polling.user_frac: 50
> kern.polling.reg_frac: 20
> kern.polling.short_ticks: 4909
> kern.polling.lost_polls: 11464
> kern.polling.pending_polls: 0
> kern.polling.residual_burst: 0
> kern.polling.handlers: 1
> kern.polling.enable: 1
> kern.polling.phase: 0
> kern.polling.suspect: 10249
> kern.polling.stalled: 3
>
> [EMAIL PROTECTED] sysctl machdep.cpu_idle_hlt
> machdep.cpu_idle_hlt: 1
>
kern.polling.burst: 1000
kern.polling.each_burst: 80
kern.polling.burst_max: 1000
kern.polling.idle_poll: 1
kern.polling.poll_in_trap: 0
kern.polling.user_frac: 5
kern.polling.reg_frac: 120
kern.polling.short_ticks: 29
kern.polling.lost_polls: 55004
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 4
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 50690
kern.polling.stalled: 25
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spoofed MAC on a dhcp interface
Hi, On Sun, Jul 25, 2004 at 05:52:57PM -0700, Charlie Schluting wrote: > Hi :) > > /etc/rc.conf: > ifconfig_xl0="ether 00:11:11:11:11:11" > ifconfig_xl0="DHCP" The last assignment takes precedence over the previous one. > The above doesn't work.. > I'm trying to set the mac, and then dhcp.. is this the correct way? Set iconfig_xl0="DHCP" in rc.conf, then use a /etc/start_if.xl0 script to set the MAC address: #!/bin/sh ifconfig xl0 ether 00:11:11:11:11:11 > With this config, its not getting the mac assigned to xl0, so I have to > stop dhclient, run "ifconfig ether 00:11:11:11:11:11" manually, then > dhcp again. > > Thanks! > -Charlie $0.02 Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spoofed MAC on a dhcp interface
James Housley wrote: The key was created /etc/start_if.xl0: #!/bin/sh Yep! Someone else also responded with a similar suggestion. Thank you very much, everyone, problem solved. I didn't know you could make start_if. ...very cool. I also now know its in rc.conf(5) :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: device polling takes more CPU hits??
Hi Don,
> I would post the output of 'sysctl kern.polling', its likely
> some of the tuning there is insufficient.
> What do you have HZ set to (sysctl kern.clockrate)? I would
> probably have it set to ~1000.
> You will want 'machdep.cpu_idle_hlt=1'.
Thanks for quick reply. Here is the sysctl output with polling turned on.
-J
[EMAIL PROTECTED] sysctl kern.clockrate
kern.clockrate: { hz = 4000, tick = 250, tickadj = 1, profhz = 1024, stathz = 128 }
[EMAIL PROTECTED] sysctl kern.polling
kern.polling.burst: 150
kern.polling.each_burst: 5
kern.polling.burst_max: 150
kern.polling.idle_poll: 1
kern.polling.poll_in_trap: 1
kern.polling.user_frac: 50
kern.polling.reg_frac: 20
kern.polling.short_ticks: 4909
kern.polling.lost_polls: 11464
kern.polling.pending_polls: 0
kern.polling.residual_burst: 0
kern.polling.handlers: 1
kern.polling.enable: 1
kern.polling.phase: 0
kern.polling.suspect: 10249
kern.polling.stalled: 3
[EMAIL
PROTECTED] sysctl machdep.cpu_idle_hlt
machdep.cpu_idle_hlt: 1
--
James JunTowardEX Technologies, Inc.
Technical LeadNetwork Design, Consulting, IT Outsourcing
[EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: device polling takes more CPU hits??
From: James [mailto:[EMAIL PROTECTED] > Hi all, > ... > > Any idea why device polling is kind of having... negative > impact? Is this b/c > I have SMP compiled on a box that really doesn't have two > cpu's?? Is SMP+APIC_IO > support even required for HTT use? I would post the output of 'sysctl kern.polling', its likely some of the tuning there is insufficient. What do you have HZ set to (sysctl kern.clockrate)? I would probably have it set to ~1000. You will want 'machdep.cpu_idle_hlt=1'. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
device polling takes more CPU hits??
Hi all, I've got a weird case on my hands on a 2.8ghz xeon w/ HTT working as a router w/ device polling... This is a single-processor 2.8ghz xeon, not dual/quad, etc. The kernel does have SMP compiled in though. The box has two gig-e cards, em0 and bge0. bge0 is the uplink to the core, em0 is the downlink to the ethernet switch with 802.1q vlans for customer aggregation. During daytime, the box pushes about 15kpps at rate of roughly 12% interrupt CPU load. Sometimes when it spikes to 100kpps (rare, but happens), cpu load goes up as high as 30% on interrupts. Now these figures are w/ device polling off. As soon as I turn device polling ON, interrupt load climbs from 12% to 23%. During spikes, it climbs to about 48% to 50%. Any idea why device polling is kind of having... negative impact? Is this b/c I have SMP compiled on a box that really doesn't have two cpu's?? Is SMP+APIC_IO support even required for HTT use? The version btw is FreeBSD 4.9-STABLE. hardware info: Jul 21 23:09:24 r2.bos /kernel: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2788.16-MHz 686-class CPU) Jul 21 23:09:24 r2.bos /kernel: Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Jul 21 23:09:25 r2.bos /kernel: em0: port 0xccc0-0xccff mem 0xfcd0-0xfcd3,0xfcd4-0xfcd5 irq 7 at device 6.0 on pci3 Jul 21 23:09:25 r2.bos /kernel: bge0: mem 0xfcf2-0xfcf2,0xfcf3-0xfcf3 irq 2 at device 0.0 on pci2 Jul 21 23:09:25 r2.bos /kernel: bge1: mem 0xfcf0-0xfcf0,0xfcf1-0xfcf1 irq 5 at device 0.1 on pci2 Thanks for any tips! -J -- James JunTowardEX Technologies, Inc. Technical LeadNetwork Design, Consulting, IT Outsourcing [EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spoofed MAC on a dhcp interface
On Sun, Jul 25, 2004 at 05:52:57PM -0700 I heard the voice of Charlie Schluting, and lo! it spake thus: > Hi :) > > /etc/rc.conf: > ifconfig_xl0="ether 00:11:11:11:11:11" > ifconfig_xl0="DHCP" > > The above doesn't work.. Because that's setting a variable. If you set a variable, then set it to something else, it doesn't keep the old value around for sport :) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: spoofed MAC on a dhcp interface
Charlie Schluting wrote: Hi :) /etc/rc.conf: ifconfig_xl0="ether 00:11:11:11:11:11" ifconfig_xl0="DHCP" The above doesn't work.. I'm trying to set the mac, and then dhcp.. is this the correct way? With this config, its not getting the mac assigned to xl0, so I have to stop dhclient, run "ifconfig ether 00:11:11:11:11:11" manually, then dhcp again. I needed to do the exact thing so I could switch to replace dead NIC without having to involve my Cable company. /etc/rc.conf: ifconfig_xl0="DHCP" # DHCP on external interface The key was created /etc/start_if.xl0: #!/bin/sh # # Needed to fake my MAC at Comcast # /sbin/ifconfig xl0 ether 00:80:c8:de:1a:50 /sbin/ifconfig xl0 up Jim -- /"\ ASCII Ribbon Campaign . \ / - NO HTML/RTF in e-mail . X - NO Word docs in e-mail . / \ - [EMAIL PROTECTED] http://www.FreeBSD.org The Power to Serve [EMAIL PROTECTED] http://www.TheHousleys.net - A Microsoft Certified Systems Engineer is to computing what a McDonalds Certified Food Specialist is to fine cuisine. -- Jack O'Neill smime.p7s Description: S/MIME Cryptographic Signature
Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description --- o [1999/11/26] kern/15095 net TCP's advertised window is not scaled imm o [2001/02/08] kern/24959 net proper TCP_NOPUSH/TCP_CORK compatibility o [2003/07/11] kern/54383 net NFS root configurations without dynamic p 3 problems total. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
