

2.2 vs 2.4 150
bevo wrote to us with a shoot-out review of kernel 2.2 vs 2.4. It covers what's been updated, some benchmarks, and also has a good page on how to compile your own kernel, including modules recommendation and such.
Them as has, gets.
Re:The real 'end' for 2.0.38? (Score:1)
Well, I for one certainly hope so. The less bug-reports for me to handle, the better... I can't say that I've been drowned in reports, though.
The reason a lot of people run v2.0.xx is that this kernel-series is well tested and most bugs documented, hence its behaviour is mostly predictable.
Re:Good Fnarg! that article is so full of shit. (Score:2)
I'd have to buffer to hell to be able to encode a-la unix filters.
and like the other guys said, I want to edit the music after the initial capture; mp3 is not a directly editable format.
--
Re:Good Fnarg! that article is so full of shit. (Score:1)
Re:Good Fnarg! that article is so full of shit. (Score:1)
As far as the encoding is concerned, I strongly doubt the Fraunhofer codec would be considered the best. Fraunhofer may have produced the first popular MP3 encoders but they certainly don't know much about audio fidelity because their encoders all distort the upper-end of the audio spectrum. I honestly find that our beloved LAME encoder works fine and cleanly. I still have my highs (the resulting MP3 data is actually too clean for my MPTrip, which tends to clip since it wasn't tuned for such strong high-ends). Not only does it retain good sound quality but it is also lightning fast on my PC (p3-850), averaging 9x encoding. That's 9 times more than you need to record live.
Re:2.4.0 (Score:2)
Re:Good Fnarg! that article is so full of shit. (Score:2)
I might not have qualfied my statement enough, then; for 128k encoding, its still surely the best. show me any other encoder that produces as listenable a result at 128k only. the freeware ones are known to be better at 160 and above (more like 192k for me) but for the highest compression ratio, frau is still (sadly) the king.
their encoders all distort the upper-end of the audio spectrum
I've not been bothered by this, even though I've heard its true. I'll easily trade some mushiness in the high end for ringing (yikes!) in the midrange. midrange 'honk' (no, I'm not being racist [g]) is so objectionable, I just cannot listen to anything at 128k but frau output.
yes, I'll give you that LAME is fast. but it doesn't optimize nearly as much as frau does. when I give frau the switch -qual 9, it takes FOREVER to process; but I then know it "huffman'd the hell" out of the source and found every bit of space it could save. by doing that, it has more bandwidth (bits) to allocate to the high and mid end.
--
Re:Small niggle with the article (Score:2)
UDMA100 channel is capable of up to 100MB/sec. We've actually tested various UDMA 100 controlers on a RAM IDE drives. (Where storage was to NVRAM not a platter) And we've seen sustained transfer rates of up to 70-92 MB/sec (depending on the IDE controler) Yes 92MB/sec. What does this mean? Well when the data goes from the media->drive cache->cable it's capable of going at the same speed as data coming of the drive. Your limiting speed is the media read/write speed.
Sure if you are using a 40MB/sec drive on a UDMA 33 channel you're limiting factor will be the IDE channel. But that's like using a UW drive on a SCSI 1 controler. Same issues.
Ok Driver isssues? Exactly what driver issues are you refering too? The only drivers you need for IDE are for the controller and only if u want to use the high performance features of SOME manufacturers. (Same as with SCSI or are you trying to tell me I don't need the Adaptec 2940 etc SCSI driver to use a scsi drive? )
As far as this sentance (your quote): because I said: "Just because you can get the data to the drive cache that quickly doesn't mean you can pump it over the channel that fast... ie the speed of the channel. 33/66/or 100 MB/sec (UDMA33/66/100)"
"Just because you can get data to the drive cache... "
Well if I get the data to the drive cache that quickly it's ALREADY traveled over the channel. Tus the speed the data arived in the cache == speed of the channel. hmm make sense? Or are you trying to convince me that data magically arives at the drive cache and THEN travels over the channel. The only way I could logically interpret that sentance was by by assuming that by channel you are refering to the read/write channel... which is the internal channel between the cache and the read/write channels ON the drive itself.
So before you argue with someone that's written drive firmware as well as debuged drive hardware please read up on disk drive design 101.
On a further note 33/66/100 are infact SUSTAINED rates.. not BURST. Often times you hear people say "you'll never see 100MB/sec with current drives except in a burst mode". What they are refering to is that since the read/write channel of the drive, (The read/write speed to the media) can't sustain 100 MB/sec (limited to about 40MB/sec right now) the only time you see 100MB/sec is during a short burst where data is being dumped to the drive cache.
However.. when the cache is full the channel speed will back off to the sustained rate of the drive. So on a drive with 2MB onboard cache the first 2 MB will BURST at 100MB/sec.. any data following that (if we are constantly streaming) will be then transfared at the to media speed of the drive, 40MB/sec in the case of the seagate drive.
This IS the same thing as puting the X15 on a UW (80MB/sec) SCSI controller. The drive will burst at 80 MB till it's cache is full, after which it will transfer at 41.5 MB/sec in the case of the X15. In otherwords the same damn principle aplies whether you are using a SCSI or an IDE drive. And by the way an 2-3 year old SCSI drive will no way in hell sustain 33-35 MB/sec as you claim. Check your numbers. Like I've said earlier the sustained transfer rate is a component of (media density)*(rpm). The current generation plater technology is now at 20MB/platter (soon to be 30) 2 years ago they were still at about 6MB. This is roughly a 2.5-3x performance increase in raw transfer rate. A 2-3 year old 7200 rpm drive is somewhere near 18-20 MB/sec at best.
Oh and BTW.. right now IDE is leading in platter density. Which also explains why a seagate 7200 RPM IDE drive has nearly the same sustained rate as their 15000rpm SCSI drive. The SCSI drive uses lower density platters. I can give you a reason for that. Because SCSI drives are optimized for high seek usage such as database or heavily loaded servers. To gain that kind of seek performance (about 1/2 that of ide drives) The have to use lower density platers to give themselves more tolerance for offtrack errors. The tracks are wider and more forgiving if a head is slightly of the center of the track.
I will stick by what I have said earlier. SCSI is a waste of your money unless you have a need for more then 4 drives in your PC or are running a heavily accessed DB or over loaded (Seek Heavy) server. So before you flame me for not checking MY facts.. please insure you have yours strait. And please get a clue to what you are talking about. What you have said is typical "I spent a crapload of money on SCSI hardware and need to defend my decision FUD".
Re:USB (Score:1)
--
Re:Small niggle with the article (Score:2)
>"We've actually tested various UDMA 100 controlers on a RAM IDE drives. (Where storage was to NVRAM not a platter) And we've seen sustained transfer rates of up to 70-92 MB/sec (depending on the IDE controler) Yes 92MB/sec."
Yes, and it's that 70-85 range that bothers me (probably limited on the other side of the controller), though UDMA/100 is better than UDMA 66 and 33 in terms of actually reaching the theoretical throughput. With some of the Quantum solid state drives, we've achieved 75+MB/s on an U2W system (a few different controllers) (and 70+ on many others).
>"Sure if you are using a 40MB/sec drive on a UDMA 33 channel you're limiting factor will be the IDE channel. But that's like using a UW drive on a SCSI 1 controler. Same issues."
UW on SCSI1... that's more like using a 40MB/s drive on a PIO/1 channel... or 40MB/s 66/100 drive on a UDMA/33 channel is like using a 40MB/s U2W drive on a F/W or UW channel.
>"Ok Driver isssues? Exactly what driver issues are you refering too? The only drivers you need for IDE are for the controller and only if u want to use the high performance features of SOME manufacturers. (Same as with SCSI or are you trying to tell me I don't need the Adaptec 2940 etc SCSI driver to use a scsi drive? )"
I was referring to the specific device support, rather than the driver for the controller. SCSI has a (IMHO) nicer command set to work with, which makes disparate types of devices easier to work with.
>"Well if I get the data to the drive cache that quickly it's ALREADY traveled over the channel. Tus the speed the data arived in the cache == speed of the channel. hmm make sense? Or are you trying to convince me that data magically arives at the drive cache and THEN travels over the channel."
I'm getting the data to the cache from the media, as I've tried to make clear with: "disk -> cache" (assuming that one enables the read cache on the drive), since bursting from the cache (as I was saying) gives the highest possible channel speed.
>So before you argue with someone that's written drive firmware as well as debuged drive hardware please read up on disk drive design 101.
Ok, I talked to myself and some others here at work (some guys who collectively have a couple decades of IDE and SCSI hardware and firmware experience), so you could take that advice yourself, and try to read and understand my comments before you reply... so far you have managed to take quite a bit out of context and not attempted to understand the basic points.
>"And by the way an 2-3 year old SCSI drive will no way in hell sustain 33-35 MB/sec as you claim. Check your numbers. Like I've said earlier the sustained transfer rate is a component of (media density)*(rpm). The current generation plater technology is now at 20MB/platter (soon to be 30) 2 years ago they were still at about 6MB. This is roughlya 2.5-3x performance increase in raw transfer rate. A 2-3 year old 7200 rpm drive is somewhere near 18-20 MB/sec at best. "
But I said (note the new emphasis):
"Well, using my Adaptec 2940-UW, and ***a couple*** of 2-3 yr old (maybe a generation ago, if you like) UW drives (10krpm 9GB, 7200 RPM 18GB) I can do 33-35MB/s at about 4-6% util"
Note that "a couple" of drives would indicate that more than one is actually used at once... two at 18-20MB/s (which is what they do, roughly) => ~36MB/s. Wow. I'm glad you read that line before irrationally flying off the handle again.
>"I will stick by what I have said earlier. SCSI is a waste of your money unless you have a need for more then 4 drives in your PC or are running a heavily accessed DB or over loaded (Seek Heavy) server. So before you flame me for not checking MY facts.. please insure you have yours strait. And please get a clue to what you are talking about. What you have said is typical "I spent a crapload of money on SCSI hardware and need to defend my decision FUD".
I agree that the new IDE drives are a far cry better than they used to be, and priced very well. Right now I have 8 hard drives, two removable media drives, two CD/DVD/CD-R drives, and one tape drive attached to one system (for personal use). Nice and easy with SCSI (maybe once I see some reasonable DDS-3 IDE drives we'll talk).
>What you have said is typical "I spent a crapload of money on SCSI hardware and need to defend my decision FUD"
Actually, I spently fairly little money (relative to the regular retail cost of the setup), and something about working with machines at work that (typically) have anywhere from 30-300 drives (not to mention the amazingly expensive controllers we happen to produce). Sounds like a pretty good reason to me. I'm justifying work results more than home use. My two other systems are IDE, with gobs of storage (cheap). Personally, I have tested the speed of the same system with the 2-3 yr old SCSI storage in it vs. the 6-mo old IDE storage... the older stuff comes out ahead on anything that bothers with any sort of seeks.
BTW, the areal density on the biggest SCSI drives isn't any different than that of the big IDE drives right now.
I'm not spouting FUD to justify myself. I mostly object to the fact that you can't read and digest my comments without misunderstanding them.
--
Re:USB... (Score:1)
Re:Old machines (Score:2)
There's no reason not to at least try it out, (except that it'll take a couple hours to compile the kernel on your 486!), so go for it.
Re:Small niggle with the article (Score:2)
First Off:
I'm getting the data to the cache from the media, as I've tried to make clear with: "disk -> cache" (assuming that one enables the read cache on the drive), since bursting from the cache (as I was saying) gives the highest possible channel speed.
Ok so if on a UDMA100 controler I can get data from a Solid State drive at 80-90MB sec.. that means my channel can sustain up to 90MB/sec.
If the drive can sustain 40MB/sec thus drive->cache->controler->PC Memory can sustain 40MB/sec.
Therefor your original comment about:
Peak media transfer rate != channel rate... Just because you can get the data to the drive cache that quickly doesn't mean you can pump it over the channel that fast.
Is, like I have stated previously, incorrect. You are always bottlenecked by the slowest component. Which is infact the drive.
Next Up:
But I said (note the new emphasis):
"Well, using my Adaptec 2940-UW, and ***a couple*** of 2-3 yr old (maybe a generation ago, if you like) UW drives (10krpm 9GB, 7200 RPM 18GB) I can do 33-35MB/s at about 4-6% util"
Ok now. If we are to compare apples to apples I can take a "couple" of 2-3 year old IDE drives and ALSO get 33-35 MB sec. (Raid 0 - Striped across 2+ IDE drives) Apples to Apples.
And Finally:
ATA specification is infact a subset of SCSI. ATA was never intended to be used with tape drives, scanners,printers, etc. ATA is a simplified technology and command set for random access block devices only. ( Disks,cdroms,etc ) Heck look at the supported commands and their HEX values.. they are the same as SCSI. And Simple is not always worse. It is true that 5-6 year old IDE controler implemetations were frankly crap.. this is not the case today. As with all things in the technology where there is harsh competition the products released improve in quality tremedeously from generation to generation.
BTW, the areal density on the biggest SCSI drives isn't any different than that of the big IDE drives right now.
Please prove me wrong by showing me a 7200RPM (or faster) SCSI Drive that I can purchase today with a platter density of 20GB/platter or more. The one such IDE drive is the Western Digital Caviar WD400BB.
The reason you can't is because there isn't any. SCSI drives sacrifice capacity for performance. The lower platter density allows SCSI drives that 5ms access time. The other reason is because IDE drive manufactureres are in a Capacity war. SCSI vendors are in a accestime war. 2 different requirements yielding 2 different results. IDE == high capacity/ high acces time. SCSI == low capacity / low acces time. Each has their use.
Re:Old machines (Score:2)
As the wise old UNIX programmer from the Dilbert cartoons once said:
Here's a quarter, kid. Go buy yourself a real computer.
Well, to give you an example of how a 66MHz 486DX2 would be useful: dirt cheap NAT/Firewall box. Yes, the Linksys box is going for less than $100 in the two-port (one for the network, the other for the Internet) configuration, but I was able to get an old DX2-50 box for $30 from a friend.
I have two NE2000 NICs sitting around, a CD-ROM and an ISA IDE card that originally came with another CD-ROM...these are parts in my parts pile so they're technically free.(as in Beer.) Linux or FreeBSD or OpenBSD are all free OSes.(both as in Beer and as in Libertas.) So I'll have a NAT/Firewall box for $30. And one more computer will be saved from the landfill and made useful again..
----
http://www.msgeek.org/ -- Because you can't keep a geek grrl down!
Re:Small niggle with the article (Score:1)
Under FreeBSD 4-2:
su-2.03# dd if=/dev/ad0s1 of=/dev/null bs=524288
1302+1 records in
1302+1 records out
682665984 bytes transferred in 23.191338 secs (29436248 bytes/sec)
su-2.03#
This almost 30Mb/s sustained. I was shocked. I thought I would get a much lower number.
SCSI is still superior when dealing with mutliple devices, or when doing complex thing, but EIDE is pretty good those days...
Cheers,
--fred
linux-2.4.0 & gcc-2.95? (Score:1)
Re:Small niggle with the article (Score:2)
However after the 1st 2MB the cache is now full and you will see the true to media data rate. Which like I've said is upwards of 40MB/sec on the outer diameter and 26+MB/sec on the inner diameter. Remeber the OD moves FASTER then the ID relative to the head. This is why the OD transfer rate is much higher.
The BS you are saying about SCSI is just that; BS and FUD. The only differance between SCSI and IDE is the protocol and controller. It's the same PHYSICAL hardware with a diff chipset. SCSI vendors would like you to believe that their SCSI drive is FASTER then everyones IDE drive but that is just NOT THE CASE. (It used to be the case but is no longer true)
SCSI is excelent for multiple devices on a chain. That's about it. (Well that and if you want to pay for that 10K rpm drive, since there is no IDE drives at 10K right now) Additionally those 180MB/sec 360MB/sec SCSI transfer rates are also misleading. For that kind of performance they require a 64Bit/66Mhz pci slot.. because otherwise you are limited to a max of 132MB/sec by your PCI bus ANYWAYS.
So before you go of and tout how SCSI creams IDE. 1st check your facts and LOOK at www.storagereview.com and compare 7200 rpm scsi and 7200 rpm IDE drives.
The problem you see with IDE drive "slowness" is because your PC does not have UDMA mode turned on. "/hdparm -d1
Re:2.4.0 (Score:2)
If I'm not all mistaken, this is due to a problem in XFRee, not in the Linux-kernel. You should be able to solve this problem by updating to a later version of XFree (possibly a CVS-version is needed.)
Good Fnarg! that article is so full of shit. (Score:5)
In addition to this robust filesystem support, the 2 GB file size limit has also been done away with -- although I don't know exactly who has 2 GB files sitting around on their platters
How clueless can this guy be ? If someone went to such great lengths to defeat the 2gb limit, then I'm pretty sure it's because it's been a problem for a while. Uncompressed video comes to mind, where a reasonable clip bucket can contain well over 10gb of data. Databases also get pretty huge when you start collection data from the web (search engines perhaps, or DoubleClick stats). Next.
Also, at the speed processors are progressing at (we're already at 1.5 GHz), the 2 GHz mark is coming soon -- something Linux 2.4 adds support for.
Ok, will someone tell me how the hell you add support for speed ? Ok so 8 years ago we had a problem with Turbo Pascal's timing loop overflowing, and they all learned to never write such stupid timing code ever again. What could possibly work on my p3-850 that won't work on a 2ghz cpu (besides CGA Pong) ? Software doesn't need to know the speed of the supporting cpu, it just needs to do its thing as fast as it can, and wait if absolutely necessary. Timing is important in code (especially games), speed is not. Speed is merely a byproduct of time.
Linux 2.4 adds support for Wireless LAN devices and also includes PPPoE within the kernel itself
Funny, I thought anyone could include PPPoE in the kernel when configuring it for a recompile. Perhaps he could have mentioned that it was enhanced and tweaked, but saying it's included in the kernel is like saying your brand new car comes with a steering wheel. Du-uh!
Well that's about all I could squeeze out of that one page of blab. Have a great kernel!
More to installing 2.4? (Score:1)
Re:2.4 Rocks (Score:5)
Rotfl. So does it means that 2.2 sucked despite all the claims that it was a server-class OS ?
I used 2.0 and 2.2 for a loooong time. A lot of things sucked badly (overall, it sucked less then the NT4 boxes I rhad), but I generally got bashed when pointing those suckage. Now, it is pollitically correct to talk about shortcomings of 2.2 ? (As long as I don't point any 2.4 problem...)
Cheers,
--fred
Re:USB... (Score:1)
Re:Do this on other platforms (Score:1)
(Oh, you mean _the_kernel_. Oh. Ah.)
Re:Good Fnarg! that article is so full of shit. (Score:1)
Re:Filesystem inaccuracy (Score:1)
I was feeling pretty 1337 at that time
Re:Good Fnarg! that article is so full of shit. (Score:1)
Btw these are used for submillisecond delays most of the time, you don't want to have a timer interrupt at 10 or 100kHz, do you ? Linux does have a regular timer interrupt at 100 Hz on most architectures for system management chores.
So for 386 and 486, the only reasonable solution is to use delay loops. For Pentium+ the TSC can be used but the problem was that it was calibrated by counting CPU clock in one second which might overflow in the near future. Note that having a TSC which counts at the core clock frequency is overkill when your CPU runs over 5 times the bus clock, which is the one which determines externally visible effects. In this case, PPC gets it right since the CPU timebase is based on the bus clock divided by 4 for most models, which corresponds roughly to the shortest possible I/O access time or the duration of a data burst transfer to fill a cache line. This would allow up to 8 or 16 GHz bus clock, which we aren't going to see in a _long_ time, if ever.
This said this is one the worst articles on 2.4 I've ever seen...
38,000 not 38! (culture difference) (Score:2)
The original post was probably posted by somebody who comes from a culture where '.' is the demarcator for thousands-place instead of ','. i.e. 38.000 == 38,000. Either that or they typo'd, after all the two keys are right next to each other.
Based purely on personal experience, I can say with authority that linux can handle > 38 tcp/ip connections simultaneously :-).
--
Fuck Censorship.
silly american... (Score:1)
Realize that in several European locales (like ... I dunno, Germany), the meanings of '.' and ',' in numeric contexts are reversed from American usage.
The world's a lot bigger than your little corner of it, my friend. He was saying 38000 connections.
Re:Good Fnarg! that article is so full of shit. (Score:2)
Filesystem inaccuracy (Score:2)
is only available under PPC linux. This is
false.
That is all.
K.
-
Re:Good Fnarg! that article is so full of shit. (Score:1)
Regards, TOmmy
USB... (Score:1)
------
*lmao* (Score:1)
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
Re:Do this on other platforms (Score:2)
The *full* version ? This means everything from the kernel to the applications, including the C library. On what linux distro did you do that ?
Btw, I do it once a week on my operating system (freebsd)
cvsup -L 2 stable-supfile
make buildworld
make buildkernel KERNEL=SIDONIE
make installkernel KERNEL=SIDONIE
make installworld
mergemaster
Did you really do this on your platform, or are you just making noises ?
Cheers,
--fred
2GHz issues (Score:3)
IIRC, there is a potential problem with very fast (>2GHz) processors confusing the delay loop calibration.
Check out calibrate_delay in
It uses an unsigned long to count ticks. So, on a 64-bit fast processor, there's probably no problem.
On the other hand, I may be completely wrong.
Re:Small niggle with the article (Score:1)
-- Eat your greens or I'll hit you!
Another great article about 2.4 (Score:3)
Re:2.4 Rocks (Score:1)
Does this that Linux is using Microsoft's standard marketing technique of "New version out - must diss current version to acquire beta testers" now? Gaaah!
Re:My take on 2.4.0 (Score:1)
This gonna be a good GNU/Linux year (Score:1)
Re:Filesystem inaccuracy (Score:1)
Indeed, the FAQ for the HFS filesystem driver in the Linux 2.2 source tree states:
So, it would seem that actually it should work on x86 first.
--Joe--
there is a fix for this problem: (Score:1)
Re:Old machines (Score:1)
2.4.0 won't boot on 386's (or at least some 386's, I don't remember) due to a small bug that's fixed in the 2.4.1 pre-patches.
IIRC, it also uses slightly more swap space to do exactly the same thing, so disk space may be an issue as well.
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Re:The real 'end' for 2.0.38? (Score:1)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Re:linux-2.4.0 & gcc-2.95? (Score:1)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
Re:Small niggle with the article (Score:1)
Anyway you are right that a modern IDE drive could swamp an ATA-33 bus (just: 37MB max sequential transfer rate on today's fastest IDE disk). But the fact is that most transfers are not sequential in nature, and for random access modern SCSI drives have 2 to 3 times the performance of modern IDE drives.
Hell, even the aging Seagate Barracuda 9LP is faster in every StorageReview benchmark than the IBM Deskstar 75 GXP, which is the fastest IDE drive you can buy today. The Seagate Cheetah 18XL really creams the IBM (for only ~$225, mind you), while the Seagate Cheetah X15 (~$425) positively destroys any other drive available.
Re:2.4.0 (Score:1)
Summary;
1. Make sure that you have the usb-storage module compiled in and scsi support. I think its experimental still.
2. modprobe usb-storage.
3. plug in camera
4. read console output and find out what scsi dev it was mapped to.
5. Mount that device.
Re:Good Fnarg! that article is so full of shit. (Score:1)
So they changed the type holding this value (including delay loops, calibrations, and whatever else) to allow Hz values over 2G.
Re:Good Fnarg! that article is so full of shit. (Score:2)
I've heard that Microsoft Windoze ME is having problems with some faster processors because it is shutting itself down faster than the disk subsystem can go down. Now as to why this is being done asynchronously I canna tell you. Of course, this *is* Micro$oft we're talking about and flashiness is more important than stability.
How the fuck can shutting down the fucking computer be so fucking difficult??!!??
Fsck.
Re:Do this on other platforms (Score:2)
Re:Linux People Read On ... (Score:1)
do u speak english?
is english your native language?
i am not.
i am a chinese from hongkong.
english is not my mother tongue,but even a grade 6 student can figure out your grammer sucks...
techie guy!@#$%^
Re:USB (Score:2)
It'd be really easy for a network card to stick in one or two extra bytes every hour, until it had a sample of your processor's L2 cache (merely 64k on some processors). You wouldn't even notice it with a sniffer, unless you were paranoid.
Seriously, it'd be interesting to implement, just to see if anyone did notice it. And it'd be sort of fun to look over all those L2 cache dumps.
Anyways, lots of hardware manufacturers in the past ignored everyone but Microsoft customers; so much so, in fact, that it was either common knowledge or the equivalent (a strong, persistant rumor -- which is the best you can do when everything in the industry is covered by NDAs) that those companies were in bed with Microsoft big time. Or Intel. Why else would companies (say, 3COM) suddenly discontinue popular products (say, the Big Picture PCI video capture board) and replace them with brain-dead USB models that have half the features... and call it an upgrade? It doesn't make too much sense to me, except to believe that either Intel or Microsoft convinced them to 'retire' the PCI product.
So, of course it happens. And lots of corporations will happily ignore a significant minority (I'm sure that non-Win95/98/ME users make up over 10% of the desktop market; Win2k and NT must be somewhere around the size of the Mac or Linux desktop installations). Just look at the number of video card, sound cards, and USB peripherals that plain don't work outside of Win 98 or Win ME. Many more have seriously reduced functionality on Win NT4 or Win2k. Forget ever using them under a non-MS operating system.
Your best bet is to just hardware from manufacturers that are Linux friendly, ignore technology that does not have an international standards organization behind it, and wait until the second revision of any product before expecting stable (ie, in the stable kernel) Linux drivers.
Life sure is easy when you go with an all SCSI setup. Everything is a SCSI device. None of this weirdness with IDE, parallel port, or USB peripherals. Blech. They're all slower than SCSI, too. (Ultra DMA/66 and 100 are plain marketing bullshit. All you need is Ultra DMA/33 for 90% of the high performance EIDE hard drives.)
I suppose I just wanted to spout off.
Oh yeah, one more thing. There really aren't any I2O peripherals or motherboards out there, even though it's been years since Intel introduced it. There's the Asus P2B-D2, with integrated SVGA, SCSI, 10/100 NIC, and dual Pentium II support, but precious few other products. Mostly just triple channel Ultra 160 RAID adapters, which tend to cost as much as a used car.
Re:More to installing 2.4? (Score:1)
2.4 changes the layout of modules, and the new modutils handles the new layout.
mainstream commerce (Score:2)
How exactly is this new? I'd say there is LESS focus on the mainstream today than at almost any time in the past. Can you imagine, say, a shoemaker in the 1500s marketing to Jews because it was "cool" to be countercultural and antiestablishment like that? I dunno about where you live but every record store I've ever gone to the largest section is "Alternative".
filesystems (Score:1)
It is of course also helpful for those users who are forced to dual-boot because they have that one damned application they can only run in Winblows.
Why no benchmarks with SMP? (Score:3)
Re:Good Fnarg! that article is so full of shit. (Score:1)
Yeah, tell me about it.
When I capture video at 640x480 I stick to MPEG1 at 3.5MBPS. Believe me, your hard drive fills up FAST.
Flavio
Ummm... just curious... (Score:1)
Re:stupid reviewer, learn to speel! (Score:1)
Re:Small niggle with the article (Score:2)
And sure a 180 or 360 SCSI controller can transfer data at 180MB and/or 360MB/sec. BUT what good does that do you if as soon as the data has to go anywhere. (Network or CPU.. or your video editing software) It gets boged down by the PCI bus.
Additionaly Remeber that a SCSI drive (EVEN the XP15) CAN'T transfer data to it's media at even close to 360MB/sec. Sure some day the drives will hit 360MB/sec to the media.. but by then the 32Bit 33Mhz PCI bus will be long gone too.
And IDE drives will certainly keep up. The truth of the matter is that a 7200 RPM 20MB/platter IDE drive and a 7200 RPM 20MB/platter drive have nearly identical sustained transfer rates. (go to storage review and run the sort on transfer rates)
I will give SCSI that they are faster for when it comes to seeks (Most Server tasks).. but again you pay that 30%+ penalty in cost.
Additionally Max Transfer Rate Record for IDE is currently held by the Seagate Barracuda ATA III (7200RPM) at 40.5MB/sec at the OD.
Current Record Holder for SCSI is Fujitsu's MPF3xxxAH at 42.77 MB/sec. The X15 (15K RPM)weighs in at only 41.47 MB/sec.
So IDE is definetly not second chair in peak transfer rates.
The choice in the drive you buy should really depend on WHAT you are trying to do. Buying a SCSI drive for a desktop system is frankly a BIG waste of money. Hell buying a SCSI drive for a small servers is a waste of money. (instead spending the extra 30% for a SCSI drive you're better off geting more RAM for the server to use as cache instead)
The only place I'd use SCSI drives would be in servers that are under heavy load or are under constant random access patterns. (Where your read cache is being trashed constantly) Or require a lot of drives.
Re:Fluffy article - memory management? (Score:1)
Re:Good Fnarg! that article is so full of shit. (Score:1)
Re:Do this on other platforms (Score:1)
why? (Score:1)
Why? Is Linux 2.4's NFS incompatible with other NFS clients? Stoopid kernel developers.
NFS finally doesn't suck. (Score:3)
Bottom line, if you need a free high availability NFS server, 2.4 is a godsend. If you have the cash, I still recommend sticking with Solaris, however.
Re:mainstream commerce (Score:2)
The word of the day is: co-option
Re:What I think (about what he thinks he thinks) (Score:2)
The parent of that post is funny, too, but I don't know if it was meant to be. It certainly says something, though, about how many moderators don't actually read the story they are moderating.
Re:Good Fnarg! that article is so full of shit. (Score:2)
A speed issue would be a delay loop overflow, but anyone still using counter-based delay loops should sit down with a game developer and learn about more robust throttling methods. Every decent computer architecture has a system clock that can be used to accurately measure time in tiny increments.
On any x86 system you can use the system clock to trigger rhythmic interrupts that keep everything in sync. Good old Dos games used this trick to hit 60fps on the mark without having to wait for vertical blanking to occur. Why couldn't an OS scheduler use this technique to manage timeslices and other boring chores ? I don't know about other architectures but surely there is something analogous to this method.
Re:2.4.0 (Score:2)
pere
Re:Filesystem inaccuracy (Score:2)
Re:Good Fnarg! that article is so full of shit. (Score:3)
Actually this is new. Previously to get PPPoE support (in a stable kernel) you had to install a kernel patch or use a client that runs in user land (e.g., rp-pppoe - which is excellent, thanks David). Now it's included in the kernel.
I agree with everything else, though. This guy needs a couple of good whacks with a cluestick.
Re:Small niggle with the article (Score:2)
Re:Small niggle with the article (Score:2)
I also thought that that assertion was suspect, based on my own "real world usage" experiences. The motherboard drivers for my PCs (I have 3, all the same config) at work have an option to enable ATA-66 mode or not when you install them. We're developing an application that requires loading a large landscape database (these are PIII 700s with 512 MB RAM). When the option is not enabled, loading the landscape takes on average 35 to 40 seconds. When enabled, the load time drops to, on average, just under 20 seconds. Nothing else on the configuration was different, only that, and those values are the average of many load times.
Re:Do this on other platforms (Score:2)
Re:Small niggle with the article (Score:2)
That's nice, I've been working with the hardware and firmware for drive controllers for a while myself...
Thank you for completely misreading my post...You said: "And the fact of the matter is that an IDE drive can SUSTAIN over 40MB/sec at the outer diameter. THIS IS TO THE MEDIA rate."
because I said: "Just because you can get the data to the drive cache that quickly doesn't mean you can pump it over the channel that fast... ie the speed of the channel. 33/66/or 100 MB/sec (UDMA33/66/100)"
Meaning: Just because disk -> cache = 40MB/s
!=> cache -> controller via ide cable at 40MB/s
So you are hot and bothered about agreeing with me... (except that a 33/66/100MB/s is the peak burst rate, not sustained - that was my point).
You said: "Remeber the OD moves FASTER then the ID relative to the head. This is why the OD transfer rate is much higher."
I don't remember disputing that, but thanks for sharing.
You: "The BS you are saying about SCSI is just that; BS and FUD. The only differance between SCSI and IDE is the protocol and controller. It's the same PHYSICAL hardware with a diff chipset."
Me: "IDE is a *slow* protocol, and fairly braindead"
Wow, we were both talking about the protocol, and I never mentioned drive hardware - just interface hardware. Looks like you are upset about agreeing again. Obviously, the newer technology that was developed for server drives is now on the desktop. I never disputed that.
You: "SCSI is excelent for multiple devices on a chain. That's about it."
Well, let's see - try to attach an external cabinet with IDE... oops, sorry. The range of devices is better, the driver support isn't as complicated, and there's better error reporting, configuration, and on-the-fly debugging... but that's ok - that's beyond the desktop space anyway, and it doesn't seem as if you want to consider that. I'll get back to my utilization #s a little later.
You: "since there is no IDE drives at 10K right now"
Well, I've had my 10krpm UW SCSI drives for a couple of years now - some things don't catch up as quickly as areal density (mostly because people don't want to pay for them).
You: " Additionally those 180MB/sec 360MB/sec SCSI transfer rates are also misleading. For that kind of performance they require a 64Bit/66Mhz pci slot.. because otherwise you are limited to a max of 132MB/sec by your PCI bus ANYWAYS."
Another true statement that is irrelevant to my argument... I only mentioned U2W, which is 80MB/s, and has worked (for quite some time now) rather quickly. A lot of the equipment I work with has had 64b/66MHz slots for a long time, too... but again, for the desktop space, U2W is pretty reasonable.
You: "The problem you see with IDE drive "slowness" is because your PC does not have UDMA mode turned on. "/hdparm -d1
Well, using my Adaptec 2940-UW, and a couple of 2-3 yr old (maybe a generation ago, if you like) UW drives (10krpm 9GB, 7200 RPM 18GB) I can do 33-35MB/s at about 4-6% util on a Celeron 300a... bummer. That's not as many %s as you, I gess you win that one
You: "So before you go of and tout how SCSI creams IDE. 1st check your facts and LOOK at www.storagereview.com and compare 7200 rpm scsi and 7200 rpm IDE drives."
So before you go off and FLAME someone using CAPITALIZED WORDS all OVER the place, MAYBE you should READ the other post and THINK and/or CHECK your FACTS...
--
Re:Do this on other platforms (Score:2)
If I'm not mistaken, Debian can do this. I believe it compiles source
Debian's about as close as it gets to ports, and it's smarter about downloading dependencies simultaneously.
--
Re:Do this on other platforms (Score:2)
Apparently Linus doesn't even consider necessary parts of the kernel to be worthy of the distribution. New kernel, old modutils? Better hope your network driver on that headless box wasn't a module. Better hope init still works too.
--
Old machines (Score:2)
2GB Limit very easy to bump into (Score:3)
You don't even have to reach that far. Compressed video easilly grows to larger than 2 gb for any non-trivial project. For example, I used dvgrab [schirmacher.de] to capture multiple small video clips[1] from my ieee1394 sony trv-900 camcorder [bealecorner.com] and media converter [insanely-great.com] (sony), then edited them together into a 25 minute home video. This is all using compressed DV format, which is small enough that captures work perfectly fine in realtime to ATA33 IDE drives (unlike traditional analog captures which demand much faster drives because the quantity of data is so much greater).
25 minutes of video, even in 4:1:1 or 4:2:0 compressed DV format, is way bigger than 2 GB.
My solution was to upgrade to kernel 2.4.0 (which is easy to do with Mandrake 7.2, as long as you do not compile in devfs support) with the ieee1394 fixes [sourceforge.net]. I opted to use SGI's XFS [sgi.com] filesystem (which rocks) but to get around the 2GB limit upgrading to 2.4.0 was sufficient (ext2 and reiser both worked fine for test files of about 5.5 GB in size).
[1]This is a limiting bug in dvgrab which segfaults at around 900MB, but works fine in "looping" mode with filesizes 900MB.
Re:Good Fnarg! that article is so full of shit. (Score:3)
and live audio events, as well. if I wanted to record several hours of audio (like a 6hour Grateful Dead marathon on my local FM radio station), I'd need much more than 2 gigs of contiguous storage.
until now, I've had to break my live music into 2gig or less segments. that sucked! now, with the limit removed, I just hit 'record' (well, I type record) then come back 6 hours later and hit ctl-c and voila - I have a large audio file that I can now cut at logical boundaries rather than physical ones.
(of course getting an audio editor to be able to read more than 2gig at a time will be tricky to find; linux is way behind the curve in this aspect; and winblows has problems (much of the time) with even 1gig audio files).
still, being able to store that much audio to disk is the first step. editing it in-place will soon follow.
--
Re:Small niggle with the article (Score:2)
This is untrue. Todays IDE hard Drives top out at 40+MB/sec (YES 40 Mega BYTES per sec) at the outer diameter. This is a SUSTAINED transfer rate. At the inner diameter they hit 26+MB/Sec. So an IDE drive can indeed saturate a UDMA33 bus.
Take a look at the Baracuda ATA II and Maxtor DM+ 60 reviews at http://www.storagereview.com if you don't believe me.
USB (Score:2)
I've seen glimmers of being able to use Windows drivers (using WINE parts I think) to contact USB devices.
Can anyone comment on what to expect from either that or why I shouldn't worry that we'll get everything supported 'in house' despite proprietary device vendors?
--
Re:2.4.0 (Score:2)
Re:Good Fnarg! that article is so full of shit. (Score:2)
Heck - my /home partition comes to well over 2GB compressed. Putting that into a tarfile before 2.4 would have been virtually impossible.
Re:2.4.0 (Score:2)
Did some more searching on the web and found out that it is certainly not supported. Rather disappointing, but you'll have that.
My take on 2.4.0 (Score:5)
with one exception:
I can't get the joystick support working for
my Gravis Xterminator in my SB PCI 128.
I can get it fine under 2.2.17, 2.2.18 and 2.2.19
pre, but not 2.4.0 (xmame just ain't the same
without it!)
But otherwise it's lovely.... It is discernably
faster in use than 2.2.18(ish) which itself
is discernably quicker than the early 2.2.x
series.
Re: 2.4.0 & XFree86 4.0.2 (Score:2)
I've a feeling I might need to fiddle with the shm filesystem and it'll go away; I understand that it's needed to make shared memory (and hence X) run properly.
VIA chipset warning. (Score:2)
I've had simillar problems with the patched version of 2.2.18 as supplied with Debian, and I don't want to go through the same again until I know that it is fixed.
Fluffy article - memory management? (Score:4)
This article is almost completely useless. It tries hard to pretend to have hard technical data and all it has is fluff. I don't understand how anybody could've seriously written that piece and expected it to actually help anybody understand anything.
What did that paragraph actually tell you? Almost nothing. Some vague hand waving about memory management with no specifics at all. Irritating!
I'm actually seriously interested in what kinds of changes were made to the VM subsystem. I know that's what held up the kernel for several months, and I want to know what was done.
Re:More to installing 2.4? (Score:4)
the reason can be found in archive:
linux-2.4.0/Documentation/Changes
There states that newer versions of system utilities need to be upgraded.
The list of minimal versions for some packages
is this:
(copied from the Changes file)
============ begin ==========
o Gnu C 2.91.66
o Gnu make 3.77
o binutils 2.9.1.0.25
o util-linux 2.10o
o modutils 2.4.0
o e2fsprogs 1.19
o pcmcia-cs 3.1.21
o PPP 2.4.0
o isdn4k-utils 3.1beta7
============ end ===========
Re:Good Fnarg! that article is so full of shit. (Score:2)
Small niggle with the article (Score:3)
Whilst it is true that no drive will supply a sustained 33mb/sec, this forgets the overhead inherent in the EIDE protocol itself, which can be up to 30% of the bandwidth down the EIDE bus. Also remember this is per drive too.
--
2.4.0 (Score:3)
I am really having a lot of problems with it crashing X as well (dual heads). It may not be a problem w/2.4.0 but it seems to only have started when I upgraded the kernel.
USB is coming along but it is not yet at a point where it is useful enough for me to give it thumbs up. When my Intel Create and Share USB camera and my Cassiopeia link cradle are supported, I will jump up and down. Until then, it is just a novelty...
Just my worthless
Do this on other platforms (Score:2)
Re:VIA chipset warning. (Score:2)
Kernel Install help for Newbies (Score:3)
Re:2GB Limit very easy to bump into (Score:2)
I've only been using it for a couple of weeks, so I cannot state this with the kind of certainty a few month's experience would grant, but thus far it has been very solid and very fast.
I have been really pleased with it. I actually prefer it over reiser, though reiser is also quite nice. I did have some issues with reiser under Mandrake 7.1
I'll be able to comment on the stability with more certainty in a month or two, after I've been using XFS (at work and at home) and beating up on it a while longer
Re:Small niggle with the article (Score:2)
--
Re:Good Fnarg! that article is so full of shit. (Score:4)
You've seen the BogoMIPS reported in a Linux kernel boot? That measure is reported when the kernel calibrates a certain timing loop which it uses for microsecond delays. There are some *very* good reasons why the kernel still uses timing loops not the least of which is that the gettimeofday() syscall is much too slow for the kernel to use for this purpose.
Believe me, the kernel developers know what they are doing. If you doubt that, spend some time reading the archives [indiana.edu] of the kernel development list or the weekly Kernel Traffic [linuxcare.com] summary.
Re:USB (Score:5)
I can't really answer your question, but I wanted to make the suggestion that if vendors of proprietary devices only support Windows, the solution is not to switch to Windows, but rather to use something else and forego their devices just to spite them.
If we give up and just go with the flow, we are essentially rewarding the behavior that we want to change. That isn't the recipe for success.
I recognize that not all vendors will ever provide open source drivers, but we could at least expect drivers for OS OSes.
In principle I don't object to closed-source drivers, but with the proliferation of spyware and other badbehaviorware, I'm getting to the point that I don't really want to run anything closed on my systems. However, it might be better to postpone that battle for now, and concentrate on getting drivers, open or closed, for alternative OSes.
On the bright side, I notice that Linux 2.4 supports I2O, which if I understand correctly is a protocol for OS-independent drivers. If we could get vendors to ship I2O drivers with all their nifty toys, Linuxers (and others) would be in as good a shape as Windowsers as far as device support is concerned. And it should be in vendors' best interest to ship I2O drivers, because that would let them maintain one driver and sell everywhere, rather than limiting themselves to a single market or having to maintain multiple drivers for multiple OSes.
Of course, with Windows running on 90% of the world's desktops, some vendors may not think that their slice of the remaining 10% is worth bothering with. There's an unfortunate focus on the mainstream in commerce these days.
And of course, MS may be subsidizing some of them a la OEM agreements, with an explicit or tacit agreement that they will only support Windows. If that turns out to be the case, that's all the more reason to shop elsewhere.
--
Re:Filesystem inaccuracy (Score:2)
Furthermore, an HFS driver is already in the 2.2 kernels, and was available for the 2.0 kernels as a patch. I use the HFS driver on my 2.2 kernel, on my Intel Pentium II system, to mount old Syquest 40MB removables I still have from my old Mac days. Works like a charm.
Perhaps the reviewer was referring to HFS+, the newer Mac filesystem?
--Jim