Re: qmail IO--qmail vs postfix competition
Just curious how you pull this off? so 4 million/30=133 thousand emails per mail server roughly. So how do you distribute between the machines evenly into ezmlm as well? On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Date: Tue, 20 Feb 2001 15:35:31 -0800 (PST) > From: Gordon Tetlow <[EMAIL PROTECTED]> > To: Dan Phoenix <[EMAIL PROTECTED]> > Cc: Jesper Skriver <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: qmail IO--qmail vs postfix competition > > On Tue, 20 Feb 2001, Dan Phoenix wrote: > > > On Tue, 20 Feb 2001, Gordon Tetlow wrote: > > > > > Yep, that's 4 million unique emails. Actually, I should qualify that, it > > > took 4 hours for the mail servers to accept and queue them. The outgoing > > > probably took a bit longer, but from the way the queues stacked up, it > > > probably wasn't more than 5 hours to get all the deliverable messages out > > > (except for excite.com which wasn't taking mail at the time). > > > > when you say "about 30 mailers" are you talking about 30 separate > > machines? > > Yes, 30 machines that live to deliver. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, 20 Feb 2001, Dan Phoenix wrote: > On Tue, 20 Feb 2001, Gordon Tetlow wrote: > > > Yep, that's 4 million unique emails. Actually, I should qualify that, it > > took 4 hours for the mail servers to accept and queue them. The outgoing > > probably took a bit longer, but from the way the queues stacked up, it > > probably wasn't more than 5 hours to get all the deliverable messages out > > (except for excite.com which wasn't taking mail at the time). > > when you say "about 30 mailers" are you talking about 30 separate > machines? Yes, 30 machines that live to deliver. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Date: Tue, 20 Feb 2001 15:13:11 -0800 (PST) > From: Gordon Tetlow <[EMAIL PROTECTED]> > To: Jesper Skriver <[EMAIL PROTECTED]> > Cc: Dan Phoenix <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: qmail IO--qmail vs postfix competition > > On Tue, 20 Feb 2001, Jesper Skriver wrote: > > > On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: > > > My company (online greeting cards) sent our 4 million emails in 4 hours > > > using a cluster of about 30 mailers with qmail on FreeBSD (old version of > > > FreeBSD at that). That averages to 16,666 mail messages per minute or > > > about 500 per minute per server. The best part was the servers weren't > > > breaking a sweat. > > > > Is that 4 million different emails, or a much lower number of mails with > > multiple recipients ? > > Yep, that's 4 million unique emails. Actually, I should qualify that, it > took 4 hours for the mail servers to accept and queue them. The outgoing > probably took a bit longer, but from the way the queues stacked up, it > probably wasn't more than 5 hours to get all the deliverable messages out > (except for excite.com which wasn't taking mail at the time). > > -gordon > when you say "about 30 mailers" are you talking about 30 separate machines? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fwd: Re: Re: postfix: No buffer space available
Here's what has happened with the advice earlier: >tried to add the following via sysctl.conf > >kern.ipc.maxsockets = 5000 >kern.ipc.maxsockbuf = 524288 > >But neither parameter takes effect. are these read-only values?? and: ># netstat -m >445/720/4096 mbufs in use (current/peak/max): > 172 mbufs allocated to data > 273 mbufs allocated to packet headers >154/252/1024 mbuf clusters in use (current/peak/max) >684 Kbytes allocated to network (61% in use) >0 requests for memory denied >0 requests for memory delayed >0 calls to protocol drain routines Anybody got any other ideas how scale FreeBSD up to postfix's needs? tia, Len http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: Re: postfix: No buffer space available
Since nobody else has asked this, I think I will: What network device are you using and with what driver? Please show the output of `ifconfig -a' when you notice this problem. Finally, try `ifconfig down' followed by `ifconfig up' when you notice this, and see if it temporarily fixes the problem. Thanks to Matthew Dodd and NetBSD, I think we may have a solution to the ep wedging problems (which has similar symptoms, by the way) sometime soon (i.e. when I get around to it this weekend, after first mid-term, if noone beats me to it). In the meantime, it would be nice to know if there are other devices exhibiting this behavior. (All this assuming, of course, that what you're describing is not the result of a kernel resource shortage, such as mbuf starvation, etc.) Regards, Bosko. Renaud Waldura wrote: > > >But neither parameter takes effect. > > They may be read-only if you're running with securelevel > 0. Otherwise they > "take effect" just fine. > > > > Anybody got any other ideas how scale FreeBSD up to postfix's needs? > > > Yes, recompile your kernel with "maxusers 128" or more. This tweaks a bunch > of stuff, notably mbufs. > > E.g. with 128 "users" I've got: > > 226/1920/10240 mbufs in use (current/peak/max): > 159 mbufs allocated to data > 67 mbufs allocated to packet headers > 130/1438/2560 mbuf clusters in use (current/peak/max) > 3116 Kbytes allocated to network (9% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > > --Renaud > > > > > > - Original Message - > From: "Len Conrad" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, February 20, 2001 1:36 PM > Subject: Fwd: Re: Re: postfix: No buffer space available > > > > Here's what has happened with the advice earlier: > > > > >tried to add the following via sysctl.conf > > > > > >kern.ipc.maxsockets = 5000 > > >kern.ipc.maxsockbuf = 524288 > > > > > >But neither parameter takes effect. > > > > are these read-only values?? and: > > > > ># netstat -m > > >445/720/4096 mbufs in use (current/peak/max): > > > 172 mbufs allocated to data > > > 273 mbufs allocated to packet headers > > >154/252/1024 mbuf clusters in use (current/peak/max) > > >684 Kbytes allocated to network (61% in use) > > >0 requests for memory denied > > >0 requests for memory delayed > > >0 calls to protocol drain routines > > > > Anybody got any other ideas how scale FreeBSD up to postfix's needs? > > > > tia, > > Len > > > > > > http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K > > http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-hackers" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Well, as I said, these boxes are rather bored. I don't think the load > reaches above 0.05. Most of the time is delivering mail trying to > negotiate with destination hosts. I don't think that the mailers are IO > bound, but I haven't really looked to find out to tell you the truth. Once > the mailers are set up we treat them as black boxes. They just work. Aye. So is the one I was mentioning. I keep trying to get it to do more, but dan doesnt have any more mail to throw at it :-). It is totally idle though. Yes that is also a problem with his site, a good chunk of the mailings are to incorrect hotmeail.com, ecite.com, places :) And most of the places have VERY slow front end mail servers like you noted. Wish there was something one could do about that. But alas... > Also, the 500K number, is that per day? The 4 million was in 4 hours, not > a day. Below is what he was doing on a single ATA disk. Not even ATA100. Thehn we transitioned him to a 3 x 9.1GB IBM Deathstar Vinum RAID-0 stripe for /var/spool/postfix/. Not to shabby for a single disk IDE server. I was impressed. And yes these are for 24h. I don't have stats on the SCSI array yet. Hopefully I can get those tonight. But the IDE disk below was totally hammered. Between Postfix slamming the disks until there was no I/O left and logging on the same drive, it was pretty ugly to watch :-) Grand Totals messages 292315 received 288975 delivered 7 forwarded 6803 deferred (22932 deferrals) 28822 bounced 9 rejected 903m bytes received 930m bytes delivered 837 senders 485 sending hosts/domains 193110 recipients 28337 recipient hosts/domains smtpd 100118 connections 15 hosts/domains 0 avg. connect time (seconds) 8:17:03 total connect time = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: Re: postfix: No buffer space available
> >But neither parameter takes effect. They may be read-only if you're running with securelevel > 0. Otherwise they "take effect" just fine. > Anybody got any other ideas how scale FreeBSD up to postfix's needs? Yes, recompile your kernel with "maxusers 128" or more. This tweaks a bunch of stuff, notably mbufs. E.g. with 128 "users" I've got: 226/1920/10240 mbufs in use (current/peak/max): 159 mbufs allocated to data 67 mbufs allocated to packet headers 130/1438/2560 mbuf clusters in use (current/peak/max) 3116 Kbytes allocated to network (9% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines --Renaud - Original Message - From: "Len Conrad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 20, 2001 1:36 PM Subject: Fwd: Re: Re: postfix: No buffer space available > Here's what has happened with the advice earlier: > > >tried to add the following via sysctl.conf > > > >kern.ipc.maxsockets = 5000 > >kern.ipc.maxsockbuf = 524288 > > > >But neither parameter takes effect. > > are these read-only values?? and: > > ># netstat -m > >445/720/4096 mbufs in use (current/peak/max): > > 172 mbufs allocated to data > > 273 mbufs allocated to packet headers > >154/252/1024 mbuf clusters in use (current/peak/max) > >684 Kbytes allocated to network (61% in use) > >0 requests for memory denied > >0 requests for memory delayed > >0 calls to protocol drain routines > > Anybody got any other ideas how scale FreeBSD up to postfix's needs? > > tia, > Len > > > http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K > http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
OpenSSH 2.5.1
--Repost--- If duplicated, ignore this. thanks. --- Hi I have made a patch to up ssh version 2.3.0(FreeBSD-current) to recently released OpenSSH 2.5.1. Too rough made and it should have more measurements especially in, - SKEY or OPIE functions. - Kerberos4/5 functions. I could not compile with -DSKEY and -DK... options yet. Patch file is too large(gziped 170k+ ;-)to attach here, so I put it in http://www.c-wind.com/~tomo/230-250.diff.gz - /usr/src/crypto/openssh diffs - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 http://www.c-wind.com/~tomo/secure-251.tar.gz - /usr/src/secure Makefiles - MD5 (secure-251.tar.gz) = 7c23bc97fd1e8a48034509b2169dca91 Thanks, -- tomo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, 20 Feb 2001, Gordon Tetlow wrote: > Forgot to add info about the mailers. Each has a hardware raid controller > with about 32MB of memory on the controller configured to RAID-1 2HDs for > redundancy. Ideally, the mail never actually hits the disk but resides > exclusively in memory. Aha. That explains it. You use HW raid. I wondered why you were only doing 4 million mails for *30* boxes. Dan, is doing 500K, on a completely idle box (cpu/ram/I/O wise), with vinum, Postfix, and RAID-0. Have you seen brad knowles papers on vinum vs HW raid? It's erm enlightening to say the least :) Id be happy to dig up the URL if you are interested. I personally will be using Vinum from now on. The performance is very impressive. = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating BSD bootable CD
Dave Smith wrote: > > On Tue, Feb 20, 2001 at 01:16:17PM +1300, David Preece wrote: > > I started in the handbook, the section on backups and creating a bootable > > floppy was invaluable. It's also worth trawling the archives of > > freebsd-small, in particular look for "tinybsd" which (IIRC) is a > > configurable script for making a small installation of FreeBSD without > > going to the lengths that pico goes to, crunchgen etc. As far as I remember, there is not much special. Just create a bootable floppy image and give it as option -b to mkhybrid. (I strongly recommend mkhybrid over mkisofs because it tends to make defective filesystems in fewer cases). > Thanks. I'm already investigating this stuff. One more question -- is > there a list of all valid /dev nodes? cd /dev sh MAKEDEV all should do it. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, 20 Feb 2001, Dan Phoenix wrote: > Just curious how you pull this off? > so 4 million/30=133 thousand emails per mail server roughly. > So how do you distribute between the machines evenly into ezmlm as > well? We use Alteon load balancers to take care of the balancing part, after that, qmail just works. We did add a hack for a deferral server option to qmail, meaning after 10 minutes of undeliverable mail (configurable), the mail gets tossed to another server that tries for up to 2 days before discarding. This keeps our frontline mailservers from dealing with all the people that can't spell hotmail.com (you wouldn't believe the number). The frontline mailservers peaked at about 600-800 messages in the queue when sending out the 4 million while the deferral servers were sitting about 1 messages (up from a normal 7000 or so, also we had 8 deferrals in rotation). Also of importance is that we are whitelisted everywhere possible to make sure that we are rate limited on the amount of mail we send (aol is a good example of that). I think that describes the general gist of our mail situation. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, 20 Feb 2001, Jesper Skriver wrote: > On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: > > My company (online greeting cards) sent our 4 million emails in 4 hours > > using a cluster of about 30 mailers with qmail on FreeBSD (old version of > > FreeBSD at that). That averages to 16,666 mail messages per minute or > > about 500 per minute per server. The best part was the servers weren't > > breaking a sweat. > > Is that 4 million different emails, or a much lower number of mails with > multiple recipients ? Yep, that's 4 million unique emails. Actually, I should qualify that, it took 4 hours for the mail servers to accept and queue them. The outgoing probably took a bit longer, but from the way the queues stacked up, it probably wasn't more than 5 hours to get all the deliverable messages out (except for excite.com which wasn't taking mail at the time). -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
On Tue, Feb 20, 2001 at 01:22:57AM -0800, Gordon Tetlow wrote: > My company (online greeting cards) sent our 4 million emails in 4 hours > using a cluster of about 30 mailers with qmail on FreeBSD (old version of > FreeBSD at that). That averages to 16,666 mail messages per minute or > about 500 per minute per server. The best part was the servers weren't > breaking a sweat. Is that 4 million different emails, or a much lower number of mails with multiple recipients ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Switching from buildkernel to config seems to recompile the entire kernel
"Matthew Emmerton" <[EMAIL PROTECTED]> writes: > A surprising number of things get recompiled when the slightest change is > made to a kernel configuration. [...] Not relevant. The point here is that 'make buildkernel' uses a compile directory in /usr/obj, while the old 'config & make' method uses a compile directory in /usr/src. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: Re: postfix: No buffer space available
On Tue, 20 Feb 2001, Len Conrad wrote: > >kern.ipc.maxsockets = 5000 > >kern.ipc.maxsockbuf = 524288 > > > >But neither parameter takes effect. If the sysctl's are read only that you want to change slap them in your /boot/loader.rc \ Increase MBUF's for purpose of testing Postfix under alot of connections. set kern.ipc.nmbclusters=65536 That is what I have on mine to increase mbuf's. But I beat Postfix to death with benchmarks and testing it for the book. heh Also you can set the above to read only variables in /boot/loader.rc as well. Then they take effect after reboot. Maxfiles is what i usually hit first, then ipc.sockets. Mbuf's havent been a real problem :) = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tommorow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! Author of upcoming book on Postfix ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
Let's look at implementation of getaddrinfo(3) function (there are some
functions more which
do the same way). We can find source for this function in
/usr/src/lib/libc/net/getaddrinfo.c file.
This functions in some case reads /etc/hosts file and try to find out there
host name. getaddrinfo(3)
calls some functions and function _gethtent() tries to read line by linefrom
/etc/hosts file:
static struct addrinfo *
_gethtent(hostf, name, pai)
FILE *hostf;
const char *name;
const struct addrinfo *pai;
{
char *p;
char *cp, *tname, *cname;
struct addrinfo hints, *res0, *res;
int error;
const char *addr;
char hostbuf[8*1024];
again:
if (!(p = fgets(hostbuf, sizeof hostbuf, hostf)))
return (NULL);
if (*p == '#')
goto again;
if (!(cp = strpbrk(p, "#\n")))
goto again;
*cp = '\0';
if (!(cp = strpbrk(p, " \t")))
goto again;
*cp++ = '\0';
We can see if line is bigger than 8k, then _gethtent() reads until the end
of line.
In most case this function doesn't find needed host name in such lines, but
in some case it can find part of
line as correct host name and tries to fetch IP address, but it also will
not work, because we lose
beginning of line when "goto again".
This code can be simply rewriten as loop with fgets(), strlen()/strchr() and
realloc(), but it causes
speed lost in this function.
Also I understand that 8k for line in /etc/hosts is enough and should not be
problem for most of _real life_
situations.
Matt Dillon <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> :> fgets() with the proper length limitation, using a statically
allocated
> :> buffer is not a big deal. Most configuration files couldn't have
long
> :> lines and still be legal anyway.
> :
> :Note that the classical loop
> :while (fgets(buf, n, fp) != NULL) {
> : tokenize(buf, args...);
> : ...
> : }
> :may have problems if the line is too long, so one needs to detect it by
> :looking for the '\n'. if none is found, then one can either abort on
error
> :or ignore the line. In the latter case, you need to read the remaining
chars
> :so that the next fgets won't get them.
> :
> :regards,
> :mouss
>
> Yes, but we are talking about simple stupid config files here.
Programs
> which actually tokenize an input stream typically do not use fgets().
> Tokenizers either use [f]lex, [f]getc(), read() (and handle the
buffering
> themselves), or mmap().
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
Have you tried playing with: kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.maxsockets: 4136 The first one looks particularly interesting. --Renaud - Original Message - From: "Len Conrad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 20, 2001 6:28 AM Subject: postfix: No buffer space available > Sorry to bother you hackers again, but two submissions to -questions > got no response so it looks like another scaleability issue on you > people can handle : > > > > On a very busy postfix relay hub, we're seeing this: > > Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer > space available > > Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer > space available > > Can we fix this with a systcl write? > > The server already has: > > # sysctl -a | grep maxfile > kern.maxfiles: 16384 > kern.maxfilesperproc: 16384 > > ... which fixed "fatal: too many files open" pb for this client last > November. > > btw, Wietse Venema himself asked me to be informed of how I manage to > tweak FreeBSD to handle this apparent scaleability issue. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
Jason Brazile <[EMAIL PROTECTED]> writes: > I want to construct a portable Makefile to build a java application. Don't bother. a) use jikes instead of javac, it's much faster and gives better diagnostics. b) to rebuild, just list all the source (.java) files on the jikes command line. Jikes will figure out what needs rebuilding and what doesn't. If there are too many files, list them all (each on one line) in a text file (e.g. 'sources') and specify '@sources' on the command line. If there is a single file in your project that directly or indirectly depends on every other, you can also just specify that one file on the command line. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
> > Disagree. If you want it to be portable, don't use a non-standard > > extension to a tool, such as jikes dependency features. > > > > We used jikes for our day-day development, but move back to using > > 'javac' for our Q/A and final builds. That way we can complain to Sun > > when things don't work. ;) > > So what's the problem? javac also automatically builds dependencies, > it's just not as good at it as jikes. Not in a way that's usable my make. Jike can be used to build external dependency files. > Also, my experience is that unless you're paying Sun significant > amounts of $$, their reaction to bug reports is to close their eyes, > hum real loud and hope they go away. True, but Sun is no different than anyone else in that regard. I have found the individual developers somewhat more easy to work with, if you can get a contact within Sun. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
Nate Williams <[EMAIL PROTECTED]> writes: > Disagree. If you want it to be portable, don't use a non-standard > extension to a tool, such as jikes dependency features. > > We used jikes for our day-day development, but move back to using > 'javac' for our Q/A and final builds. That way we can complain to Sun > when things don't work. ;) So what's the problem? javac also automatically builds dependencies, it's just not as good at it as jikes. For a final build, you want to start with a clean tree anyway, so javac's inability to correctly detect if a dependency is out of date is irrelevant. Also, my experience is that unless you're paying Sun significant amounts of $$, their reaction to bug reports is to close their eyes, hum real loud and hope they go away. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
> Jason Brazile <[EMAIL PROTECTED]> writes: > > I want to construct a portable Makefile to build a java application. > > Don't bother. > > a) use jikes instead of javac, it's much faster and gives better > diagnostics. Agreed. > b) to rebuild, just list all the source (.java) files on the jikes > command line. Jikes will figure out what needs rebuilding and what > doesn't. If there are too many files, list them all (each on one > line) in a text file (e.g. 'sources') and specify '@sources' on > the command line. Disagree. If you want it to be portable, don't use a non-standard extension to a tool, such as jikes dependency features. We used jikes for our day-day development, but move back to using 'javac' for our Q/A and final builds. That way we can complain to Sun when things don't work. ;) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: make bug? (dependency names with '$')
> > > > I want to construct a portable Makefile to build a java application. > > > I've played with Java and Make in the past, but I found that spawning a new > instance of the Java compiler is more expensive than compiling a pretty big > bunch of files. gcc starts up a lot quicker than a JVM. Jikes is your friend. We switched from using javac because of this. Nate ps. This should probably be moved to freebsd-java. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
Jason Brazile writes: > > : I want to construct a portable Makefile to build a java application. > > > > That's not possible. Java specifies a half assed make system as part > > of the language, so it is nearly impossible to use another make system > > on top of it unless you are willing to live with a whole slew of > > problems. That's not true. I built a 100K line application using make w/out any problems. (It builds on Win9X, NT, FreeBSD, and Solaris). Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
In the last episode (Feb 20), Len Conrad said: > Sorry to bother you hackers again, but two submissions to -questions > got no response so it looks like another scaleability issue on you > people can handle : > > > > On a very busy postfix relay hub, we're seeing this: > > Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer space available > Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer space available I bet you're running out of mbufs. If netstat -m shows either 'current' or 'peak' anywhere near 'max', you'll want to raise either maxusers or "options NMBCLUSTERS" and rebuild your kernel. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
At 11:34 20/02/01 -0700, Drew Eckhardt wrote: >These control the default socket buffer size. Assuming postfix >is not setting the appropriate socket options, when they are increased >space will run out with even fewer connections. If they are decreased >such that they are less than the bandwidth delay product, you will have >TCP/IP performance problems. > >The original poster needs to play with some of the kern.ipc values >instead, most notably kern.ipc.maxsockbuf. You're right. a quick check shows that ENOBUFS may be caused by too many things, including mbuf allocation failures, and even the network interface queue has its "word"... cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >You might want to try setting > net.inet.tcp.sendspace > net.inet.tcp.recvspace >to larger values. I have these in my /etc/sysctl.conf. These control the default socket buffer size. Assuming postfix is not setting the appropriate socket options, when they are increased space will run out with even fewer connections. If they are decreased such that they are less than the bandwidth delay product, you will have TCP/IP performance problems. The original poster needs to play with some of the kern.ipc values instead, most notably kern.ipc.maxsockbuf. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: COPTFLAGS without -O in /etc/make.conf breaks kernel make
At 05:51 20/02/01 +0100, Cyrille Lefevre wrote: >"Julian Stacey" <[EMAIL PROTECTED]> writes: > > > Here's a weirdness in 4.2-RELEASE kernel generation: > > - Compiling a GENERIC kernel _Without -O optimiser causes a broken make ! > > - Compiling a GENERIC kernel _With_ -O optimiser compiles OK. > >this question is cyclic. and yes, the kernel *have* to be compiled >w/ -O turned on. sorry, I don't remember why. > >if you want yo put something to COPTFLAGS, try something like this : As far as I know, "-O" is necessary because of the "-Wuninitialized" option. but I'm not sure if removing the latter will make you able to compile without -O. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
In message <[EMAIL PROTECTED]> Jason Brazile writes: : Warner wrote: : > In message <[EMAIL PROTECTED]> Jason Brazile writes: : > : I want to construct a portable Makefile to build a java application. : > : > That's not possible. Java specifies a half assed make system as part : > of the language, so it is nearly impossible to use another make system : > on top of it unless you are willing to live with a whole slew of : > problems. : : Until someone started using inner classes, my Makefiles were being : fairly successful at "living with a whole slew of problems". :-) There are bigger problems when you have .java files generated. That's why java's make like system is half assed, and the wrong half at that. There's no hook there to generate .java files. If you needed to support multiple versions of java w/o warnings, for example, you'd need to run your .java code through a preprocessor (since java's conditionals are too weak to allow for this possibility). That's when you start hitting heap bigtime problems. This does sound like a bug in our make :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
You might want to try setting
net.inet.tcp.sendspace
net.inet.tcp.recvspace
to larger values. I have these in my /etc/sysctl.conf.
regards,
mouss
At 15:28 20/02/01 +0100, Len Conrad wrote:
>Sorry to bother you hackers again, but two submissions to -questions got
>no response so it looks like another scaleability issue on you people can
>handle :
>
>
>
>On a very busy postfix relay hub, we're seeing this:
>
>Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer
>space available
>
>Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer
>space available
>
>Can we fix this with a systcl write?
>
>The server already has:
>
># sysctl -a | grep maxfile
>kern.maxfiles: 16384
>kern.maxfilesperproc: 16384
>
>... which fixed "fatal: too many files open" pb for this client last November.
>
>btw, Wietse Venema himself asked me to be informed of how I manage to
>tweak FreeBSD to handle this apparent scaleability issue.
>
>"sysctl -a"
>
>gives:
>
>kern.ostype: FreeBSD
>kern.osrelease: 4.1.1-RELEASE
>kern.osrevision: 199506
>kern.version: FreeBSD 4.1.1-RELEASE #0: Tue Sep 26 00:46:59 GMT 2000
> [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC
>
>kern.maxvnodes: 32525
>kern.maxproc: 532
>kern.maxfiles: 16384
>kern.argmax: 65536
>kern.securelevel: -1
>kern.hostname: imgate2.snip.net
>kern.hostid: 0
>kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024,
>stathz = 128 }
>kern.posix1version: 199309
>kern.ngroups: 16
>kern.job_control: 1
>kern.saved_ids: 0
>kern.boottime: { sec = 982608649, usec = 136401 } Mon Feb 19 13:50:49 2001
>kern.domainname:
>kern.osreldate: 411000
>kern.bootfile: /kernel
>kern.maxfilesperproc: 16384
>kern.maxprocperuid: 531
>kern.dumpdev:
>kern.ipc.maxsockbuf: 262144
>kern.ipc.sockbuf_waste_factor: 8
>kern.ipc.somaxconn: 128
>kern.ipc.max_linkhdr: 16
>kern.ipc.max_protohdr: 60
>kern.ipc.max_hdr: 76
>kern.ipc.max_datalen: 136
>kern.ipc.nmbclusters: 1024
>kern.ipc.semmap: 30
>kern.ipc.semmni: 10
>kern.ipc.semmns: 60
>kern.ipc.semmnu: 30
>kern.ipc.semmsl: 60
>kern.ipc.semopm: 100
>kern.ipc.semume: 10
>kern.ipc.semusz: 92
>kern.ipc.semvmx: 32767
>kern.ipc.semaem: 16384
>kern.ipc.shmmax: 4194304
>kern.ipc.shmmin: 1
>kern.ipc.shmmni: 96
>kern.ipc.shmseg: 64
>kern.ipc.shmall: 1024
>kern.ipc.shm_use_phys: 0
>kern.ipc.mbuf_wait: 32
>kern.ipc.mbtypes: 460 164 160 0 0 0 0 0 0 0 0 0 0 0 0 0
>kern.ipc.nmbufs: 4096
>kern.ipc.maxsockets: 1064
>kern.dummy: 0
>kern.ps_strings: 3217031152
>kern.usrstack: 3217031168
>kern.logsigexit: 1
>kern.cam.cd.changer.min_busy_seconds: 5
>kern.cam.cd.changer.max_busy_seconds: 15
>kern.fallback_elf_brand: 9
>kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
>kern.module_path: /;/boot/;/modules/
>kern.acct_suspend: 2
>kern.acct_resume: 4
>kern.acct_chkfreq: 15
>kern.timecounter.method: 0
>kern.timecounter.hardware: i8254
>kern.ps_arg_cache_limit: 256
>kern.ps_argsopen: 1
>kern.fast_vfork: 1
>kern.randompid: 0
>kern.ps_showallprocs: 1
>kern.shutdown.poweroff_delay: 5000
>kern.shutdown.kproc_shutdown_wait: 60
>kern.sugid_coredump: 0
>kern.coredump: 1
>kern.corefile: %N.core
>kern.quantum: 10
>kern.ccpu: 1948
>kern.fscale: 2048
>kern.devstat.numdevs: 7
>kern.devstat.generation: 7
>kern.devstat.version: 4
>kern.nselcoll: 60034
>kern.consmute: 0
>kern.filedelay: 30
>kern.dirdelay: 29
>kern.metadelay: 28
>kern.chroot_allow_open_directories: 1
>vm.loadavg: { 0.39 0.43 0.52 }
>vm.v_free_min: 886
>vm.v_free_target: 2906
>vm.v_free_reserved: 248
>vm.v_inactive_target: 4359
>vm.v_cache_min: 2906
>vm.v_cache_max: 5812
>vm.v_pageout_free_min: 34
>vm.pageout_algorithm: 0
>vm.swap_enabled: 1
>vm.swap_async_max: 4
>vm.swap_idle_threshold1: 2
>vm.swap_idle_threshold2: 10
>vm.v_free_severe: 567
>vm.stats.sys.v_swtch: 15651300
>vm.stats.sys.v_trap: 1045137
>vm.stats.sys.v_syscall: 53830549
>vm.stats.sys.v_intr: 19460810
>vm.stats.sys.v_soft: 3519936
>vm.stats.vm.v_vm_faults: 610808
>vm.stats.vm.v_cow_faults: 138115
>vm.stats.vm.v_cow_optim: 0
>vm.stats.vm.v_zfod: 310288
>vm.stats.vm.v_ozfod: 309994
>vm.stats.vm.v_swapin: 0
>vm.stats.vm.v_swapout: 0
>vm.stats.vm.v_swappgsin: 0
>vm.stats.vm.v_swappgsout: 0
>vm.stats.vm.v_vnodein: 374
>vm.stats.vm.v_vnodeout: 0
>vm.stats.vm.v_vnodepgsin: 2490
>vm.stats.vm.v_vnodepgsout: 0
>vm.stats.vm.v_intrans: 2
>vm.stats.vm.v_reactivated: 125
>vm.stats.vm.v_pdwakeups: 0
>vm.stats.vm.v_pdpages: 0
>vm.stats.vm.v_dfree: 0
>vm.stats.vm.v_pfree: 355480
>vm.stats.vm.v_tfree: 809980
>vm.stats.vm.v_page_size: 4096
>vm.stats.vm.v_page_count: 127974
>vm.stats.vm.v_free_reserved: 248
>vm.stats.vm.v_free_target: 2906
>vm.stats.vm.v_free_min: 886
>vm.stats.vm.v_free_count: 97173
>vm.stats.vm.v_wire_count: 8879
>vm.stats.vm.v_active_count: 11659
>vm.stats.vm.v_inactive_target: 4359
>vm.stats.vm.v_inactive_count: 10259
>vm.stats.vm.v_cache_count: 4
>vm.stats.vm.v_cache_min: 2906
>vm.stats.vm.v_cache_max: 5812
>vm.stats.vm.v_pageout_free_min: 34
>vm.stats.vm.v_interrupt_free_
Re: Switching from buildkernel to config seems to recompile the entire kernel
In message <003001c09b4c$48226f90$[EMAIL PROTECTED]> "Matthew Emmerton" writes: : A surprising number of things get recompiled when the slightest change is : made to a kernel configuration. I've often wondered myself why removing one : line (such as psuedo-device bpf) forces lots of stuff to be recompiled (like : the ahc driver). This is due to a bug in kmod.mk that I've been testing a fix for. The short answer is that it is because all the targets depend on the symbolic link, which means that if the directory changes, they get recompiled. I'll go ahead and commit this later today if I can find time to hook up my laptop. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
>Have you tried playing with: > >kern.ipc.maxsockbuf: 262144 >kern.ipc.sockbuf_waste_factor: 8 >kern.ipc.maxsockets: 4136 > >The first one looks particularly interesting. We have of course looked at that, and "guessed" it was as interesting as you did. I'm looking for some more precise guidance, if it's available, before we go twisting knobs and pushing buttons to see what happens. however, the cowboy rode over the hill and found this Indian: # /sbin/sysctl -w kern.ipc.maxsockets=5000 sysctl: oid 'kern.ipc.maxsockets' is read only Len http://BIND8NT.MEIway.com : Binary for ISC BIND 8.2.3 for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-spam mail gateways To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
On Tue, Feb 20, 2001 at 06:14:42PM +0300, Andrey Simonenko wrote: > Let's look at implementation of getaddrinfo(3) function (there are some > functions more which > do the same way). We can find source for this function in > /usr/src/lib/libc/net/getaddrinfo.c file. > > This functions in some case reads /etc/hosts file and try to find out there > host name. getaddrinfo(3) > calls some functions and function _gethtent() tries to read line by linefrom > /etc/hosts file: [snip code] > We can see if line is bigger than 8k, then _gethtent() reads until the end > of line. > In most case this function doesn't find needed host name in such lines, but > in some case it can find part of > line as correct host name and tries to fetch IP address, but it also will > not work, because we lose > beginning of line when "goto again". > > This code can be simply rewriten as loop with fgets(), strlen()/strchr() and > realloc(), but it causes > speed lost in this function. > > Also I understand that 8k for line in /etc/hosts is enough and should not be > problem for most of _real life_ > situations. I'm coming in late in this thread. What is it you are trying to accomplish? FWIW, I've rewritten this and lots of code like it while revamping nsswitch. Unlike the traditional code, I am careful to handle lines of arbitrary length by processing only chunks (e.g. 512 bytes) at a time. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
OpenSSH 2.5.1
Hi I have made a patch to up ssh version 2.3.0(FreeBSD-current) to recently released OpenSSH 2.5.1. Too rough made and it should have more measurements especially in, - SKEY or OPIE functions. - Kerberos4/5 functions. I could not compile with -DSKEY option yet and I did not test Kerberos'. Patch file is too large(gziped 170k+ ;-)to attach here, so I put it in http://www.c-wind.com/~tomo/230-250.diff.gz - /usr/src/crypto/openssh diffs - MD5 (230-251.diff.gz) = 9ff326a90d1f0b6d2eb0f863defdc129 http://www.c-wind.com/~tomo/secure-251.tar.gz - /usr/src/secure Makefiles - MD5 (secure-251.tar.gz) = 7c23bc97fd1e8a48034509b2169dca91 Thanks, -- tomo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
Warner wrote: > In message <[EMAIL PROTECTED]> Jason Brazile writes: > : I want to construct a portable Makefile to build a java application. > > That's not possible. Java specifies a half assed make system as part > of the language, so it is nearly impossible to use another make system > on top of it unless you are willing to live with a whole slew of > problems. Until someone started using inner classes, my Makefiles were being fairly successful at "living with a whole slew of problems". :-) > d=$$ > X=foo$dbar.class > > x:$(X) > echo "$(X)" Thanks for the suggestion. I named this target "w" in order to add to what I already had: X=foo$bar.class XX=foo$$bar.class XXX=foo\$$bar.class d=$$ W=foo$dbar.class .PHONY: x xx xxx yy w x: $(X) echo $(X) xx: $(XX) echo $(XX) xxx: $(XXX) echo $(XXX) yy: $(XX) echo $(XXX) w: $(W) echo "$(W)" However, other than the quotes, it doesn't seem to work differently from my previous "xx" target: $ make w make: don't know how to make fooar.class. Stop $ gmake w echo "foo$bar.class" foo.class $ make xx make: don't know how to make fooar.class. Stop $ gmake xx echo foo$bar.class foo.class Kees Jan wrote: > Have you looked at Apache's Ant project? I don't like it myself, but if you > want a portable make, you might as well use a Java one. :) Hmm, well thanks for reminding me about ant. I guess I should really consider it, unless I am ready to admit to being an old dog. Jason Jason Brazile [EMAIL PROTECTED] Netcetera AG, 8040 Zuerichphone +41 1 247 70 70 fax +41 1 247 70 75 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: make bug? (dependency names with '$')
Dear Jason, > > I want to construct a portable Makefile to build a java application. > I've played with Java and Make in the past, but I found that spawning a new instance of the Java compiler is more expensive than compiling a pretty big bunch of files. gcc starts up a lot quicker than a JVM. My solution (ahem) is to compile per (sub)package of my application and simply let the JAR file depend on all of the source files. Compiling this way is quicker in the majority of cases that I have. Have you looked at Apache's Ant project? I don't like it myself, but if you want a portable make, you might as well use a Java one. :) Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Switching from buildkernel to config seems to recompile the entire kernel
> I cvsup'ed my 4.2-stable box and did the usual > make buildworld > make buildkernel KERNCONF= > where KNAME is the name of theconfig file > make installkernel KERNCONF= > make installworld > > and then rebooted the box. A short while I modified my kernel config > to remove sl and ppp. I then did a /usr/sbin/config > > This seems to recompile all the modules and the entire kernel even though > I expected only a few things to be recompiled and the kernel relinked A surprising number of things get recompiled when the slightest change is made to a kernel configuration. I've often wondered myself why removing one line (such as psuedo-device bpf) forces lots of stuff to be recompiled (like the ahc driver). -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
In message <[EMAIL PROTECTED]> Warner Losh writes: : This seems like a bug in make(1). Although I think you might want to : investigate: : : d=$$ : X=foo\$dbar.class : : x: : echo $(X) d=$$ X=foo$dbar.class x: $(X) echo "$(X)" Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make bug? (dependency names with '$')
In message <[EMAIL PROTECTED]> Jason Brazile writes: : I want to construct a portable Makefile to build a java application. That's not possible. Java specifies a half assed make system as part of the language, so it is nearly impossible to use another make system on top of it unless you are willing to live with a whole slew of problems. : When a java source file contains an inner class, it creates class : I could live with having to use something like the "yy" target if it : worked with BSD make, because it works with GNU make. This seems like a bug in make(1). Although I think you might want to investigate: d=$$ X=foo\$dbar.class x: echo $(X) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
postfix: No buffer space available
Sorry to bother you hackers again, but two submissions to -questions
got no response so it looks like another scaleability issue on you
people can handle :
On a very busy postfix relay hub, we're seeing this:
Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer
space available
Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer
space available
Can we fix this with a systcl write?
The server already has:
# sysctl -a | grep maxfile
kern.maxfiles: 16384
kern.maxfilesperproc: 16384
... which fixed "fatal: too many files open" pb for this client last
November.
btw, Wietse Venema himself asked me to be informed of how I manage to
tweak FreeBSD to handle this apparent scaleability issue.
"sysctl -a"
gives:
kern.ostype: FreeBSD
kern.osrelease: 4.1.1-RELEASE
kern.osrevision: 199506
kern.version: FreeBSD 4.1.1-RELEASE #0: Tue Sep 26 00:46:59 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC
kern.maxvnodes: 32525
kern.maxproc: 532
kern.maxfiles: 16384
kern.argmax: 65536
kern.securelevel: -1
kern.hostname: imgate2.snip.net
kern.hostid: 0
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024,
stathz = 128 }
kern.posix1version: 199309
kern.ngroups: 16
kern.job_control: 1
kern.saved_ids: 0
kern.boottime: { sec = 982608649, usec = 136401 } Mon Feb 19 13:50:49 2001
kern.domainname:
kern.osreldate: 411000
kern.bootfile: /kernel
kern.maxfilesperproc: 16384
kern.maxprocperuid: 531
kern.dumpdev:
kern.ipc.maxsockbuf: 262144
kern.ipc.sockbuf_waste_factor: 8
kern.ipc.somaxconn: 128
kern.ipc.max_linkhdr: 16
kern.ipc.max_protohdr: 60
kern.ipc.max_hdr: 76
kern.ipc.max_datalen: 136
kern.ipc.nmbclusters: 1024
kern.ipc.semmap: 30
kern.ipc.semmni: 10
kern.ipc.semmns: 60
kern.ipc.semmnu: 30
kern.ipc.semmsl: 60
kern.ipc.semopm: 100
kern.ipc.semume: 10
kern.ipc.semusz: 92
kern.ipc.semvmx: 32767
kern.ipc.semaem: 16384
kern.ipc.shmmax: 4194304
kern.ipc.shmmin: 1
kern.ipc.shmmni: 96
kern.ipc.shmseg: 64
kern.ipc.shmall: 1024
kern.ipc.shm_use_phys: 0
kern.ipc.mbuf_wait: 32
kern.ipc.mbtypes: 460 164 160 0 0 0 0 0 0 0 0 0 0 0 0 0
kern.ipc.nmbufs: 4096
kern.ipc.maxsockets: 1064
kern.dummy: 0
kern.ps_strings: 3217031152
kern.usrstack: 3217031168
kern.logsigexit: 1
kern.cam.cd.changer.min_busy_seconds: 5
kern.cam.cd.changer.max_busy_seconds: 15
kern.fallback_elf_brand: 9
kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
kern.module_path: /;/boot/;/modules/
kern.acct_suspend: 2
kern.acct_resume: 4
kern.acct_chkfreq: 15
kern.timecounter.method: 0
kern.timecounter.hardware: i8254
kern.ps_arg_cache_limit: 256
kern.ps_argsopen: 1
kern.fast_vfork: 1
kern.randompid: 0
kern.ps_showallprocs: 1
kern.shutdown.poweroff_delay: 5000
kern.shutdown.kproc_shutdown_wait: 60
kern.sugid_coredump: 0
kern.coredump: 1
kern.corefile: %N.core
kern.quantum: 10
kern.ccpu: 1948
kern.fscale: 2048
kern.devstat.numdevs: 7
kern.devstat.generation: 7
kern.devstat.version: 4
kern.nselcoll: 60034
kern.consmute: 0
kern.filedelay: 30
kern.dirdelay: 29
kern.metadelay: 28
kern.chroot_allow_open_directories: 1
vm.loadavg: { 0.39 0.43 0.52 }
vm.v_free_min: 886
vm.v_free_target: 2906
vm.v_free_reserved: 248
vm.v_inactive_target: 4359
vm.v_cache_min: 2906
vm.v_cache_max: 5812
vm.v_pageout_free_min: 34
vm.pageout_algorithm: 0
vm.swap_enabled: 1
vm.swap_async_max: 4
vm.swap_idle_threshold1: 2
vm.swap_idle_threshold2: 10
vm.v_free_severe: 567
vm.stats.sys.v_swtch: 15651300
vm.stats.sys.v_trap: 1045137
vm.stats.sys.v_syscall: 53830549
vm.stats.sys.v_intr: 19460810
vm.stats.sys.v_soft: 3519936
vm.stats.vm.v_vm_faults: 610808
vm.stats.vm.v_cow_faults: 138115
vm.stats.vm.v_cow_optim: 0
vm.stats.vm.v_zfod: 310288
vm.stats.vm.v_ozfod: 309994
vm.stats.vm.v_swapin: 0
vm.stats.vm.v_swapout: 0
vm.stats.vm.v_swappgsin: 0
vm.stats.vm.v_swappgsout: 0
vm.stats.vm.v_vnodein: 374
vm.stats.vm.v_vnodeout: 0
vm.stats.vm.v_vnodepgsin: 2490
vm.stats.vm.v_vnodepgsout: 0
vm.stats.vm.v_intrans: 2
vm.stats.vm.v_reactivated: 125
vm.stats.vm.v_pdwakeups: 0
vm.stats.vm.v_pdpages: 0
vm.stats.vm.v_dfree: 0
vm.stats.vm.v_pfree: 355480
vm.stats.vm.v_tfree: 809980
vm.stats.vm.v_page_size: 4096
vm.stats.vm.v_page_count: 127974
vm.stats.vm.v_free_reserved: 248
vm.stats.vm.v_free_target: 2906
vm.stats.vm.v_free_min: 886
vm.stats.vm.v_free_count: 97173
vm.stats.vm.v_wire_count: 8879
vm.stats.vm.v_active_count: 11659
vm.stats.vm.v_inactive_target: 4359
vm.stats.vm.v_inactive_count: 10259
vm.stats.vm.v_cache_count: 4
vm.stats.vm.v_cache_min: 2906
vm.stats.vm.v_cache_max: 5812
vm.stats.vm.v_pageout_free_min: 34
vm.stats.vm.v_interrupt_free_min: 2
vm.stats.misc.zero_page_count: 70388
vm.stats.misc.cnt_prezero: 376460
vm.max_proc_mmap: 36401
vm.pageout_stats_max: 2906
vm.pageout_full_stats_interval: 20
vm.pageout_stats_interval: 5
vm.pageout_stats_free_max: 5
vm.swap_idle_enabled: 0
vm.defer_swapspace_pageouts: 0
vm.disable_swapspace_pageouts: 0
vm.max_page_launder: 32
vm.zone:
ITEMSIZE LIMITUSED
Re: Staticaly allocated buffers in library. Is it correct?
At 12:46 19/02/01 -0800, Matt Dillon wrote: >Yes, but we are talking about simple stupid config files here. Programs > which actually tokenize an input stream typically do not use fgets(). > Tokenizers either use [f]lex, [f]getc(), read() (and handle the buffering > themselves), or mmap(). I used the tokenize() just as an example. I consider that every program that reads a line thinks it is a line and that the next fgets will read the _next_ line. but fgets doesn't guarantee that. so we have the following alternatives: - assume the file is well formed (no too long lines). - check that the lines are not too long. I personally prefer the second alternative. It has a cost, but this is more robust. How many times have we seen things assumed for some time, and then the code reused by someone else in another purpose but failing to check that the assumptions are no more true. This has often resulted in security problems. So I'd go for "trust BUT control". and this is even more important in library functions. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
make bug? (dependency names with '$')
Background:
I want to construct a portable Makefile to build a java application.
When a java source file contains an inner class, it creates class
file names with an embedded '$'.
$ cat foo.java
public class foo {
private class bar {
}
}
$ javac foo.java
$ ls
foo$bar.class foo.class foo.java
Problem:
- BSD make seems to have trouble with dependencies whose names contain $.
- I can construct a case where GNU make is happy enough, but BSD make isn't.
Test Case:
$ cat Makefile
X=foo$bar.class
XX=foo$$bar.class
XXX=foo\$$bar.class
.PHONY: x xx xxx yy
x: $(X)
echo $(X)
xx: $(XX)
echo $(XX)
xxx: $(XXX)
echo $(XXX)
yy: $(XX)
echo $(XXX)
# LATEST BSD make (e.g. main.c at revision 1.46 2001/02/19 03:59:04)
$ make x
make: don't know how to make fooar.class. Stop
$ make xx
make: don't know how to make fooar.class. Stop
$ make xxx
make: don't know how to make foo\ar.class. Stop
$ make yy
make: don't know how to make fooar.class. Stop
# package: gmake-3.79.1 GNU version of 'make' utility
$ gmake x
gmake: *** No rule to make target `fooar.class', needed by `x'. Stop.
$ gmake xx
echo foo$bar.class
foo.class
$ gmake xxx
gmake: *** No rule to make target `foo\$bar.class', needed by `xxx'. Stop.
$ gmake yy
echo foo\$bar.class
foo$bar.class
Conclusion:
I could live with having to use something like the "yy" target if it
worked with BSD make, because it works with GNU make.
If people agree that this seems like a bug, I will try to see if I
can find where the problem is, but there are probably others who would
be more efficient at this.
Jason
Jason Brazile [EMAIL PROTECTED]
Netcetera AG, 8040 Zuerichphone +41 1 247 70 70 fax +41 1 247 70 75
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: isa/pnp modem not in sio.c
> > I constantly wonder why on earth the !#%$!^%!# modem vendors > dont use the > 'compatid' field to say 'this is compatable with a COM port' - and > everything would work nicely. > Because the drivers and the fluff they come with are rather excellent advertising platforms. Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO--qmail vs postfix competition
My company (online greeting cards) sent our 4 million emails in 4 hours using a cluster of about 30 mailers with qmail on FreeBSD (old version of FreeBSD at that). That averages to 16,666 mail messages per minute or about 500 per minute per server. The best part was the servers weren't breaking a sweat. Again as with all benchmarks you are talking about, there are lots of other factors then just "How fast does it push the mail." For what we do, qmail is a great solution. I've personally never looked at postfix, but I understand it to be a great MTA as well. I think in the end, you will find that both are very similar and that it's just a matter of personal preference. That being said, I'll be interested to see what the numbers come out to be. -gordon On Mon, 19 Feb 2001, Dan Phoenix wrote: > I would like to set up this challenge early next week. > NOw that I have taken out the IO issue with the mail servers > ...already proved postfix did better on I/O so now i want to eliminate > that factor to 2 exactly the same machines. I running qmail ...1 running > postfix to see which MTA has better sending speed on freebsd. > > What I have not decided on is benchmark program to use. > test will be how many outgoing it can send a sec for each. > I welcome benchmark proggies anyone can offer as a solution for this. > Much appreciated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
