Re: Timers in drivers vs userland

2008-10-18 Thread Len Gross
Slight correction; I should have said more accurate usleep, not "timer." -- Len On Sat, Oct 18, 2008 at 3:12 PM, Len Gross <[EMAIL PROTECTED]> wrote: > If I place a timer directly in a driver (like Ethernet) will it be > subject to less jitter and more consistency than if it were in > Userland?

Timers in drivers vs userland

2008-10-18 Thread Len Gross
If I place a timer directly in a driver (like Ethernet) will it be subject to less jitter and more consistency than if it were in Userland? I know FreeBSD is not "real time," but I need to be able to run a polling algorithm with about 1 ms accuracy. Thanks in advance. (Please tell me if there i

Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC?

2008-10-18 Thread Sam Leffler
Max Laier wrote: On Saturday 18 October 2008 19:05:26 Sam Leffler wrote: [EMAIL PROTECTED] wrote: Synopsis: [request] Isn't it time to enable IPsec in GENERIC? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 18 16:5

Re: SNMP High Capacity Counters

2008-10-18 Thread Eugene Grosbein
On Sat, Oct 18, 2008 at 07:18:52PM +0200, Hartmut Brandt wrote: > >I've just found that ports/net-snmp (version 5.4) built > >WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit > >ifHC* counters but it does not. > > > >It seems agent/mibgroup/if-mib/data_access/interface_sysct

Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC?

2008-10-18 Thread Max Laier
On Saturday 18 October 2008 19:05:26 Sam Leffler wrote: > [EMAIL PROTECTED] wrote: > > Synopsis: [request] Isn't it time to enable IPsec in GENERIC? > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: gavin > > Responsible-Changed-When: Sat Oct 18 16:55:14 UTC

Re: SNMP High Capacity Counters

2008-10-18 Thread Hartmut Brandt
Eugene Grosbein wrote: Hi! I've just found that ports/net-snmp (version 5.4) built WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit ifHC* counters but it does not. It seems agent/mibgroup/if-mib/data_access/interface_sysctl.c that obtains interface statistics from the ker

Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC?

2008-10-18 Thread Sam Leffler
[EMAIL PROTECTED] wrote: Synopsis: [request] Isn't it time to enable IPsec in GENERIC? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) for consideration h

Re: conf/128030: [request] Isn't it time to enable IPsec in GENERIC?

2008-10-18 Thread gavin
Synopsis: [request] Isn't it time to enable IPsec in GENERIC? Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sat Oct 18 16:55:14 UTC 2008 Responsible-Changed-Why: Over to maintainer(s) for consideration http://www.freebsd.org/cgi/qu

SNMP High Capacity Counters

2008-10-18 Thread Eugene Grosbein
Hi! I've just found that ports/net-snmp (version 5.4) built WITH_MFD_REWRITES=yes supports IF-MIB, and in theory should show 64-bit ifHC* counters but it does not. It seems agent/mibgroup/if-mib/data_access/interface_sysctl.c that obtains interface statistics from the kernel. The function netsnmp

Re: Closing connection from an accept_filter(9)

2008-10-18 Thread David DeSimone
Eugene M. Kim <[EMAIL PROTECTED]> wrote: > > Is it possible to close a connection from an accept filter, for > example, in order to prevent an incoming connection with a malformed > request body from ever reaching the userland? How would you propose to find out what is in the request body without

Re: kern/128181: [fxp]: Unread portion of the kernel message buffer

2008-10-18 Thread remko
Old Synopsis: Unread portion of the kernel message buffer New Synopsis: [fxp]: Unread portion of the kernel message buffer Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Sat Oct 18 08:14:54 UTC 2008 Responsible-Changed-Why: reassign