More benchmarking stuff...
Folks, In addition to the vinum vs. DPT SmartRAID IV benchmarking that I had done, I've also started doing filesystem/OS-level benchmarking with a program called "postmark" that Network Appliance wrote to show off the performance of their NetApp Filers. See http://www.netapp.com/tech_library/3022.html for the paper from NetApp that shows the performance of their filers against various other systems, and it also includes a link to the page where you can get the source code. The source code compiled and is running just fine for me under FreeBSD 3.3-RC. Not a single hitch. Their best results on an F630 with 1000 files and 50,000 transactions were 253 transactions per second, 799.91 KBytes/sec read, and 817.89 KBytes/sec written. I just ran this same test on an old PPro 200Mhz system with 128MB of RAM and softupdates on a Western Digital Enterprise 4.5GB hard drive. I got 282 transactions per second, 869.09 KBytes read per second, and 888.63 KBytes written per second! This ancient machine with a single slow hard drive, but running FreeBSD 3.3-RC with softupdates beats their *expensive* NFS file server!!! I'm going to run this on some other machines, including the same machine and disk without softupdates, FreeBSD 3.2-RELEASE on a dual-processor PIII @ 450Mhz without softupdates on both the single Western Digital boot disk and on the external DPT SmartRAID IV striped array of four IBM 10kRPM UltraStar 9LZX drives, a single processor Pentium III @ 450Mhz running Linux 2.9 on the internal hard drive and on the external DPT SmartRAID V controlled striped array of five Quantum Fireball 7200RPM 9GB drives (both mounted async and sync), and any other machines I can get my hands on. I think this is going to be fun! -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weird syscons keyboard behaviour
I've noticed some odd syscons keyboard behaviour over the past month or so. Sometimes I get a vty that outputs PC graphics characters for all of my input. This is always at a "login:" prompt. I think I can duplicate this by typing a bunch of garbage at a login prompt, but I don't feel like trying to test it right now and have to reboot my main machine. I just saw this again after a clean boot with a 24 hour old kernel. (built 07:00 a.m. 9/16/99 CST from a few hour old CVSup). The boot went fine, but when I started typing at the login prompt, all I got was garbage. I couldn't switch vty's or anything. I just gave up and hit the big red button. After the reboot, everything was fine. I think this might be some kind of timing problem. I was starting to type in my username right away when I saw the boot was finishing, and if I recall the past incidents correctly, I may have been doing the same thing. I've seen this probably 4 or 5 times in the past month, maybe 6 weeks. Anyone have any ideas what is going on? This is a Compaq AMD K6-2/400 machine. PS/2 style keyboard input to the motherboard. I'll be glad to supply any further details. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird syscons keyboard behaviour
Mike Pritchard wrote: I've noticed some odd syscons keyboard behaviour over the past month or so. Sometimes I get a vty that outputs PC graphics characters for all of my input. This is always at a "login:" prompt. I think I can duplicate this by typing a bunch of garbage at a login prompt, but I don't feel like trying to test it right now and have to reboot my main machine. I just saw this again after a clean boot with a 24 hour old kernel. (built 07:00 a.m. 9/16/99 CST from a few hour old CVSup). The boot went fine, but when I started typing at the login prompt, all I got was garbage. I couldn't switch vty's or anything. I just gave up and hit the big red button. After the reboot, everything was fine. I think this might be some kind of timing problem. I was starting to type in my username right away when I saw the boot was finishing, and if I recall the past incidents correctly, I may have been doing the same thing. I've seen this probably 4 or 5 times in the past month, maybe 6 weeks. Anyone have any ideas what is going on? Aye, I've seen it infrequently also. I've not spent any time trying to recreate the problem because it happens so infrequently. The system I've seen it on is an Intel 200MHz Pentium notebook (ChemUSA) also with PS/2 style input. I seem to recall seeing it for more than a month, maybe the last few (3 or 4) months. Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird syscons keyboard behaviour
I've noticed some odd syscons keyboard behaviour over the past
month or so. Sometimes I get a vty that outputs PC graphics characters
for all of my input. This is always at a "login:" prompt. I think
I can duplicate this by typing a bunch of garbage at a login prompt,
but I don't feel like trying to test it right now and have to
reboot my main machine.
[...]
I think this might be some kind of timing problem. I was starting
to type in my username right away when I saw the boot was finishing,
and if I recall the past incidents correctly, I may have been
doing the same thing.
I've seen this probably 4 or 5 times in the past month, maybe
6 weeks. Anyone have any ideas what is going on?
It appears that if you hit the keyboard before (at the boot loader
prompt or during the kernel is probing devices) or while the keyboard
driver is being initialized, you may see the problem.
The keyboard driver does try to flush keyboard input before it
manipulates the keyboard controller and the keyboard, but apparently it
is sometimes confused.
# One possible explanation for this failure of keyboard flushing is
# that the clock or timer calibration is not correctly done and I/O
# delay is not working properly. Well, I am not sure, though...
I have no idea why this is cropping up now, rather than before... The
AT keyboard driver has unchanged for some time. Yes, there has been
some commits in the past couple of months, but they don't change the
basic operation of the driver.
Would you please try the following patch for /sys/dev/kbd/atkbd.c and
see how it fares?
Kazu
Index: atkbd.c
===
RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v
retrieving revision 1.13
diff -u -r1.13 atkbd.c
--- atkbd.c 1999/08/15 06:06:14 1.13
+++ atkbd.c 1999/08/19 12:08:22
@@ -1154,7 +1189,7 @@
}
/* save the current controller command byte */
- empty_both_buffers(kbdc, 10);
+ empty_both_buffers(kbdc, 200);
c = get_controller_command_byte(kbdc);
if (c == -1) {
/* CONTROLLER ERROR */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
On Fri, Sep 17, 1999 at 11:24:41AM +0200, Brad Knowles wrote: Their best results on an F630 with 1000 files and 50,000 transactions were 253 transactions per second, 799.91 KBytes/sec read, and 817.89 KBytes/sec written. I just ran this same test on an old PPro 200Mhz system with 128MB of RAM and softupdates on a Western Digital Enterprise 4.5GB hard drive. I got 282 transactions per second, 869.09 KBytes read per second, and 888.63 KBytes written per second! This ancient machine with a single slow hard drive, but running FreeBSD 3.3-RC with softupdates beats their *expensive* NFS file server!!! My results running postmark on a PII-450 with 196MB RAM and an IBM Deskstar DJNA 352030 running -current as of a few weeks ago are: 1000/5 UFS+softupdates MFS NFS tr/s218 1562100 read kb/s 699.05 4870321.56 write kb/s 714.77 4980328.79 The NFS server is a PII-233 with 32MB RAM (I know...) and a Maxtor 91728D8 IDE disk running 3.2R. It seems strange that the 'old PPro 200' would have better results than my PII-450, but there's probably some optimizations that I haven't done yet. Alex -- ++---+ | SMTP: [EMAIL PROTECTED] | E-Gold: 101979 | | ICBM: N52 22.64'6 E4 51.54'1 | PGP: 0x1d512a3f | ++---+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird syscons keyboard behaviour
On Fri, Sep 17, 1999 at 02:45:08PM +0200, Soren Schmidt [EMAIL PROTECTED] wrote: prompt or during the kernel is probing devices) or while the keyboard driver is being initialized, you may see the problem. Hmm I've seen the problem where on "loose" the input at the loader prompt but it has always come back when syscons probes the keyboard. But I have also seen the other problem exactly two times, and the keyboard hasn't been touched at all those two times... I had written it of as a fluke in my screen/keyboard/mouse switchbox... I always get such behavior when I touch keyboard just before the autoboot begins countdown. It's reliably repeatable, but nothing I care much about. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
Re: More benchmarking stuff...
At 2:03 PM +0200 1999/9/17, Brad Knowles wrote: For this stage, I now get: Transactions per second:33 KBytes Read per second: 79.66 KBytes Written per second: 144.31 For the third and final stage (20,000 files and 100,000 operations), I get the following results: Transactions per second:38 KBytes Read per second: 102.84 KBytes Written per second: 142.15 I'll be doing these same tests on other machines and other configurations of similar machines, and will report the numbers as I can. If this sort of stuff should not be posted to the freebsd-current mailing list, I would appreciate someone letting me know now before I complete the process of making a complete and total fool of myself in the process. ;-) -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
On Sep 17, 2:03pm, Brad Knowles wrote: } Subject: Re: More benchmarking stuff... } } Sadly, when I go to the second set of tests (20,000 files and } 50,000 transactions), my performance goes into the crapper. I know } that softupdates trades memory for speed, and I guess this PPro 200 } w/ 128MB RAM just doesn't have enough memory to keep up. } } For this stage, I now get: } } Transactions per second:33 } KBytes Read per second: 79.66 } KBytes Written per second: 144.31 I'd expect a NetApp to do a lot better than UFS on FreeBSD if there are large directories. Directory lookups in UFS require a sequential scan whereas the NetApp filesystem uses some sort of hashing scheme. Also FreeBSD only caches a limited number of directory blocks. This was discussed on -hackers in April. Search for the subject "Directories not VMIO cached at all!". Matt Dillon posted a patch to to better cache directories (at the possible expense of wasted RAM and which breaks NFS) in Message-ID [EMAIL PROTECTED]. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
At 3:33 PM +0200 1999/9/17, Brad Knowles wrote: For the third and final stage (20,000 files and 100,000 operations), I get the following results: Transactions per second:38 KBytes Read per second: 102.84 KBytes Written per second: 142.15 Running the first test again on a much more powerful system (Dell PowerEdge 1300 Pentium III @ 450Mhz w/ 1MB L2 cache and 1GB RAM, running Linux 2.9, and on the internal Quantum Viking-II hard drive mounted "defaults" (including async) on /var), I get: Transactions per second:2380 MBytes Read per second: 7.31 MBytes Written per second: 7.47 This is on par with the kind of performance I'd expect to see on a similar machine running FreeBSD 3.x-STABLE and softupdates, but I don't know how it compares to -STABLE and standard Berkeley FFS. I'm running the second tests now. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
At 4:35 PM +0200 1999/9/17, Brad Knowles wrote: I'm running the second tests now. The second series of tests was *highly* educational. For the first time ever with postmark, I saw errors like this: Error: cannot open '34878' for writing Error: cannot open '34879' for writing .Error: Cannot delete '31484' .Error: cannot open '31483' for reading Error: Cannot delete '30648' .Error: cannot open '31483' for reading .Error: Cannot delete '30352' Done Deleting files...Error: Cannot delete '30352' Error: Cannot delete '30353' Error: Cannot delete '30648' Error: Cannot delete '31486' Error: Cannot delete '32103' I'm guessing that the async filesystem under Linux just couldn't keep up. I'm hoping that this hasn't permanently trashed that filesystem. ;-) I also noticed that system CPU usage was *much* higher under Linux than it was under FreeBSD. I saw peaks of 97% utilization in system time, and I'm going to re-run these tests under the bash "time" command to see if I can get some averages of system versus user mode usage, etc Anyway, the results I got were: Transactions per second:97 KBytes Read per second: 230.58 KBytes Written per second: 418.22 The re-run of the second sequence with "time" is now underway. I've also got back initial results of running postmark on a similar Dell PowerEdge 1300, but this time one with two 450Mhz processors. Otherwise, it is configured pretty much identically, at least for the subsystems I'm testing so far. The filesystem is *not* mounted with softupdates. The results I got were: Transactions per second:35 KBytes Read per second: 110.58 KBytes Written per second: 113.06 I'm re-running this command under bash "time" as well, and all future results to be reported will be likewise. I'm also going to go back and do the same for the tests I ran on the older PPro 200 machine with 128MB RAM. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
At 8:05 AM -0700 1999/9/17, Thomas Dean wrote: These tests with softupdates do not appear to be a test of the disk i/o system, but, a test of memory. Are the files deleted before they are actually written to disk? Good question. I don't know the answer. I know that the process is to create all the files first, then operate on them (including deletions and more creations), and then finally do a removal of all of them as quickly as possible at the end of the test. I'd be willing to guess a lot of files do get created and then deleted before the data ever gets written to disk. After all, postmark was written to simulate the kind of a load that a heavily-used mail system places on the machine, and that's precisely the sort of environment where something like softupdates or mounting filesystems async does tend to help the most. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
My results running postmark on a PII-450 with 196MB RAM and an IBM Deskstar DJNA 352030 running -current as of a few weeks ago are: 1000/5UFS+softupdates MFS NFS tr/s 218 1562100 read kb/s 699.05 4870321.56 write kb/s714.77 4980328.79 I tried it on my -current of 2 days ago: 1000/5 on a UFS+softupdates K6-2/300 64MB seagate 9.1 7200 EIDE tr/s 126 read kb/s 406.01 write kb/s 415.14 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
In the last episode (Sep 17), Brad Knowles said: At 8:05 AM -0700 1999/9/17, Thomas Dean wrote: Are the files deleted before they are actually written to disk? Good question. I don't know the answer. I know that the process is to create all the files first, then operate on them (including deletions and more creations), and then finally do a removal of all of them as quickly as possible at the end of the test. I'd be willing to guess a lot of files do get created and then deleted before the data ever gets written to disk. After all, postmark was written to simulate the kind of a load that a heavily-used mail system places on the machine, and that's precisely the sort of environment where something like softupdates or mounting filesystems async does tend to help the most. Hmm. But when you're running a mail spool, you _want_ your files to get committed to disk, don't you? If you've got (guessing) 500 spool files sitting in unflushed disk caches and you reboot, those files are lost. Softupdated just guarantees that the disk will be in a stable state after a crash, not that all data written before the crash will be available. Don't NetApps do logging, so if the system crashes, the files are recovered from the log? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
John-Mark Gurney wrote: John Polstra scribbled this message on Sep 12: Just to avoid duplicated effort: I currently have work in progress on a "fslog" pseudo-device. It enables you to monitor a filesystem and receive notifications for all interesting changes to files and directories. This includes reads, writes, renames, file creations, unlinks, links, etc. -- anything that changes the stat(2) results for a file, or causes directory entries to be created, destroyed, or changed. The device itself is working, but so far I have implemented the support for only a few of the event types. It won't take much more work to finish it. ugh, why aren't you extending poll to work on files and directories to get this info?? it would make MUCH more sense to extend poll to do this.. any specific reason why it wasn't done this way? Yes. Last time I checked, our CVS repository contained 50,000 files in 13,000 directories. Somehow the thought of a 63,000-element pollfd array leaves me cold. Sometimes you want to know about all changes in a whole tree of files. Poll isn't well-suited for that. John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
On Fri, 17 Sep 1999, Dan Nelson wrote: In the last episode (Sep 17), Brad Knowles said: At 8:05 AM -0700 1999/9/17, Thomas Dean wrote: Are the files deleted before they are actually written to disk? Good question. I don't know the answer. I know that the process is to create all the files first, then operate on them (including deletions and more creations), and then finally do a removal of all of them as quickly as possible at the end of the test. I'd be willing to guess a lot of files do get created and then deleted before the data ever gets written to disk. After all, postmark was written to simulate the kind of a load that a heavily-used mail system places on the machine, and that's precisely the sort of environment where something like softupdates or mounting filesystems async does tend to help the most. Hmm. But when you're running a mail spool, you _want_ your files to get committed to disk, don't you? If you've got (guessing) 500 spool files sitting in unflushed disk caches and you reboot, those files are lost. Softupdated just guarantees that the disk will be in a stable state after a crash, not that all data written before the crash will be available. Soft updates guarantees that when an fsync() is done, it's on disk... Don't NetApps do logging, so if the system crashes, the files are recovered from the log? -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
In message [EMAIL PROTECTED], John Polstra writes: ugh, why aren't you extending poll to work on files and directories to get this info?? it would make MUCH more sense to extend poll to do this.. any specific reason why it wasn't done this way? Yes. Last time I checked, our CVS repository contained 50,000 files in 13,000 directories. Somehow the thought of a 63,000-element pollfd array leaves me cold. Sounds like something Bruce would do :-) -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
At 10:46 AM -0500 1999/9/17, Dan Nelson wrote: Hmm. But when you're running a mail spool, you _want_ your files to get committed to disk, don't you? True enough. RFC 1123 requires that you *not* lost mail messages for stupid reasons like fileservers crashing, etc You do want those things written to disk. If you've got (guessing) 500 spool files sitting in unflushed disk caches and you reboot, those files are lost. Yup. They'd be gone. I guess my question would be how many messages in the spool that were in the process of being handled could be held in unflushed caches in memory? If that's only a few hundred files, and those few hundred files represent something like only a few seconds worth of mail, then just how literally are you going to take RFC 1123, and how much mail can a large operator "lose" before they are violating not only the "law" of RFC 1123, but also the spirit? These are tough, real-world questions that I don't really have any answers for. This is another reason that I occasionally continue to pester Eric Allman and Wietse Venema to make changes to their respective MTAs, so that they at least allow the option of holding open the connection to the transmitter and not return "250 Ok" until such time as the mail message(s) have actually been delivered to the mailboxes, as opposed to just written to spool. This kind of option would allow wicked-fast things such as running /var/spool/mqueue on a memory-based filesystem. Of course, you'd need a timeout and return something like "251 Okay, will spool" and a way to ensure that the spool file for that message has actually been written to physical disk, although perhaps this could be left up to the OS and the MTA just uses the standard system calls to move the file from one directory/filesystem to another (the source could be an mfs, while the target could be UFS). Of course, not everyone would want or could make use of an option like this, but I suspect that the largest sites needing the absolute maximum performance out of their multiple mail servers would be *real* happy if this sort of thing were possible. Don't NetApps do logging, so if the system crashes, the files are recovered from the log? The log-structured filesystem and snapshots are two advantages that Network Appliance NFS servers do have. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
On Fri, 17 Sep 1999, Matthew Dillon wrote: : files sitting in unflushed disk caches and you reboot, those files are : lost. Softupdated just guarantees that the disk will be in a stable : state after a crash, not that all data written before the crash will be : available. : : :Soft updates guarantees that when an fsync() is done, it's on disk... Actually it doesn't. I wish it did. All softupdates does is guarentee that the on-disk image is stable, it doesn't guarentee that the on-disk image has been synchronized to what the program thinks it has written to the file. According to kirk FSYNC() does the right thing and 'sync()' doesn't. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch to add bridging to vr Ethernet driver
Could someone *please* review and commit this patch to /sys/pci/if_vr.c?
I've been trying since June to get this into the source tree. If/when
this goes in you can close kern/12385. Thanks.
--lyndon
--- /sys/pci/if_vr.cFri Aug 27 18:50:59 1999
+++ if_vr.c Mon Sep 6 21:57:43 1999
@@ -79,6 +79,11 @@
#include net/bpf.h
#endif
+#include "opt_bdg.h"
+#ifdef BRIDGE
+#include net/bridge.h
+#endif /* BRIDGE */
+
#include vm/vm.h /* for vtophys */
#include vm/pmap.h/* for vtophys */
#include machine/clock.h /* for DELAY */
@@ -1415,7 +1420,21 @@
continue;
}
}
-#endif
+#endif /* NBPF0 */
+#ifdef BRIDGE
+ if (do_bridge) {
+ struct ifnet*bdg_ifp;
+ bdg_ifp = bridge_in(m);
+ if (bdg_ifp != BDG_LOCAL bdg_ifp != BDG_DROP)
+ bdg_forward(m, bdg_ifp);
+ if (((bdg_ifp != BDG_LOCAL) (bdg_ifp != BDG_BCAST)
+ (bdg_ifp != BDG_MCAST)) || bdg_ifp == BDG_DROP) {
+ m_freem(m);
+ continue;
+ }
+ }
+#endif /* BRIDGE */
+
/* Remove header from mbuf and pass it on. */
m_adj(m, sizeof(struct ether_header));
ether_input(ifp, eh, m);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 2xPIIIx450 results NFS results (was More benchmarking stuff...)
At 11:56 AM -0700 1999/9/17, Matthew Dillon wrote: In real-life... for example, with a mail or web server, the namecache tends to be somewhat more effective then 50%. The web servers at BEST generally had a 95%+ name cache hit rate. The name cache misses are what are causing the lion's share of the directory inefficiencies. Note that with a mail server, this is precisely the sort of thing that happens with /var/spool/mqueue. In particular, with sendmail, a qf/df pair of files get created, the message is received, the sender is told "250 Ok", then sendmail goes to deliver the message in the background, which 95-99% of the time happens on the first attempt, and then the qf/df pair of files get deleted. So, again, we see that they've actually done a decent first-pass attempt at simulating the load a mail server would place on the filesystem. All that we need to add now are a few more features. ;-) With a news server using traditional spool, the file would tend to get created, live for a relatively significant period of time (days or even weeks before it gets expired), and only then would it get removed. An absolutely full newsfeed these days is running somewhere around 1.1 million files comprising some 55GB of data (see http://transit.us-va.remarq.com/feed-size/), or an average of 52,608.71 bytes per article. A very busy mail server might do a million messages per day (or more), but the average message size would be much closer to 2-5KB. The primary difference between mail and news is that news articles tend to live a lot longer (mail messages might live for months or years in a users mailbox, but that's not /var/spool/mqueue, and has a different pattern of access), and they tend to be a lot larger. However, there are still on the same order of number of articles/messages input per day versus deleted per day (assuming you've got a handle on your spool and it's not growing out of control on you), it just typically takes news servers a few days to delete something once it comes in. Thus, the name cache misses might tend to be lower on news servers, but I wouldn't be too willing to bet on it -- an article that got created seven days ago and not touched since probably won't be in the name cache any more than a file that is just now being created. Of course, once you get into CNFS or timehash sorts of news spool storage mechanisms, you've traded the name cache problem and directory update problems in for an entirely different set of problems, and the filesystem may or may not be particularly good at optimizing them, as softupdates is with lots more smaller individual files. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Panic (From -chat's Re: Real Audio program that discusses FreeBSD, solaris, and Linux)
http://www.thesync.com/etc/archives.html
When I tried to view the program linked here, my -CURRENT system went
kablouie.
FreeBSD mortis.futuresouth.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue
Sep 14 16:48:29 CDT 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/MORTIS i386
I have a coredump. Panic message is:
(Yes, I have mastered the skill of dropping to DDB and panicing while in
X ;)
Fatal trap 12: page fault while in kernel mode
mp_lock = 0102; cpuid = 1; lapic.id = 0c00
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0162490
stack pointer = 0x10:0xcb1c9d4c
frame pointer = 0x10:0xcb1c9d60
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 372 (screen-3.7.6)
interrupt mask = tty - SMP: XXX
panic: from debugger
mp_lock = 0103; cpuid = 1; lapic.id = 0c00
boot() called on cpu#1
Ideas?
Backtrace looks like:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
#1 0xc0157319 in panic (fmt=0xc0282090 "feed_root: count == 0")
at ../../kern/kern_shutdown.c:531
#2 0xc0215685 in feed_root (feeder=0xc02aa460,
buffer=0xcbfcbefe Address 0xcbfcbefe out of bounds, count=0,
stream=0xce35aefc)
at ../../dev/pcm/feeder.c:112
#3 0xc0214c80 in chn_write (c=0xc10d4000, buf=0xce35aefc) at
../../dev/pcm/channel.c:286
#4 0xc0213d70 in dsp_write (d=0xc10d3400, chan=0, buf=0xce35aefc,
flag=21)
at ../../dev/pcm/dsp.c:187
#5 0xc021321d in sndwrite (i_dev=0xc11e3f00, buf=0xce35aefc, flag=21)
at ../../dev/pcm/sound.c:310
#6 0xc018bcc4 in spec_write (ap=0xce35aeb4) at
../../miscfs/specfs/spec_vnops.c:369
#7 0xc0201cb0 in ufsspec_write (ap=0xce35aeb4) at
../../ufs/ufs/ufs_vnops.c:1858
#8 0xc0202251 in ufs_vnoperatespec (ap=0xce35aeb4) at
../../ufs/ufs/ufs_vnops.c:2313
#9 0xc0186032 in vn_write (fp=0xc15d4dc0, uio=0xce35aefc,
cred=0xc12e0f00, flags=0)
at vnode_if.h:331
#10 0xc0163fc8 in dofilewrite (p=0xce2c8340, fp=0xc15d4dc0, fd=13,
buf=0x81cfc88,
nbyte=1066, offset=-1, flags=0) at ../../kern/sys_generic.c:363
#11 0xc0163ed7 in write (p=0xce2c8340, uap=0xce35af80) at
../../kern/sys_generic.c:298
#12 0xc0241d76 in syscall (frame={tf_fs = -1078001617, tf_es = 47, tf_ds
= -1078001617,
tf_edi = 135924656, tf_esi = -1077948116, tf_ebp = -1077948220,
tf_isp = -835342380,
tf_ebx = 13, tf_edx = 1066, tf_ecx = 136117384, tf_eax = 4,
tf_trapno = 12,
tf_err = 2, tf_eip = 405666084, tf_cs = 31, tf_eflags = 582, tf_esp
= -1077948224,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#13 0xc022f171 in Xint0x80_syscall ()
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
FutureSouth Communications |ISPHelp ISP Consulting
"The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic (From -chat's Re: Real Audio program that discusses FreeBSD, solaris, and Linux)
hi-
This looks awfully familiar to what rvplayer does to me on
my -current box. Of course, no one has responded at all ot
anything that I sent out...
What kind of soundcard do you have? Mine is Crystal CS4236B
shipped with my box (a Digital 5510)...
I tried sending an email to cameron grant ([EMAIL PROTECTED]), but I
have heard nothing.
S
On 1999 Sep 17, Matthew D. Fuller (aka [EMAIL PROTECTED]) wrote:
When I tried to view the program linked here, my -CURRENT system went
kablouie.
FreeBSD mortis.futuresouth.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Tue
Sep 14 16:48:29 CDT 1999
[EMAIL PROTECTED]:/usr/src/sys/compile/MORTIS i386
I have a coredump. Panic message is:
(Yes, I have mastered the skill of dropping to DDB and panicing while in
X ;)
Ideas?
Backtrace looks like:
#0 boot (howto=256) at ../../kern/kern_shutdown.c:281
#1 0xc0157319 in panic (fmt=0xc0282090 "feed_root: count == 0")
at ../../kern/kern_shutdown.c:531
#2 0xc0215685 in feed_root (feeder=0xc02aa460,
buffer=0xcbfcbefe Address 0xcbfcbefe out of bounds, count=0,
stream=0xce35aefc)
at ../../dev/pcm/feeder.c:112
#3 0xc0214c80 in chn_write (c=0xc10d4000, buf=0xce35aefc) at
../../dev/pcm/channel.c:286
#4 0xc0213d70 in dsp_write (d=0xc10d3400, chan=0, buf=0xce35aefc,
flag=21)
at ../../dev/pcm/dsp.c:187
#5 0xc021321d in sndwrite (i_dev=0xc11e3f00, buf=0xce35aefc, flag=21)
at ../../dev/pcm/sound.c:310
#6 0xc018bcc4 in spec_write (ap=0xce35aeb4) at
../../miscfs/specfs/spec_vnops.c:369
#7 0xc0201cb0 in ufsspec_write (ap=0xce35aeb4) at
../../ufs/ufs/ufs_vnops.c:1858
#8 0xc0202251 in ufs_vnoperatespec (ap=0xce35aeb4) at
../../ufs/ufs/ufs_vnops.c:2313
#9 0xc0186032 in vn_write (fp=0xc15d4dc0, uio=0xce35aefc,
cred=0xc12e0f00, flags=0)
at vnode_if.h:331
#10 0xc0163fc8 in dofilewrite (p=0xce2c8340, fp=0xc15d4dc0, fd=13,
buf=0x81cfc88,
nbyte=1066, offset=-1, flags=0) at ../../kern/sys_generic.c:363
#11 0xc0163ed7 in write (p=0xce2c8340, uap=0xce35af80) at
../../kern/sys_generic.c:298
#12 0xc0241d76 in syscall (frame={tf_fs = -1078001617, tf_es = 47, tf_ds
= -1078001617,
tf_edi = 135924656, tf_esi = -1077948116, tf_ebp = -1077948220,
tf_isp = -835342380,
tf_ebx = 13, tf_edx = 1066, tf_ecx = 136117384, tf_eax = 4,
tf_trapno = 12,
tf_err = 2, tf_eip = 405666084, tf_cs = 31, tf_eflags = 582, tf_esp
= -1077948224,
tf_ss = 47}) at ../../i386/i386/trap.c:1056
#13 0xc022f171 in Xint0x80_syscall ()
--
---
Sean O'ConnellEmail: [EMAIL PROTECTED]
Institute of Statistics and Decision Sciences Phone: (919) 684-5419
Duke University Fax: (919) 684-8594
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 2xPIIIx450 results NFS results (was More benchmarking stuff...)
At 1:02 PM -0700 1999/9/17, Matthew Dillon wrote: Sendmail does not get into trouble with queue files it is able to retire quickly. Where sendmail gets into trouble is with queue files it ISN'T able to retire quickly. This is why you *see* 10,000+ files in mqueue at times. These files build up because a small percentage of mail destinations cannot be delivered to immediately. In my experience, sendmail almost always accepts messages a lot faster than it can process them, regardless of the mode in which sendmail is running. Foreground, queue-only, background, in my experience it doesn't make a whole lot of difference. So the input number of files can grow very quickly, with deliveries (and mqueue file removals) suffering. The reason sendmail tends to break down with large queue directories has little to do with directory overhead and a lot to do with sendmail's own algorithms. If you have 50 sendmails running a 10,000 file queue, each of those sendmail processes is essentially scanning the entire queue. Yup, that's another very real problem with sendmail, and another reason why I really like postfix. If not controlled, this eventually leads to a cascade failure. The potential for a cascade failure is, in fact, the number one reason for *NOT* running sendmail with background queueing mode turned on. The best way to avoid a cascade failure is to run the sendmail daemon in queue-only mode with a set fork limit: sendmail -bd -OMaxDaemonChildren=X -ODeliveryMode=q And run the sendmail queue runner separately: sendmail -q1m -OMaxDaemonChildren=Y -OMinQueueAge=1h In my experience, you still get messages being accepted a lot faster than they're being pushed out. This is usually made even worse when you're delivering to mbox-style mailboxes, where a single large message may come in addressed to dozens of recipients, and now you might have megabytes of data being read but gigabytes of data being written. This is another of my pet peeves, where I believe that a database-oriented solution that writes just one copy of the message and then gives all recipients pointers to it, would help a great deal. Of course, there's not anyone like Eric or Wietse to pick on when it comes to writing database-oriented local delivery agents. The key issue with any mail server is that bandwidth and transaction useage tends to be low relatively speaking. A USENET news system almost always has much higher transactional overhead, especially if it is taking several feeds. A million news messages a day translates to around 10 million protocol transactions for a news box taking 4 feeds. However, most of those transactions should be looking up message-ids in history or precommit cache databases and then refusing the article without it actually being transmitted. High transactional rates, yes. But the actual number of articles being received would be on par with a very busy mail server. If you've got a lot of outbound feeds, of course the outbound data rate could be a very real problem, but that's a separate issue. What you cannot afford to spend time doing in a mail server is scanning the same queue file over and over again, so what you want to optimize for are the 5% of email messages that wind up stuck in the queue for more then a few minutes but usually less then an hour, and then make sure the 1% that stick around past that do not interfere with the processing of those that stick around less. You can't really fix sendmail in this regard, although you could replace it with a different MTA. I guess you could change the implementation methods of the underlying filesystem so as to speed up those constant linear sweeps of the entire mqueue directory by the queue runners (and by every sendmail process that goes to create a file in the mqueue, since they have to guarantee that the filename they're creating is unique). How you would actually do this is totally beyond me, however. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, [EMAIL PROTECTED]Belgacom Skynet NV/SA |o| |o| Systems Architect, News FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the
Re: Panic (From -chat's Re: Real Audio program that discusses FreeBSD, solaris, and Linux)
On Fri, Sep 17, 1999 at 04:02:37PM -0400, a little birdie told me that Sean O'Connell remarked hi- This looks awfully familiar to what rvplayer does to me on my -current box. Of course, no one has responded at all ot anything that I sent out... I've never had any troubles out of it before. This is the first time I've had any problems out of it. It didn't have any problems playing mp3's, or audio off .avi clips. What kind of soundcard do you have? Mine is Crystal CS4236B shipped with my box (a Digital 5510)... This is the builtin on an Intel Providence motherboard: pcm1: CS4236B at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 -- Matthew Fuller (MF4839) |[EMAIL PROTECTED] Unix Systems Administrator |[EMAIL PROTECTED] Specializing in FreeBSD |http://www.over-yonder.net/ FutureSouth Communications |ISPHelp ISP Consulting "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird syscons keyboard behaviour
In message [EMAIL PROTECTED] Mike Pritchard writes: : I've noticed some odd syscons keyboard behaviour over the past : month or so. Sometimes I get a vty that outputs PC graphics characters : for all of my input. This is always at a "login:" prompt. I think : I can duplicate this by typing a bunch of garbage at a login prompt, : but I don't feel like trying to test it right now and have to : reboot my main machine. syscons can get confused about the state of the CTRL key. I see exactly this if i hit ^C to sendmail just before the keymap changes since the key up event is after the keymap change and that key is no longer ctrl. However, hitting the control key several times seems to fix this. Next time you see the problem, you might want to try this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
In message [EMAIL PROTECTED] John Polstra writes: : There are now 63000 files and directories in the repository. : That's 2**3 * 3**2 * 5**3 * 7. If we concatenate the exponents, : we get 3231, which is 3**2 * 359. Repeating, we get 21, which : is 3 * 7. One more repetition and we get 11, which is itself a : prime, as is 37. Isn't that amazing? : : ;-) Stop. The Illuminati "Law of 5's" is spreading. After all we have 2**3 (2+3 is 5), 3**2 (ditto) and 5**3 (three of the sacred 5's). The 7 is put in to confuse The Man[tm], but true afficionados know about the deception and how to deal with that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more
:On Sun, 12 Sep 1999, Chris Costello wrote: : : On Sun, Sep 12, 1999, Rodney W. Grimes wrote: : Not with me, and I am sure Warner and a few other die hard ``more'' users : are going to be chimming in here as soon as they get to this... : :Down with "n"! Up with "/"! : :No, up with '?'. : :-- : Ben Rosengart Up with '?' followed by 'n'! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
: files sitting in unflushed disk caches and you reboot, those files are : lost. Softupdated just guarantees that the disk will be in a stable : state after a crash, not that all data written before the crash will be : available. : : :Soft updates guarantees that when an fsync() is done, it's on disk... Actually it doesn't. I wish it did. All softupdates does is guarentee that the on-disk image is stable, it doesn't guarentee that the on-disk image has been synchronized to what the program thinks it has written to the file. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make world speed-up patch (was Re: optional 'make release' speed-uppatch)
:The snippet from /usr/src/Makefile.inc1 that I'm talking about (in my
:own little world) was this:
:
:.if !defined(NOCLEAN)
:@echo
:@echo "--"
:@echo " Cleaning up the temporary ${OBJFORMAT} build tree"
:@echo "--"
:mkdir -p ${WORLDTMP}
:-chflags -R noschg ${WORLDTMP}/
:rm -rf ${WORLDTMP}
:.endif
:
:
:Can we please have this optimised ?
I think that the rm -rf can safely be placed before before AND after
the chflags, which will optimize the chflags considerably. This combined
with using softupdates for your /usr/obj partition will result in
a very quick cleanup time.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
:Also FreeBSD only caches a limited number of directory blocks. This :was discussed on -hackers in April. Search for the subject "Directories :not VMIO cached at all!". Matt Dillon posted a patch to to better :cache directories (at the possible expense of wasted RAM and which breaks :NFS) in Message-ID [EMAIL PROTECTED]. That's been committed, but you have to turn it on with a sysctl because softupdates occassionally barfs with it on. It seems unlikely to me that it will effect the benchmark unless the benchmark creates a whole lot of directories. sysctl -w vfs.vmiodirenable=1 The NFSv3 performance elements have also been committed. I'm going to try running this benchmark thingy on my test boxes as soon as I can get my cvs tree updated. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADs UP - VM, VN, SWAP, NFS commits made
A large number of commits have been made relating to the following: VM a number of minor swap related bugs have been fixed madvise() enhancements prepatory 'lastr' field added to vm_map_entry VN swap-backed VN now works again major enhancements made to VN device, see new vnconfig man page NFS client-side nfs commit rpc now asynchronized (when you are running nfsiod's), wasn't before. major performance improvement in server-side nfs commit rpc - full file fsync replaced with ranged block sync. SPECFS A bug related to mmap()ing files backed by disks with sector sizes larger then 512 bytes fixed. sysctl vfs.enable_userblk_io added, defaults to 1. Setting to 0 disables buffered block device access from usermode, allowing testing to determine what roadblocks, if any, remain in regards to the removal of user access to buffered block devices. Fixes for BOOTP are slated to go in tomorrow. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More benchmarking stuff...
:According to kirk FSYNC() does the right thing and 'sync()' doesn't. : Lets see... well, it will sync the file state, but it will not necessarily sync the related directory entry (as far as I can tell). So if you take a case such as sendmail creating a queue file, fsync will succeed and the file itself will be consistent, but the directory entry for the file may not yet have been created and synced. A crash at that point would result in a missing file. Kirk would know for sure. - At some point we need to extend the kernel VOP_FSYNC API to include a file offset/range so NFS can conditionally fsync part of a file and know for sure that it's data and metadata have gone to the platter. And its directory entry as well in the case of a newly created file. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
2xPIIIx450 results NFS results (was More benchmarking stuff...)
Ok, these are on duel P3 450 boxes running -CURRENT, with the NFS performance enhancements. Local disk is an 18G seacrate on an LVD/W scsi bus. UFS tests: on 1G duel P3-450 machine, 1x18G seagate SCSI-LW bus NFS tests: 1G duel P3-450 client, 512M duel P3-450 server, 100BaseTX, nfsd -n 4, nfsiod -n 4. Heh heh I accidently left my UFS/NFS-client box configured for 32M of memory and had gotten through the 1000/5 tests before I realized it! So I might as well give you the results: 1000/5 trans readwrite (client with 32M of ram) UFS+SOFT264/s 841K/s 860K/s NFS 84/s 270K/s 276K/s 1000/5 trans readwrite (client with 1G of ram) UFS+SOFT1515/s 4.7M/s 4.8M/s NFS 107/s 344K/s 352K/s 2/5 trans readwrite (client with 1G of ram) UFS+SOFT162/s 366K/s 663K/s NFS 50/s 125K/s 226K/s Both the client and server systems were 90%+ *IDLE* during all tests. The network was operating at 1-2 MBytes/sec through the 1000/5 tests and from 0.6MB to 1.2MB/sec through the 2/5 test. This isn't surprising since the test is performing essentially random seek I/O's from a single process. The benchmark has a number of problems. The 'postmark' program isn't forking at all, so there is a serious bottleneck in the process itself, especially whenever a read is issued. It doesn't really give us an accurate representation of a multi-tasking load. Most NFS servers have a multitasking load so it isn't really a fair test. The benchmark shows pretty clearly the inefficiency of large UFS directories. Putting 2 files in a single directory is not fun, and it seriously skews the test results considering what the benchmark is supposed to be testing. It seems pretty clear to me that this benchmark has been designed to show-off the netapp in the best possible light and its competitors in the worst possible light. Well, ok, that may be an overly-harsh assessment, but it is still true to some degree. The benchmark is seriously flawed. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2xPIIIx450 results NFS results
Matthew Dillon wrote: [..] One thing of interest to note, especially as it relates to the performance degredation with a larger number of files, is that 'systat -vm 1' reports an approximately 50% name-cache hit no matter what postmark is doing. In otherwords, postmark is creating a new file (namecache miss), opening it (namecache hit), doing some I/O, and then closing it. 4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision 1008.A, running `systat -vm 1' gives the normal display but without any numbers filled in, then switches over to an empty screen that says: The alternate system clock has died! Reverting to ``pigs'' display. Which also doesn't work (I'm sure innd would be considered a CPU and memory hog but nothing is displayed). top is also broken (0% everywhere). Apparently this can be fixed by adding `device apm0 at nexus? flags 0x0020' to the kernel config file, but the last time I tried that the machine would panic while booting. Has this been fixed since? In real-life... for example, with a mail or web server, the namecache tends to be somewhat more effective then 50%. The web servers at BEST generally had a 95%+ name cache hit rate. The name cache misses are what are causing the lion's share of the directory inefficiencies. 100% on another news server (3.2-STABLE, INN 2.2 with CNFS) :-) (only watched it for a few moments though, lowest was 97.) Thanks, -- Niels. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2xPIIIx450 results NFS results
: I/O, and then closing it. : :4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision :1008.A, running `systat -vm 1' gives the normal display but without any :numbers filled in, then switches over to an empty screen that says: :... Whenever systat or top do weird things it probably means you need to recompile libkvm. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: An FS question perhaps... non blocking I/O.
In message [EMAIL PROTECTED], John Polstra writes: ugh, why aren't you extending poll to work on files and directories to get this info?? it would make MUCH more sense to extend poll to do this.. any specific reason why it wasn't done this way? Yes. Last time I checked, our CVS repository contained 50,000 files in 13,000 directories. Somehow the thought of a 63,000-element pollfd array leaves me cold. Sounds like something Bruce would do :-) He can try it on the repository here: $ find . -type d | wc -l 8764 $ find . -type f | wc -l 586382 $ It would be one expensive call with that many elements to scan... - -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: more
On 12-Sep-99 Matthew Dillon wrote: :On Sun, 12 Sep 1999, Chris Costello wrote: : : On Sun, Sep 12, 1999, Rodney W. Grimes wrote: : Not with me, and I am sure Warner and a few other die hard ``more'' : users : are going to be chimming in here as soon as they get to this... : :Down with "n"! Up with "/"! : :No, up with '?'. : :-- : Ben Rosengart Up with '?' followed by 'n'! that bold Search: scared me earlier. It seems to friendly! Luke To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 2xPIIIx450 results NFS results
I've been getting this too on 4.0-C, just rebuild last night, still there. top displays: CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle AND loads 2 make the machine very unresponsive, its like SMP was before that pci_support.c patch a month or two ago. - ( Adam Strohl ) - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.netxxx.xxx. x - - ( DigitalSpark.NET )--- - On Fri, 17 Sep 1999, Rodney W. Grimes wrote: : I/O, and then closing it. : :4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision :1008.A, running `systat -vm 1' gives the normal display but without any :numbers filled in, then switches over to an empty screen that says: :... Whenever systat or top do weird things it probably means you need to recompile libkvm. This is not a libkvm problem on my box, these are fresh make worlds on 3.3-RC as of 2 days ago. It only appears to occur when running SMP, and has been a problem in the past if you look at the cvs log for systat/vmstat.c. Search for the specific message given by this user in the log, you'll see it has come and gone at least once. I already sent one message out about this, in response to Jordans ``release tag going down''. -- Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
