On Thu, 13 Apr 2006 15:38:44 +0100 Dieter <[EMAIL PROTECTED]> wrote: > > > > > I just got 49194139 bytes/sec reading a large file (~10GB) on FreeBSD. > > > > > Linux on the same machine could only manage 35741200 bytes/sec. > > > >=20 > > > > Which controller, kernel, and file system are you using ? > > >=20 > > > nforce4-ultra Seagate 7200rpm SATA > > > 6.0 FFS aka UFS > > > > UFS on Linux ? > > I'm pretty sure your benchmark only shows that Linux' implementation of UFS > > is weaker than FreeBSD's, which is not surprising. > > Linux: 2.6.16 and the default penguinix filesystem
I'll take a guess and say ext3. > FreeBSD read the exact same file from Linux's fs at 37194917 bytes/sec. > So FreeBSD can read files off a Linux fs faster than Linux can. Very weird. This may also depend on the I/O scheduler, which one are you using ? > Linux refuses to mount the UFS fs. Not too surprising, since it's FFS 6.0. > This wasn't intended to be a "BSD is better than Linux" thing. I rather hope so. > > > > > The biggest disk speed problem today for SATA is the lack of NCQ supp= > > ort. > > > > > Developers are having trouble getting info on how to access NCQ for > > > > > various controllers. Thus, this is an area where an open-source SATA > > > > > controller could help significantly. > > > >=20 > > > > This market is taken or will be in the near future, at least at the > > > > low-end : > > >=20 > > > low end vaporware? > > > > SiliconImage chipsets are not vaporware. Also, what is in the pipeline now > > should be available for sale a few months from now, so I would not count > > AHCI as vaporware either. > > "or will be in the near future" sounded like vaporware. > > Has SiliconImage gotten their act together? Some of their SATA chips > are buggy. Luckily the one I have is merely very slow. (2 drives > together total 40 MB/s dd-ing sequential sectors from the raw device, no > buffer cache, no filesystem. Compared to the nf4u which does 65-70MB > *per drive* running 4 drives at once. Same make&model drives) What I heard was that SiliconImage controllers on some NF4 mainboards behave badly. The benchmarks I've seen on good SiliconImage boards are surprising, with Sil-3112 and 3114 being faster than anything when they got out, including even Intel ICH6. > > Antivirus servers running on F/OSS prove that F/OSS is superior in > > terms of security than proprietary software from Redmond. I do not > > see how this helps WHG III. > > If you help the morons keep the virus away from the virus servers, > they will continue to run virus server. Or buy existing proprietary antivirus technology to keep the virus at bay. F/OSS loses a foothold. > > People started > > using Windows when F/OSS was not an option. > > Unix has been around far longer than virus server. Unix has never, > even in the early days, had the level of problems that virus server > has. UNIX was not as affordable as Win95/NT 10 years ago, by a wide margin. People got hooked on the MS ersatz. No need to rewrite history, this is what happened and we all wish it had not. > > Whole companies cannot > > make the switch from proprietary (especially Windows, not UNIX) > > to F/OSS > > Proprietary UNIX is not a problem. Having source is better, certainly. > but proprietary UNIX doesn't create massive amounts of problems, > the companies that sell it aren't constantly being hauled into court > for illegal business practices, etc. etc. etc. Yes, hence the "not UNIX" comment. Also, it's far easier to migrate from UNIX to FOSS than Windows to FOSS. > > Let's help them and > > make money at the same time. > > Help them migrate away from virus server, yes. > Help them keep virus server limping along, no. I'm not sure willingly losing a market this way is a good idea. On the other hand, even if antivirus software is typically very CPU-intensive, I am not even sure there is a market in the first place :) François _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
