Recommended amount of swap
What is the state of the art for the recommended amount of swap in FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large database systems with around 128 - 256 GB. Thanks in advance, -- Sean Hamilton ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Detach USB Device Driver and Attach it to ugen driver at runtime
Hi, I'm using libusb to gain access to raw USB Data from userspace. My
problem is that this library only works with devices which are treated as
generic devices ("handled by the ugen driver"). I need a mechanism that will
allow me to detach any device specific drivers that are attached to a device
and attach the ugen driver instead. I want to do this without re-compiling
the FreeBSD Kernel. Thanks in advance for your help.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Detach USB Device Driver and Attach it to ugen driver at runtime
On Monday 05 September 2011 15:40:44 Daniel Grech wrote:
> Hi, I'm using libusb to gain access to raw USB Data from userspace. My
> problem is that this library only works with devices which are treated as
> generic devices ("handled by the ugen driver"). I need a mechanism that
> will allow me to detach any device specific drivers that are attached to a
> device and attach the ugen driver instead. I want to do this without
> re-compiling the FreeBSD Kernel. Thanks in advance for your help.
Hi,
The following functions should be implemented:
int
libusb20_dev_detach_kernel_driver(struct libusb20_device *pdev,
uint8_t iface_index);
int libusb_detach_kernel_driver(libusb_device_handle *devh, int
interface) or int libusb_detach_kernel_driver_np(libusb_device_handle
*devh, int interface) Detach a kernel driver from an interface. This is
needed to claim an interface required by a kernel driver. Returns 0 on
success, LIBUSB_ERROR_NOT_FOUND if no kernel driver was active,
LIBUSB_ERROR_INVALID_PARAM if the interface does not exist,
LIBUSB_ERROR_NO_DEVICE if the device has been disconnected and a
LIBUSB_ERROR code on failure. This function is non-portable.
man libusb20
man libusb
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: TIME_WAIT Assassination in FreeBSD???
On Sat, 3 Sep 2011, Jarrod Lee Petz wrote: 3. Does FreeBSD handle this situation? How? I can't seem to find much info on TIME_WAIT assassination in FreeBSD is mentioned in RFC 6056 I'm not familiar with the RFC side here, but I can confirm that FreeBSD will recycle TIMEWAIT connections more quickly than specified when load is very high. This is done on the basis of allocated space; the sysctl: net.inet.tcp.maxtcptw Instructs the stack regarding how much state to retain -- this is implemented by adjusting the allocation limit on the tcptw zone. On my system, it seems to auto-tune to about 5000 connections, a value derived from the global limit on the number of sockets on the box I'm looking at -- your mileage may vary. The resource limit case can occur in tcp_twstart(), when uma_zalloc() returns NULL on failing to allocate new TIMEWAIT state for a connection. At that point, it forces an early scan of TIMEWAIT connections (which normally happens on 2msl intervals) with a 'reuse' argument of 1, authorising premature reuse. Without too close an analysis, it appears on face value to implement LRU: we reuse storage held by the connection that has been in TIMEWAIT the longest. Robert ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: TIME_WAIT Assassination in FreeBSD???
In FreeBSD, the ftp client allocates the port for an active-mode data connection by calling bind(2) with so_port set to 0, which means it lets the kernel pick a port, see http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/lukemftp/src/Attic/ftp.c?rev=1.1.1.8;content-type=text%2Fplain;hideattic=0 The kernel code where the port is picked is in function in_pcb_lport(), see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_pcb.c?rev=1.281;content-type=text%2Fplain Basically, there is a range of ports (49152-65535, adjustable with sysctl), and the algorithm picks a random port within that range: if (dorandom) *lastport = first + (arc4random() % (last - first)); It checks whether that port is available. If not, it increments it by one, and tries again, etc. in a loop, until it finds one. So, for your case, it is unlikely that two subsequent bind() calls from the ftp client would result in the same port being picked randomly, unless a large part of the port range is unavailable. You can get port re-use that is quick enough to confuse pf, for instance, by opening new connections (to the same destination address and port) at a high rate, e.g. when running the Apache web server benchmark tool. But if you're simply running the ftp client on an otherwise idle host, and two subsequent bind() calls get assigned the same 'random' port, I'd say the port randomization is not working properly :) HTH, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
In the last episode (Sep 05), Sean Hamilton said: > What is the state of the art for the recommended amount of swap in > FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large > database systems with around 128 - 256 GB. I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of swap is probably never going to be used, and if it is used, you're just going to thrash your swap device. If you have 128GB of RAM and need to swap to disk, you desperately need more RAM, not swap :) -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
On Mon, Sep 5, 2011 at 3:48 PM, Dan Nelson wrote: > In the last episode (Sep 05), Sean Hamilton said: >> What is the state of the art for the recommended amount of swap in >> FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large >> database systems with around 128 - 256 GB. Keep in mind that you need at least ram = swap to get a coredump. > -- > Dan Nelson > dnel...@allantgroup.com > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
On Mon, 5 Sep 2011 14:48:57 -0500 Dan Nelson wrote: > In the last episode (Sep 05), Sean Hamilton said: > > What is the state of the art for the recommended amount of swap in > > FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large > > database systems with around 128 - 256 GB. > > I suggest 2x RAM for systems less than 4gb or so. Anything more than > 4GB of swap is probably never going to be used, and if it is used, > you're just going to thrash your swap device. but tmpfs (and swap-backed md devices) can use substantial amounts of swap without contributing to thrashing. In some cases it may be possible to justify larger amounts of swap. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
In the last episode (Sep 05), Eitan Adler said: > On Mon, Sep 5, 2011 at 3:48 PM, Dan Nelson wrote: > > In the last episode (Sep 05), Sean Hamilton said: > >> What is the state of the art for the recommended amount of swap in > >> FreeBSD? Both "normal" systems with 512 MB - 8 GB of RAM, and large > >> database systems with around 128 - 256 GB. > > Keep in mind that you need at least ram = swap to get a coredump. Not if debug.minidump is set to 1, which it is by default. In that case, only mapped memory gets dumped, which should ignore disk cache pages and be a lot smaller than your RAM size. Enabling ZFS may make your dumps bigger unless the minidump code is smart enough to not dump the ARC. -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Detach USB Device Driver and Attach it to ugen driver at runtime
On 05/09/2011, at 23:10, Daniel Grech wrote:
> Hi, I'm using libusb to gain access to raw USB Data from userspace. My
> problem is that this library only works with devices which are treated as
> generic devices ("handled by the ugen driver"). I need a mechanism that will
> allow me to detach any device specific drivers that are attached to a device
> and attach the ugen driver instead. I want to do this without re-compiling
> the FreeBSD Kernel. Thanks in advance for your help.
You can access the device via ugen even if a kernel driver has attached to it.
I suspect you wouldn't be able to if the kernel driver that did attach is in
use, but I am not sure.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Recommended amount of swap
On Mon, Sep 05, 2011 at 02:48:57PM -0500, Dan Nelson wrote: > I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of > swap is probably never going to be used I see you don't do mass package builds :-) Or, even build openoffice or some of the math packages. > and if it is used, you're just going to thrash your swap device. That's us! :-) mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
