Re: Socket so_linger setting
Matthew Dillon wrote: I think your patch is fine as is, Mike! Good find! Even though so_linger cannot be negative, it is often convenient to use a signed integer to store the value to avoid unexpected arithmatic results when mixing with signed operations. My quick perusal does not show any cases of this for so_linger, so we could make it unsigned, but I don't see any pressing need to do so. The range check would need to be in there in either case. Can I go ahead and commit it? What is the status with this? As far as I can tell, the fix is correct and needed for some Java/JCK issues (the issue can be worked around in the JVM but that is the incorrect place to deal with it) -Matt Matthew Dillon [EMAIL PROTECTED] :During some parameter limit checking work, I ran into what I believe to :be an error in FreeBSD. (Albeit unlikely to be hit) : :A setsockopt of the SO_LINGER field will cause strange results if :the value is set above 32767. : :This is due to the fact that in struct socket, the so_linger field :is a signed short and the parameter passed to setsockopt for linger :is a signed long. : :What happens is that any value between 32768 and 65535 will cause :so_linger to be negative. And then getsockopt will return a sign :extended negative value in the signed long field for linger. : :The trivial fix is to do the following: : :-- :--- uipc_socket.c Wed May 1 01:13:02 2002 :+++ /tmp/uipc_socket.c Fri Nov 1 06:55:10 2002 :@@ -1139,7 +1139,8 @@ : if (error) : goto bad; : :- so-so_linger = l.l_linger; :+ /* Limit the value to what fits in so_linger */ :+ so-so_linger = (l.l_linger SHRT_MAX ? SHRT_MAX : l.linger); : if (l.l_onoff) : so-so_options |= SO_LINGER; : else :-- : :What this does is limit the value to no more than 32767 (SHRT_MAX) :However, I believe the more correct answer is that so_linger should :not be a signed value to begin with. : :The reasoning is that what does a negative so_linger mean? To :close the socket before the user does ;^)? : :It is somewhat obvious that so_linger does not need to be a long. : :It is not possible to change the API to make the input a short. : :Limiting the value to 32767 is reasonable (and that is a *vary* :long linger time) : :However, given that negative linger values really don't exist :(logically) it would be reasonable to not that field be signed. :That would naturally limit the values to being within a valid :range and prevent some strange results, specifically when :looking at the tsleep() call where the so_linger field is :just blindly multiplied by the hz of the system. (around line :312 of uipc_socket.c) A segative so_linger will get sign extended :into a negative int (32-bit) (times hz) and then passed to tsleep :which just checks for zero, passed on to timeout which then :passes it to callout_reset. It turns out that callout_reset will :take negative values and make them a single tick... (whew! lucky :thing that was there :-) : :The question I have is: should put together a patch that changes :so_linger (and xso_linger) to unsigned? (And make sure there are :no bad side effects) or is the trivial fix above what is wanted? : :[ My personal feeling is that since so_linger has no valid negative : value that the field should be unsigned. Not that it matters : about improving the range as 32767 is over 9 hours. It is more : a matter of correctness in the code/representation since the : code assumes the value is not negative already. ] : :-- :Michael Sinz -- Director, Systems Engineering -- Worldgate Communications :A master's secrets are only as good as : the master's ability to explain them to others. 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: Socket so_linger setting
Matthew Dillon wrote: I was going to wait till 5.0 released first but I could do it now if you want. It would help the Java work but I don't know if it is critical to be done today vs some short time in the future. (Depends on the timing of the Java project and the wish to get JCK cert) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Socket so_linger setting
During some parameter limit checking work, I ran into what I believe to be an error in FreeBSD. (Albeit unlikely to be hit) A setsockopt of the SO_LINGER field will cause strange results if the value is set above 32767. This is due to the fact that in struct socket, the so_linger field is a signed short and the parameter passed to setsockopt for linger is a signed long. What happens is that any value between 32768 and 65535 will cause so_linger to be negative. And then getsockopt will return a sign extended negative value in the signed long field for linger. The trivial fix is to do the following: -- --- uipc_socket.c Wed May 1 01:13:02 2002 +++ /tmp/uipc_socket.c Fri Nov 1 06:55:10 2002 @@ -1139,7 +1139,8 @@ if (error) goto bad; - so-so_linger = l.l_linger; + /* Limit the value to what fits in so_linger */ + so-so_linger = (l.l_linger SHRT_MAX ? SHRT_MAX : l.linger); if (l.l_onoff) so-so_options |= SO_LINGER; else -- What this does is limit the value to no more than 32767 (SHRT_MAX) However, I believe the more correct answer is that so_linger should not be a signed value to begin with. The reasoning is that what does a negative so_linger mean? To close the socket before the user does ;^)? It is somewhat obvious that so_linger does not need to be a long. It is not possible to change the API to make the input a short. Limiting the value to 32767 is reasonable (and that is a *vary* long linger time) However, given that negative linger values really don't exist (logically) it would be reasonable to not that field be signed. That would naturally limit the values to being within a valid range and prevent some strange results, specifically when looking at the tsleep() call where the so_linger field is just blindly multiplied by the hz of the system. (around line 312 of uipc_socket.c) A segative so_linger will get sign extended into a negative int (32-bit) (times hz) and then passed to tsleep which just checks for zero, passed on to timeout which then passes it to callout_reset. It turns out that callout_reset will take negative values and make them a single tick... (whew! lucky thing that was there :-) The question I have is: should put together a patch that changes so_linger (and xso_linger) to unsigned? (And make sure there are no bad side effects) or is the trivial fix above what is wanted? [ My personal feeling is that since so_linger has no valid negative value that the field should be unsigned. Not that it matters about improving the range as 32767 is over 9 hours. It is more a matter of correctness in the code/representation since the code assumes the value is not negative already. ] -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Socket so_linger setting
Matthew Dillon wrote: I think your patch is fine as is, Mike! Good find! Even though so_linger cannot be negative, it is often convenient to use a signed integer to store the value to avoid unexpected arithmatic results when mixing with signed operations. My quick perusal does not show any cases of this for so_linger, so we could make it unsigned, but I don't see any pressing need to do so. The range check would need to be in there in either case. Can I go ahead and commit it? I would at least commit it as a range check... Maybe we should look at changing so_linger to unsigned too. (As I stated before, it documents the value range a bit more correctly and, with better compilers, the math errors would be warnings if you assumed signed-ness of the value :-) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. Actually, with minimal work in the rc.diskless* files, we have a very workable, large-scale system with / as Read-Only. In fact, only /dev and /var are read-write (well, in testing we also have a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp points are /var/tmp) One of these days I will want to write up some of what we did. It really is rather nice to have a whole cluster of machines sharing the same install and the boot server. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: syslogd and kqueue
David O'Brien wrote: On Sat, Oct 27, 2001 at 12:26:22AM -0400, Mike Barcroft wrote: Just to clarify. This is still a POLA violation. If a log file is pulled out from underneath syslogd(8), one wouldn't expect it to start logging again, even if the file was re-created. I disagree, if the file was re-created. Actually, I find it weird and counter intuitive that syslogd will not log to the files in the config file (/etc/syslog.conf) unless they already exists. It really feels like we are living with a programming bug 25 years later If I didn't want syslogd to log something, I would not have it in syslog.conf. This has bitten a number of support people - a server fills up and they get a bit too loose with the rm command and logging stops. I actually somewhat understand why syslogd does not open/create the file using the current syslog.conf syntax - it is hard to descript user/group ownership and access rights in the syslog.conf. The thing that syslogd does is write to the file that already exists such that the access rights can be controlled externally to the syslogd process. I really hate this and wish I could change this without suddenly causing all of us old-timers to surprised. For me I see two different POLA issues: 1) For those who have already understood and used syslog for a long time - syslogd does not create a file... 2) For those who have not had much time with syslog - it is rather upsetting to have configured syslog.conf and you either HUP or reboot and yet the logging does not start. As the world of FreeBSD (and other syslog systems) increases, the ratio of people is catagory #2 vs #1 will continue to increase. (Most people do not spend much time playing with syslogd) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ALT-sp (Was: how to make 'for' understand two words as asingleargumen)
Dag-Erling Smorgrav wrote: Michael Sinz [EMAIL PROTECTED] writes: BTW - How does your system represent a file with 0xA0 in it? An ls on FreeBSD 4.4-Stable seems to show it as: -rw-r--r-- 1 msinz msinz 0 Oct 3 12:00 foo?bar Interesting - not what I would have expected but I think non-printables are replaced by the ? when ls runs. Even more interesting is this: -rw-r--r-- 1 msinz msinz 0 Oct 3 12:00 foo?bar -rw-r--r-- 1 msinz msinz 1 Oct 3 12:05 foo?bar This is only interesting (in the sense in which you seem to use the word) to someone who has not read the ls(1) manual page, and does not know of the -q and -B options... This was within the context of alt-space replacing spaces in file names. As things stand now, it is not even easily usable as the main tool used to list the files in a directory does not show it correctly. (As far as the non-printables, I agree that LS is supposed to do, but is non-breaking space really a non-printable?) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: uptime and w utilities lie about real uptime
Vladimir B.Grebenschikov wrote:
Submitter-Id: current-users
Originator:Vladimir B. Grebenschikov
Organization: TSB Russian Express
Confidential: no
Synopsis: uptime and w utilities lie about real uptime
Severity: non-critical
Priority: low
Category: bin
Class: sw-bug
Release: FreeBSD 5.0-CURRENT i386
Environment:
System: FreeBSD vbook.express.ru 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Sep 19
20:26:25 MSD 2001 [EMAIL PROTECTED]:/usr/src.local/sys/i386/compile/VBOOK i386
Description:
Just after very fast boot uptimealways shows more than 30 sec.
looking to src/usr/bin/w/w.c:
if (sysctl(mib, 2, boottime, size, NULL, 0) != -1
boottime.tv_sec != 0) {
uptime = now - boottime.tv_sec;
uptime += 30;
== ^
days = uptime / 86400;
uptime %= 86400;
hrs = uptime / 3600;
uptime %= 3600;
mins = uptime / 60;
secs = uptime % 60;
(void)printf( up);
why utility increases uptime on 30 seconds ??
Is any real reasons for it ?
From my reading of this, it seems to want to round the uptime to
the nearest minute -- afterall, w and uptime both only show the uptime
in minutes (well, days, hours, and minutes)
--
Michael Sinz Worldgate Communications [EMAIL PROTECTED]
A master's secrets are only as good as
the master's ability to explain them to others.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Chris Costello wrote: On Friday, August 31, 2001, Michael Sinz wrote: I too have been hoping for (and building internal tools) that work this way. I really wish you could just do: open(nfs://server.name.dom/directory/file.txt) and have it work. That would be nice. (Replace the above with ftp: or http: or whatever other protocol would provide read and/or write access.) Anyway, I don't see it happening quickly but I don't see it as a bad thing and I would guess that it will eventually get to that point. (The network includes your local machine so why not) Whatever happened to not distinguishing different types of file systems from one another in pathnames? And are you suggesting that we add network overhead (I'd still imagine lo0 can't help speeding things up...) to file system accesses? What I was trying to say is that there is no reason that I should care if the file is local or not. Why should a program have to specifically offer support to edit that file from an FTP site. (EMACS and other editors have added transparent FTP support, but that was extra work for them) Just as the OS support having multiple storage devices and media and the software does not need to know if the file is on a SCSI or IDE disk or if it is on DISK 2 partition 3 or DISK 5 partition 1, why should it know if it is local or on the machine beside it or on the machine on the other side of the world? Now, the OS (from a technical level) should be smart enough to handle not doing actual NFS (or FTP or HTTP or whatever protocol) to its local disk when it can. (Sometimes going in via FTP to the local machine gets you in as a different user and thus gets you different access rights so the level of complexity is not always obviously trivial) Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Paul Chvostek wrote: On Fri, Aug 31, 2001 at 02:15:09PM -0400, Michael Sinz wrote: I too have been hoping for (and building internal tools) that work this way. I really wish you could just do: open(nfs://server.name.dom/directory/file.txt) NAME amd - automatically mount file systems ... DESCRIPTION Amd is a daemon that automatically mounts filesystems whenever a file or directory within that filesystem is accessed. Filesystems are automati- cally unmounted when they appear to be quiescent. Ahh, but that assumes that your AMD configuration has all systems and mount points enumerated in it. Let me see - I think that 30gig drive may be big enough for that file :-) and have it work. That would be nice. (Replace the above with ftp: or http: or whatever other protocol would provide read and/or write access.) What you're looking for is a substitute open() function. Perhaps someone should just write a URI base library. Put it in the public domain, of course, so that all UR base is belong to us Ahh, but that does not address all software. Sure, edit all source and make the call to open() now be a call to uri_open()... Why bother making the OS deal with the issues involved? The reason the OS should (and could) is that it is the base from which all such services grow. Now, in a microkernel design (such as the previously mentioned HURD) there are ways to extend the filesystem to include new types (FTPFS is a great example of such a filter/expansion) but in FreeBSD (very much not microkernel) this then becomes an OS issue or a user-program issue. If it is in user space you end up with some have it and some don't and some have some subset which makes it really nasty. Can you imagine if there was an ide_open() to open files on IDE drives and a scsi_open() to open files on SCSI drives? Or a UFS_open() vs an ext2_open() vs an FFS_open()? Why would you then want a uri_open() vs regular open()? ahem Watch those puns - I could end up returning them unopened :-) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gzipped crashdumps
John Polstra wrote: In article [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] wrote: Anyone else think this patch from NetBSD is worthwhile? Yes yes yes yes yes! That's 5 votes in favor of it already. :-) Add in another 50 here (the number of machines here that produce dumps in our test lab :-() -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Sansonetti Laurent wrote: Anyway, the point is that a file that I can access should be a file I can access via VI or MORE or EMACS or GREP or any other tool without having those tools each having FTP and HTTP and SSH support built in to them. The OS should handle it. Yes, this should be nice. There's a similar project for Linux here: http://ftpfs.sourceforge.net/ (FTP only). It would be amusing to port it into a KLD file. Hmmm... Looks like a good first step -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
made it work. I was not asking for a magic bullet. (Well, not this time :-) I was asking that the OS support reading and/or writing of data (whatever that may be) to a file/filehandle that was created via a standard system call. The data itself will have to be correct. I don't want to make some magic XDR type of thing. That is what XDR and/or file format definitions are for. But why should VI or EMACS have to have special code in each editor just so you can load/edit a file from FTP rather than local? -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
Steve Roome wrote: On Thu, Aug 30, 2001 at 11:17:08AM -0400, Keith Stevenson wrote: Ick. If I wanted this kind of integration I would run Windows, KDE, or GNOME instead of my nice, stable, predictable, lightweight desktop environment. This entire email is very IMHO Why? a URI is by name a Uniform Resource Locator, the standard idea being that anything can be referenced by using a uniform system. I mean other than the fact that it might look ugly, or not seem like a good idea, it's become a fairly standard way of addressing things. Anyway, how else would you wish to describe something that can quite legibly define a particular protocol to use on a particular port of a machine and furthermore can give extra information. I too have been hoping for (and building internal tools) that work this way. I really wish you could just do: open(nfs://server.name.dom/directory/file.txt) and have it work. That would be nice. (Replace the above with ftp: or http: or whatever other protocol would provide read and/or write access.) Anyway, I don't see it happening quickly but I don't see it as a bad thing and I would guess that it will eventually get to that point. (The network includes your local machine so why not) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: diskless
Danny Braniss wrote: not sure, i think i tried this at some point and had problems with bugs in the implementation of mount_union. If it works for you then i guess it is not problematic. One thing you cannot do with the above is delete files which are in the lower filesystem (not that the current rc.diskless1 does, but in principle you might want to do this). so far rc.diskless1 only populates, so removing is not a problem. the solution currently in rc.diskless1 actually does a merge of 2-3 different filesystems, so between the mounts you have to populate /conf/etc as well. that's why im using /etc and not /conf/etc, it was becoming to complicated having more than one /etc. the nice thing is that i can use the same root for non diskless too. We have done the same thing here with our large diskless clusters. I really hated not having the same / (root fs) on the server and diskless clients since it made things like updates that much harder. So, we built it such that / is the same on all (and read-only on the diskless crew) We then build a /dev (from mfs with MAKEDEV) and /var (using mtree) and /etc (using the current /etc and /comf/default/etc) (Too bad devfs is not running reliably - the Linux clusters save a some RAM and boot time using that) This whole set up means that if I install a port on the server, all of the clients get it. If I do a make world/etc for the OS, all of the clients get it. (Albeit we have to patch the rc.diskless* again to put back our changes) But it really works very well and saves us lots of grief in configuration and maintainance. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS local mount
Jonathan Chen wrote: On Thu, Jul 19, 2001 at 02:38:07PM -0400, Michael Sinz wrote: I had been meaning to ask if there was a reason why NFS mounts happened before NFS servers were started but life kept getting in the way :-) If /usr was nfs mounted on a machine, then /usr needs to be mounted before nfsd was loaded, and portmap/rpcgen lives in /usr and nfsd requires one of those. Not to mention there are probably other services loaded before nfsd which may require nfs moutned directories. In general, it is a good idea to first setup vital parts of the system (like networking or mounting directories) before offering other services (such as nfsd). Ahh, but a auto-backgrounding of NFS mounts would be nice. In (albeit old) SYSV R4 which we (my old Commodore hat) did on the Amiga UNIX project, NFS mounts would try for a bit at boot time and then switch into the background if they took too long. One could specifically ask for a mount to be hard such that it would not background under any conditions. Under normal conditions, the system had its mounts up before the rest of the RC process ran. Under poor conditions, it may end up waiting for some reasonable amount of time (was it 1 or 2 minutes - I can not remember) and then background any mounts that had not yet worked. This always let the system come up to at least admin capable level, which is important when you have a headless machine somewhere. Possible ways to fix this includes: - do nothing, let those who run these circular nfs-mount systems fix it themselves. Perhaps recommend -o bg in the handbook or something. That may be good - I still think some form of timeout and then bg option would be even better... - setup a flag, nfs_mount_delayed=YES|NO in rc.conf - do something in fstab which distingushes nfs mounts which can be delayed * a new nfs_delayed fstype [this screams EVILE HACK!], or * a new delayable option (how's that different from bg?) I see that as the timeout before bg - where it tries and tries but after some point says hey, it still is not up, lets bg this thing * overload the Pass number in fstab, nobody fscks over nfs anyway. I hate that - it feels soo bad. However, it also happens to be a good place to put in a configurable timeout for bg operation. Arg Don't do it - must not go to the dark side. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS local mount
Attila Nagy wrote: Hello, I am currently installing a machine on which I want to replace the NULL and/or UNIONFS mounts with NFS. NFS server and client on the same machine, to be exact, for jailing purposes (this seems to be the most stable). The problem is, that at the FreeBSD boot process the NFS filesystems are mounted before the NFS-related daemons are started, so I can't do this in a clean way (from /etc/fstab). Are there any objections to swap those two? I mean starting the NFS server and after that mounting the NFS filesystems? That would be nice since I have a problem here at WorldGate where a number of machines mount drives from eachother. If only one of them goes down at a time things are fine, but after a power outage they all block trying to mount each other and thus never start up the NFS server such that they can mount each other. My solution has been to have the NFS mounts happen as a background process and thus letting the rest of the network startup run and thus getting to start the NFS servers which then answer these background NFS mount requests. I had been meaning to ask if there was a reason why NFS mounts happened before NFS servers were started but life kept getting in the way :-) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
Terry Lambert wrote: Rajappa Iyer wrote: http://www.sysadminmag.com/articles/2001/0107/0107a/0107a.htm Any obvious reasons why FreeBSD performed so poorly for these people? Here is a repeat of my post to -advocacy: -- Terry The article is meaningless. Too bad they titled it Which OS is Fastest for High- Performance Network Applications? instead of Which OS is Fastest for MailEngine?. The only implied caveat is the statement Our customers frequently ask us which operating system is best for running our software in paragraph 3 of the Background section. This should have been in bold type in the first paragraph. -- It makes a number of very large blunders, which are really inexcusable, given that it tries to represent itself as a fair and unbiased comparison. Becareful before you state some of these - while I agree that the article and testing methods were not perfect, it is not what you think: 2) Threaded processes are vastly inferior to finite state automatons, when it comes to CPU utilization on single CPU systems, and even on multiple CPU systems, if there is async I/O that can be scheduled on multiple CPUs. That is both a true-ism and a false-ism, depending on the way it is coded, the coder, and the architecture of the OS and hardware... 3) FreeBSD turns of write caching on IDE drives, by default, in FreeBSD 4.3 and above; you can set it to be like Linux, Solaris, and Windows, if you don't care about your data. On FreeBSD 4.2 and below, Soft Updates are not enabled by default. Either way, without tuning, you lose. And if you read the article, you may find the following text: We installed all operating systems on identical 4-GB SCSI-3 drives (IBM model DCAS-34330), and ran the tests on the same machine (ASUS P3B motherboard, Intel Pentium III 550-MHz processor, 384-MB SDRAM, Adaptec 2940UW SCSI controller, ATI Rage Pro 3D video card, Intel EtherExpress Pro 10/100 Ethernet card). So, IDE drive issue (they just suck) is not an issue here. Yes, IDE has problems, but if they did not use it, don't claim that it was an issue. 4) IDE drives do not support tagged command queueing, except IBM DTLA drives, which are known to fail due to overheating and due to their electronics being too slow for their radial track density for interior tracks. Again, don't claim it as a problem when they specifically stated that SCSI was used and which specific SCSI drive and hardware setup. 5) Real servers with storage and I/O requirements use SCSI drives so they can benefit from tagged command queues, which allow I/O to be interleaved instead of serialized. I agree. And, it seems, so did the testers. [...] 13) For each connection, there is a tcptmpl structure, which is used for keepalives. This structure will consume one mbuf per connection; in addition, the average TCP window size will be 16k; so you will need 16k/2k (8) mbufs for custer pointers plus 16k/256 (64) mbufs for the window data, plus one mbuf per connection, pplus one mbuf per connection, if you are setting options. This means that you will potentially need 74 mbufs per connection you intend to support; without patching, this also is not tunable except at compile time, and the value was not tuned. Is this not a potential issue with the OS? 14) The average througput per network architecture is extremely misleading, both because of the limited and inefficient architectures used in the test, and in using an average to determine which was the best architecture for use on all OSs. Per OS numbers would have been much more meaningful, since the final architecture was chosen based on the average, and not based on what was best for the OS being tested. I fully agree. That part of the test/description was completely wrong just because it assumed too many things and did not give a reasonable example of each implementation (and how each did on each OS). It is obvious that in the current stable FreeBSD that anything that is heavily threaded will not do as well as on other operating systems that have better threading support. But this can also be seen as a reasonable complaint against FreeBSD. And we know that and the next major FreeBSD release will have addressed it. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Machines are getting too damn fast
Matt Dillon [EMAIL PROTECTED] wrote: Subject: Re: Machines are getting too damn fast :throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its :overclocked) here on my desk with 256KB L2 cache: : :dd if=/dev/zero of=/dev/null bs=512k count=4000 :4000+0 records in :4000+0 records out :2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec) : :dd if=/dev/zero of=/dev/null bs=128k count=16000 :16000+0 records in :16000+0 records out :2097152000 bytes transferred in 1.204001 secs (1741819224 bytes/sec) : :Now THAT is a significant difference. :-) Interesting. I get very different results with the 1.3 GHz P4. The best I seem to get is 1.4 GBytes/sec. I'm not sure what the L2 cache is on the box, but it's definitely a consumer model. dd if=/dev/zero of=/dev/null bs=512k count=4000 2097152000 bytes transferred in 2.363903 secs (887156520 bytes/sec) dd if=/dev/zero of=/dev/null bs=128k count=16000 2097152000 bytes transferred in 1.471046 secs (1425619621 bytes/sec) If I use lower block sizes the syscall overhead blows up the performance (it gets lower rather then higher). So I figure I don't have as much L2 as on your system. The P4 has other issues when you don't do straight line code. Any branch mis-predictions cost a minimum of 20 cycles due to the pipeline plus whatever cache/fetch/decode hits you may get on the actual target. This may be why you get lower values than a PIII or Athelon. (Both have significantly lower penalty for branch mis-prediction) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
