> > > I like Intel as much as I like AMD > > > > That is your right. Inthell has a long history of buggy products, > > attempting to hide/ignore bugs, poor customer support, outright > > theft, etc. AMD isn't perfect, but the list of bad things is far > > far shorter. And there are other companies to consider besides > > just inthell and AMD. > > I'd rather not debate this, as it's off-topic. We can take it up > privately if you desire, but keep in mind that my ideal system would be > an AMD processor on an Intel chipset board -- but I'll probably be dead > by the time that ever happens. Both companies could have much to learn > from one another.
Inthell apparently has some good fab people. If they were a designless fab house they might not be on my black list. > No administrator in their > right mind is going to disable WC unless the disks are behind some form > of controller that does caching. (For NCQ stuff, see below.) The only setup I have found that doesn't lose data is FFS+softdep+WC off. So you think I am insane for wanting to not lose data? > > > NCQ will not necessarily improve write performance. > > > > I doubt it will help if you have the disk's write cache turned on. > > I'm pretty sure it will help with write cache turned off. > > One thing I haven't tested or experimented with is disabling write > caching on a drive that has NCQ. Since FreeBSD lacks NCQ right now, we > could test this on Linux to see what the I/O difference is (I'm talking > purely from a dd or bonnie++ perspective). The filesystem may be significant, and last time I looked, linux didn't support FFS r/w. I read something indicating that recent disks do NCQ much better than earlier ones, so "NCQ support" isn't binary. This, and people testing NCQ with the write cache on, could explain the results where NCQ doesn't help. _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"