Using any network interface whatsoever
From mailing list archives: I wrote some add-on bits for /etc/rc.network in 4.x that compares the link addresses of attached network interfaces to a list of link addresses, then sets ifconfig_ifN* variables accordingly before rc.network does anything. It provides a means of wiring IP addresses to physical ports in a way that gets around the problem of probe order. If there's interest, I'll get to work on an rcNG version. I would be interested in seeing this. I build custom machines for a company I work for, and one of our requirements is the ability to number the network ports. End users configure our software based on which port they use, so we need steady numbering of the ports, even when one customer machine might have different cards and number of cards. We basically want the order to be: 0-N motherboard ports N+1 - M card ports It sounds like your script might work, given the apparent absence of geographic mapping in most current systems. Thanks for any help. -- Where some they sell their dreams for small desires. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Athlon Processors
On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: Well, since it didn't, I might as well explain the problem here too. There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I've pushed systems like that _very_ hard and not seen any problems, with Linux, NetBSD, or FreeBSD. The only trouble I have is IDE bus resets with CD-ROM drives, especially in FreeBSD. Since the same thing happens with a lot of IDE systems, I generally blame IDE; it's a broken-by-design interface in the first place. If this is really true, I would think it should be fairly easy to prove it. Now, go back in time about 2 years, and I wouldn't doubt it, because there were problems with the first VIA KT chipsets, and even the AMD architecture in general. Everything I've read suggests those problems have been fixed. If not, then it should be fairly easy to demonstrate this. I'm willing to donate time and a system to this since I'd really like to know. In fact, if this _really is_ true, then it would be a good idea for a substantial number of people to try and verify it: the VIA based motherboards for AMD are some of the best out there, as PC motherboards go anyway. -- Star Wars Moral Number 17: Teddy bears are dangerous in herds. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Whitespace at end of line
On Mon, Jul 16, 2001 at 12:31:02PM -0700, David O'Brien wrote: On Mon, Jul 16, 2001 at 09:42:22AM -0700, Terry Lambert wrote: Wilko Bulte wrote: Maybe I'm just plain dim today (I will add a beer to rectify this situation at first convenience..) but what is so bad about some trailing whitespace that a massive commit-a-thlon is called for? just wondering, Wilko You use emacs, don't you? What does vi vs. emacs have to do with it? The beer. -- Castles are sacked in war, Chieftains are scattered far, Truth is a fixed star, Eileen aroon! -- Gerald Griffin __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Mall now BSDCentral
On Fri, Jul 06, 2001 at 07:59:12PM -0400, Sergey Babkin wrote: If the FreeBSD Foundation is an existing entity now, maybe we can just change the license for the CD images to not for resale unless the distributor signs an agreement with the Foundation ? I don't think this is a good idea. The foundation can give a certain CD vendor official status without limiting the rest. This is how things were in the past, and it seemed OK to me. For example, I occasionally bought the offical CD set from whoever was selling it. I could get it much cheaper elsewhere, but wanted to contribute money from time to time to help the project and the vendors who supported it. However, I didn't want to pay that much for CDs of the minor updates, so I usually got those from Cheap Bytes, or got a friend with fast network access to get it for me. As a FreeBSD user, I found this a useful way of doing business. Will a company like Cheap Bytes really do that much damage to the official vendor? The only thing I'm concerned with _as_a_user_, is that anyone who distributes CDs uses what the core team supports as being FreeBSD. I'd hate to see someone roll their own and call it FreeBSD. -- The determined programmer can write a FORTRAN program in any language. __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DVD IOCTLs on IDE?
On Sun, Jun 24, 2001 at 08:12:28PM -0400, David Gilbert wrote: ... and can successfully mount a DVD-ROM... they just don't play with any of the software I've been able to find. Most recently, I downloaded a copy of another package mentioned on /., but it dies looking for libdl.so ... which I assume is a stupid linux dependancy, so I havn't been chasing it. It's a dynamic load library, originally from Solaris. It's included in all dynamically linked NetBSD programs, exists as a library in Linux. Run man dlopen and see if the man page says at the top if it's a library or is included in all dynamically linked programs. I cannot get to my FreeBSD box to check right now. -- Secrecy is the beginning of tyranny. -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: import NetBSD rc system
On Thu, Jun 14, 2001 at 09:57:17AM -0400, Robert Withrow wrote: [EMAIL PROTECTED] said: :- oops, rc2 isn't started. too bad. I think that is exactly the desired design. The RC *system* starts things correctly, but the manager, *bypassing* the RC *system* can start and stop things exactly as he wished. For debugging or whatever. I'd argue that if you want to start/stop a *subtree*, you should ask the RC *system* to do that somehow. I think also, that you want to be careful about forcing dependencies. There are times when I start one service even though it has a dependency. It might be the prerequisite is only needed for a certain function you can do without. I'm sure you can think of other examples. So, how about an option to the rc.d scripts to ignore the dependencies for those times when you don't want them? Also, NetBSD doesn't seem to formalize chaining to /usr/pkg/etc/rc.d or /usr/local/etc/rc.d, unless I missed that. -- We have nothing to prove -- Alan Dawkins __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
On Thu, May 24, 2001 at 11:19:44PM -0700, Doug Barton wrote: The current mood (which I agree with) is to make softupdates the default after installation. The problem with the combo of write caching and softupdates is that if the power actually goes off the meta-data writes that softupdates postpones and are further postponed by the write cache will never happen, therefore leaving the file system in a potentially unrecoverable state. If drives could be counted on to have a synchronous write command, and the driver interface let you send a flag (cache/no-cache) with each write, would that be acceptable? In the XFS miling list at SGI, some were saying that that is what they wanted for metadata and log writes. -- Whatever... -- Kenny Gatdula To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Thu, May 24, 2001 at 12:25:59PM -0300, Rik van Riel wrote: On Wed, 23 May 2001, Shannon wrote: On Wed, May 23, 2001 at 10:54:40PM -0300, Rik van Riel wrote: 1. I don't think I've ever seen a Linux distro which has write caching enabled by default. Hell, DMA33 isn't even enabled by default ;) You are talking about controlling the IDE drive cache. The issue here is write cache in the filesystem code. 1) IIRC they were talking about hw.ata.wc In a subthread, yeah. I think though, the overall issue is the caching ext2 does that ufs does not. I'm not even sure that soft updates is quite the same thing. I think the soft-updates paper mentions that it shouldn't increase risk, while a lot of people feel like ext2 is very risky. I never really notice a big difference when I turn on write caching with my system (on the hard drive). It's been awhile since I did any benchmarks though, since I no longer run IDE drives on most systems. You can control the cache on them too with the right scsi tools, but I've not really messed with it. -- There is no such thing as security. Life is either bold | | | adventure, or it is nothing -- Helen Keller| | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Thu, May 24, 2001 at 05:00:44PM -0400, [EMAIL PROTECTED] wrote: Linux has lots of little kludges to make it appear faster on some benchmarks, but from a networking standpoint it cant handle significant network loads. Are you sure this is still true? The 2.4.x series kernel was supposed to have significant networking improvements over the previous kernels. I dont know, but I doubt it. There were significant network and memory improvements in the 2.4 release. There were also some improvements that will have to wait for the next release, but overall it is much improved. FreeBSD 4.3 is much improved over 2.x and 3.x, so I'm not sure why that would be considered unusual or surprising. The memory system in Linux is still set up by default to give more speed at the expense of smooth load handling. It seems better, but you have to go into /proc and tune things to get better load handling. the problem isnt the networking preformance, its the inability of the memory system and the ethernet drivers to handle overloads properly. They are modeled in a way that fails in practice. The way I understood it was certain drivers were more affected by this than others. Some were just fine, and handled very high loads. Another problem was multiple ethernet cards, but I forgot what caused that. A lot of that was addressed in the 2.4 release, and it seems to have made a lot of people happier. I can't test the difference because I have nothing but 10mbit ethernet. However, the 2.4 kernel is definitely faster in my day-to-day work, and has allowed me to delay a complete move to FreeBSD 4.x on my workstation. It was that much of a step forward. Now I can wait until I get proper 3D support for my nVidia graphics card. -- We have nothing to prove -- Alan Dawkins To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Thu, May 24, 2001 at 10:34:26PM +, Terry Lambert wrote: ] 1. I don't think I've ever seen a Linux distro which has write ] caching enabled by default. Hell, DMA33 isn't even enabled ] by default ;) ] ] You are talking about controlling the IDE drive cache. ] ] The issue here is write cache in the filesystem code. No. The issue here is the write cache on the drive. FreeBSD with soft updates will operate within 4% of the top memory bandwidth; see the Ganger/Patt paper on the technology. I have a file, CSE-TR-254-95.ps, that I think is probably the paper you are talking about. The title is Soft Updates: A Solution to the Metadata Update Problem in File Systems. The link on Ganger's page was dead, but I'm sure this is the one you mean. Nowhere do they support the idea that soft udpates can approach a system's memory bandwidth. What they did say was that in _one_ case, creating and then immediately deleting a directory entry, you are operating at processor/memory speeds. They said soft updates in that case were 6 times faster than the conventional system. That's not even close to the memory bandwidth of the 486 system they were using, so they had to mean the filesystem code in that test was able to run without waiting on I/O. In the more general cases, their findings were more than a factor of two compared to synchronous write ufs. I _wish_ my workstation was able to write metadata at nearly 1GB/s all the time... :) -- Star Wars Moral Number 17: Teddy bears are dangerous in herds. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Wed, May 23, 2001 at 06:53:37AM -0300, Daniel C. Sobral wrote: I cannot verify that with my drive, but my largest is 18GB so maybe the difference is not as pronounced as on some newer drives like those (currently) monster 70GB drives. It should be measurable. Actually, I edited too much. I have seen a difference, but it was too small to care abot on my system. These are 7200rpm 18GB drives too. The other variances in filesystem performance seem to overshadow the difference. The only thing I ever did to pick up some speed was to move some data on a raw device to the faster tracks. I was streaming it in so the speedup was good. I also picked up some performance on one Linux system by putting swap in the faster tracks. But for the most part, I've never been able to tell. I have read that on the 40-80GB drives, it's very noticeable. In fact, the IBM Ultrastars are supposed to be faster than their electronics can handle on the very outer tracks. -- Secrecy is the beginning of tyranny. -- Unknown | | | | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Wed, May 23, 2001 at 09:03:37AM -0400, Andresen,Jason R. wrote: The scary thing is that it was the attached harddrive that lost all of the files. The situitation is this: [snip] Sorry to hear that, but like I said, it isn't typical. ext2 in it's early days, an ext before that were really bad. But I have few problems with it these days. I've lost more ufs filesystems than I have ext2, but I don't assume my results are typical: I know ufs is better. However, ext2's problems are grossly exaggerated. It's entirely possible that there is something I could have done to prevent fsck from clearing out the filesystem, but it certainly isn't obvious from the manual, and I've never seen a FreeBSD system do that. Nothing much you can do unless you happen to know ext2 inside and out, and fix it manually. It's not normal for ext2 to die like that, and be unable to recover. Over the years I have had more bizarre, inexplicable OS problems on Intel PCs than any other. Also, for anybody who says the pull the power test isn't realistic, I can assure you that power failures DO happen (probably less in your area than My point was that yanking power only tests one aspect of the filesystem. Chosing one based on passing or not passing that test isn't a good idea. mine (I hope!)) and not planning for them only brings disaster later when you have a room with 1000 servers lose power. Well, a UPS system is as important in any system you care about as the computers and operating systems. If you run 1000 servers and they can lose power, you're on borrowed time anyway. Where I live, the power gets worse every year. I lost quite a few ext filesystems, but only a couple of ufs and ext2 filesystems. Then I bought a 1920VA UPS and it's no longer an issue. I just found it easier to not lose power than to worry about which filesystem recovers from it better. -- There are nowadays professors of philosophy, but not philosophers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 02:49:21PM -0400, Jason Andresen wrote: 6 files took ~15 minutes to create as is. I'm going to have to wait until tonight to run larger sets. 2.2.16 is what we have here. I'm still waiting to see how much faster ReiserFS is. I'm willing to overnight your test if you want. Do you have it packaged up to send? It would be interesting just to get numbers from a Linux system with a modern kernel. 2.4.1 gave me enough of a speed boost to put off another FreeBSD install until I fix some problems there. I cannot test FreeBSD with SCSI right now so my system will be an inequal set of results. I would offer to test NetBSD as well, but I suppose no one would be interested in that. -- [EMAIL PROTECTED] _ __/ armchairrocketscientistgraffitiexistentialist There is no such thing as security. Life is either bold adventure, or it is nothing -- Helen Keller To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 09:31:34AM -0400, Jason Andresen wrote: Er, I don't think ReiserFS is in the Linux kernel yet, although it is the default filesystem on some distros apparently. ReiserFS, on my system anyway, started just losing files. I'd log in and would notice some mp3 files or source code was just gone. No heavy load, and no crashes. Nope, not for me. I think they'll get it in time if the basic design isn't flawed, but things like an fs just take a lot of time to debug and come to trust. There are already some very good journaling systems, and it would seem better to get them ported, and leave things like ReiserFS a research project until it proves itself. That said, it would be hard to be much worse than Ext2fs with write cacheing enabled (default!) in the event of power failure. Point taken, but the yank power, see who survives test is illogical and dangerous thinking. Besides, my drives have megabytes of write-cache that I cannot disable. Most are large enough to cause problems for most any fs if they crash at just the right moment. From what I have read, a lot of drives really ignore commands to turn it off or do synchronous writes. Both ext2 and ufs both handle my chores with little or no trouble. On some systems, I've actually preferred ufs to the journaled file systems. We only have three Linux boxes here (and one is a PC104 with a flash disk) and already I've had to reinstall the entire OS once when we had a power glitch. ext2fsck managed to destroy about 1/3 of the files on the system, in a pretty much random manner (the lib and etc were hit hard). This is not typical. Also, I have heard the same thing from other people about flash disks. fs crash, fsck, and a mess afterwards. It would be nice if you could use ufs and see if the same problem exists. -- There's music along the river For Love wanders there, Pale | | | flowers on his mantle, Dark leaves on his hair. -- James Joyce | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 12:03:33PM -0400, Jason Andresen wrote: Here's the results I got from postmark, which seems to be the closest match to the original problem in the entire ports tree. Test setup: Two machines with the same make and model hardware, one running FreeBSD 4.0, the other running RedHat Linux 7.0. The data: Hardware: Both machines have the same hardware on paper (although it is TWO machines, YMMV). PII-300 Intel PIIX4 ATA33 controller IBM-DHEA-38451 8063MB ata0-master using UDMA33 HD Note: all variables are left at default unless mentioned. 1 transactions, 500 files. What did you set size to? How much memory on the machine? I tested on a 700MHz Athlon system with 256MB RAM, Adaptec 2940UW controller, 18GB IBM Ultrastar SCSI drive. You must have really low memory or something because I know that 1 transactions and 500 files can't be enough for anything faster than my old Sun SS5. I hit over 16MB/sec and 5000 transactions per second on my Linux machine. On the larger tests, it was disappointing. I can't test FreeBSD on SCSI right now, but my NetBSD machine (the old Sun SS5 wasn't terrible at least: Time: 220 seconds total 204 seconds of transactions (49 per second) Files: 5564 created (25 per second) Creation alone: 500 files (62 per second) Mixed with transactions: 5064 files (24 per second) 4999 read (24 per second) 4967 appended (24 per second) 5564 deleted (25 per second) Deletion alone: 628 files (78 per second) Mixed with transactions: 4936 files (24 per second) Data: 32.12 megabytes read (149.52 kilobytes per second) 35.61 megabytes written (165.73 kilobytes per second) 1 transactions, 6 files FreeBSD 4.0 with Softupdates, write cache disabled Time: 1259 seconds total 495 seconds of transactions (20 per second) I got about 60 per second right here. I was actually expecting better results from Linux and NetBSD than I got, and would expect more from FreeBSD than you got. I'm going to test FreeBSD tomorrow and Linux again with much larger numbers of files and transactions. -- Star Wars Moral Number 17: Teddy bears are dangerous in| | | herds. | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Tue, May 22, 2001 at 10:55:09PM -0300, Daniel C. Sobral wrote: And just to get things worse... :-) the test must be made on the *same* slice. If you configure two different slices, the one on the outer tracks will be faster. I cannot verify that with my drive, but my largest is 18GB so maybe the difference is not as pronounced as on some newer drives like those (currently) monster 70GB drives. A 70GB IBM Ultrastar supposedly can physically outrun the internal electronics on the faster tracks. One review I read mentioned it as a problem, though I'm not sure why. In any case, I'm not quite that picky, and I would not think that postmark would benefit as much from being on the faster tracks. It's doing a lot more complicated things than just streaming data. -- And in billows of might swell the Saxons before her,-- Unite, oh unite! Or the billows burst o'er her! -- Downfall of the Gael __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
On Mon, May 14, 2001 at 11:35:15AM -0500, Chris Dillon wrote: For the second boot I unplugged the USB hub. This time everything was fine... I'm sending this mail from the FreeBSD machine's console. Replying to my own post: The problem is the Logitech joystick, not the hub itself. Every time I boot with the joystick plugged in, FreeBSD 4.3 pukes. I was about to ask you if it wasn't one of the devices plugged into the hub and not the hub itself. Glad I read the next message. :-) A friend of mine has a Saitek joystick that when plugged into his FreeBSD 4.3 system causes the same problems. I thought it was just another mis-behaved USB device and told him to keep it unplugged. He's not likely to use it with FreeBSD anytime soon, anyway. I'm glad it's a repeatable problem. Should make it easier for the usb coders to debug. I still have not had time to generate more debugging information, but hope to get to that this week, soon. The joystick is a force-feedback model (Logi Formula Force), but is otherwise just your average every day USB joystick. IIRC, the joystick that my friend has is also force-feedback. Coincidence? I've got a force-feedback USB joypad that I can plug in and see if there are any problems. I haven't tried lately, though FreeBSD was happy with it when I tried a few months ago. I didn't have the same problem with FreeBSD 4.1, and I'm almost certain it did not occur with 4.2, but I might have had the joystick unplugged when I was using 4.2. FF devices probably report more information or do so differently than other devices. Some of them also auto-calibrate and things like that which might either slow things down or maybe they announce their presence on the bus twice or something. Did you notice, before the crash, that the kernel had some trouble querying the offending device? That happens with me, and then a little while later in the boot it crashes. -- Secrecy is the beginning of tyranny. -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
On Fri, May 11, 2001 at 07:54:26PM -0400, Shannon wrote: For the second boot I unplugged the USB hub. This time everything was fine... I'm sending this mail from the FreeBSD machine's console. Replying to my own post: The problem is the Logitech joystick, not the hub itself. Every time I boot with the joystick plugged in, FreeBSD 4.3 pukes. I've testing most other things with 4.3 on my hardware, and nothing else seems amiss. It's just like 4.2 except that no version prior to 4.3 would crash because of (or triggered by rather) a USB device. The joystick is a force-feedback model (Logi Formula Force), but is otherwise just your average every day USB joystick. -- If you tell the truth, you don't have to remember anything -- Mark Twain __ Charles Shannon Hendrix s h a n n o n @ w i d o m a k e r . c o m To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD vs. Linux
On Sun, Oct 22, 2000 at 08:38:43PM -0400, Sergey Babkin wrote: By the way, speaking of that, things in FreeBSD tend to be more synchronous with docs than in Linux. Also FreeBSD has much better backwards compatibility (though alas still not as good as commercial systems). In Linux the applications tend to break and require recompilation when the kernel is upgraded to the next second-digit version. Mostly, that is only for system utilities. Few applications care about the kernel, and I run plenty of old applications with just a compatbility library installed, just like I do on FreeBSD. I dislike the package systems like rpm and debian when they keep me from running different versions of a library unless I force it. Some dependencies just don't make any sense. The FreeBSD situation is better, but no UNIX is exactly library heaven once you get away from the basics (C, kernel, POSIX). Graphics and sound are still alphabet soup. Hopefully that will settle down in time. -- "Those who trade liberty for security will have neither -- (??)" shannon @ w i d o m a k e r . com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs. Linux
On Sat, Oct 21, 2000 at 05:31:50PM -0700, FengYue wrote: On Sat, 21 Oct 2000, Frederik Meerwaldt wrote: -Differences... FreeBSD is a real Unix, while Linux is a ..how should I Hmmm. FreeBSD is not a UNIX, rather it's a UNIX alike OS. (Which really doesn't matter IMHO) Don't forget UNIX is a trademark of Open Group. Don? :) Serously, BSD is UNIX. Wether or not TOG likes that is irrelevant. The legal distinction is not the important one. -- "The grieving lords take ship. With these our very souls pass | | | overseas." -- Exile | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SCSI tape speed
I'm interested in hearing from anyone who uses DAT drives on a DPT SCSI controller, preferrably with FreeBSD 4.1 and an Intel system. I find the speed is very slow, and I know in the past these drives were fine with FreeBSD, though I can't remember which release now. With my most recent install of FreeBSD 4.1, I am lucky to get 3MB/minute on a drive and controller combination that I know can hit 45MB/min. Right now, with NetBSD on an old Sparc 5, they still get 20MB/min or better. No errors, even large restores are perfect, but take many hours to finish. The controller I have is a DPT-2044W, and it currently has the ROM version DPT suggested for use with tape drives. The drives in question are an Archive Python 4-tape robot and a Seagate Scorpion. Both are DDS2 drives. No load on the DPT except for tapes and a CD-ROM burner. I haven't been able to find much information on this particular setup, and most tape woes seem error related, or related to another platform. -- "Those who trade liberty for security will have neither -- | | | (??)" | | | / | \ s h a n n o n @ w i d o m a k e r . c o m _/ | \_ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
