Slashdot Mirror
2.2 vs 2.4
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.
← Back to Stories (view on slashdot.org)
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.
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.
--
--
"It is now safe to switch off your computer."
If you're recording off the radio to begin with, you're not going to get cd quality anyway.
Depends what kind of editing you need to do. If you just want to split it up into smaller pieces without doing any real audio processing (I'm assuming you don't want to run it through a vocoder =) well that can be done with a few utils that work directly on the MP3 stream without recompressing.
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.
-Billco, Fnarg.com
nope, two different cards.
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.
--
--
"It is now safe to switch off your computer."
I shouldn't bother repling this late in the game. BUT I hate to see ignorant posts.
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".
In terms of the L2 cache stealing... say you only have 64/128kB of L2... that you could store in an internal RAM on a network card, though most don't have buffers quite that large. Even if they did, the card wouldn't have access via the PCI bus to the L2 RAMS directly... you'd have to wrangle it out with the device driver. Hmmm, they'd probably end up with a few copies of the task schedulers and network device drivers, though there could be some interesting stuff in there, if it knew when to look (that's the key). If it sampled from the cache only when it was going to xmit (the couple of bytes), then you'd end up with a lot of garbage... better to do spurious DMAs from known good pages in memory... hmm, that *would* make an interesting project.
--
"It's tough to be bilingual when you get hit in the head."
Thanks for eventually replying...
>"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.
--
"It's tough to be bilingual when you get hit in the head."
Yeah, but what I meant was they took the 2.4 "version" of USB support and backported that to the 2.2.18 kernel. And you're right, though IMNSHO "completely hosed" is a slightly better description than "broken".
Ceci n'est pas un sig
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.
Well in that case let's digest FURTHER. Perhaps the problem is that yer comments aren't exactly that clear.
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.
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!
Knowledge is power. Knowledge shared is power multiplied.
I used to think that, but I recently hacked a cheap machine for use at home. ATA-66 (VIA 82C686), 40Gb EIDE drive (Maxtor 54098H8).
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
1 reply beneath your current threshold.
Has anybody tried compiling linux-2.4 with gcc-2.95? Is this still considered Bad Juju?
In the USA, we like stuff watered down, like beer, television, and freedom.
You are WRONG sir. I've worked in the HD industry for 3 YEARS. 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. No cache involved. Most IDE drives these days come with 2MB cache. So that if you write a 2MB file you will see peek burst rate. Ie the speed of the channel. 33/66/or 100 MB/sec (UDMA33/66/100)
/dev/hda" (Or compile it as default into the kernel) A current generation IDE drive running in UDMA100 mode streaming data at 35MB/sec only uses 10-15% CPU on a P2-400.
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
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.)
I don't get it.. this guy sounds like Steve Ballmer on pot.
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!
-Billco, Fnarg.com
I maybe wrong here but isn't there more to upgrading from 2.2 to 2.4? I've not upgraded myself but I've seen lots of people in IRC and Newsgroups talking about having problems with loading modules?
> As far as using it as a server, 2.4 is FAST. Much faster than 2.2. Our SCSI RAID goes about 3x faster and NFS goes twice as fast (over gigabit ethernet).
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
1 reply beneath your current threshold.
Of course, the same USB support is also available in the 2.2.18 kernel. Why they backwards-ported it I'll never know.
Ceci n'est pas un sig
You actually did that? Userland and all?
(Oh, you mean _the_kernel_. Oh. Ah.)
Obviously, you have not been paying attention to what IBM has been doing. IBM has a version of Linux for the S/390, RS6000, and Infinity servers. I expect to soon see Linux for their AS/400 systems. Companies that use these machines may have huge databases. I know from experience in a financial institution, where we had databases of 5GB+. You need to be more open minded. Linux is gearing up to be a capable enterprise solution. It is a waste of time to compete with Windows 9x/ME. These are not good stable OSes for the corporate world. The fact that IBM even considered, let alone developed Linux for the S/390, shows that Linux is no longer just a science project. It is here and it is now. Now Linux should work on some better administrative tools. There are some good ones out, such as webmin, but more are needed.
I compiled the experimental hfs support in the 2.2 series to read hfs zip disks in my crappy pc.
:D
I was feeling pretty 1337 at that time
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...
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.
News for Geeks in Austin, TX
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.
DNA just wants to be free...
Well, silly as you may think it is, ther e*was* indeed a problem with running Linux on a machine with a clock higher than 2Ghz, something to do with the calibration of the dealy loop or something like that I seem to recall.
The article states that hfs (mac filesystem)
is only available under PPC linux. This is
false.
That is all.
K.
-
-- Proud descendant of semi-nomadic cattle-herders.
AFAIK, they needed to make some counters bigger so they don't overflow if the CPU is really fast.
Regards, TOmmy
...Is what I have been looking forward to in 2.4... fully functioning USB that is ;)
------
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
This was so fscking funny! The funnyest thing tho is you have to have lived it to be able to write it. So get out of the closet you fsckin 1337 linux haX0r... :)
--
"No se rinde el gallo rojo, sólo cuando ya está muerto."
$HOME is where the
-- silver_p
> On your lunch hour, download the next full version release of your operating system (service packs are for sissys). Configure it, compile it, install it and be back working with no problems by the end of the hour. That's what I did.
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
1 reply beneath your current threshold.
IANAKD (Kernel Developer) (but I do read the mailing list).
/usr/src/linux/main.c
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.
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
It talks about a DALnet server running stable on 38.000 connections. I found this link on deamonnews a BSD site, and like them I'm quite curious about how well linux 2.4 networking works compared to the latest FreeBSD. The article is here
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!
UNIX? They're not even circumcised! Savages!
You have to compile a new module called ns558 for all gamepads. Give it a try and see if it works.
New Kernel with a lot new features, new gcc with a lot new features (finally one with a proper C++ support), new KDE with included better Kdevelop... We will get a boost of new software and support. So we just need a good packaging standard for all and running a free software system will be possible to everyone. But getting rid of old (quasi)standards is hard, as everybody knows. (A20 gate, tube monitors still have analog input, althoug monitors with an own DAC are better adjustable, there are still C libraries using K/R syntax, there is still no full xml/xslt/MathML/svg featured web browser, BIOS updates run still with DOS, but cheasy keyboard with 156 Windows/IE/Menu keys and a space key(no space bar)are the only ones available.
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
There is a fix for this problem at the Windows Update Site, read about the problem here.
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.
Are you kidding? 2.0.38 is already dead. 2.0.39 was released in early January. :-)
---
The Hotmail addres is my decoy account. I read it approximately once per year.
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.
Concerning your camera.......Have you tried to use the usb-storage driver in 2.4.0. It was able to map my USB Camera (HP 315) to a scsi device.
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.
2 GHz is 2000MHz is 2,000,000,000Hz, sound close to 2^32 ? (ok, using a signed 2^32 type, int?). What happens when you store 2.3GHz into a signed int? Exactly :-)
So they changed the type holding this value (including delay loops, calibrations, and whatever else) to allow Hz values over 2G.
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.
:wq
I mean't, the kernel, I don't consider the rest of the distribution to be the O/S.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
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!@#$%^
xcyber """"""Complexity for the sake of complexity is not a solution, neither is simplicity for the sake of simplicity
If you don't trust the software, how can you trust the hardware? How do you know that 3COM, D-Link, Seagate, and Asus aren't all collecting information about you?
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.
There's an unfortunate focus on the mainstream in commerce these days.
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".
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.
isn't that the true breakthru in 2.4? SMP scalability, especially the scalability of the new networking code? I'd really like to see SMP 2.4 vs. SMP 2.2 vs. SMP 2K.
Never meant half of the things I said to you. So you know, there's a half that might be true - G. Phillips
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.
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
How does one get 32000 connections? My understanding is that each connection is an open file descriptor. I haven't been able to get the kernel (2.2) to compile with > 1024 open file descriptors. Select breaks (even after recompiliing what I thought was necessary) and no matter what I try I can't open more than 1024 connections. Sorry if this is a clueless question...
Seriously, that is one of the least informative articles I have ever read from a link on slashdot. The benchmarks were by far the least informative piece of the entire article.
Russian Russian Russian RussianDollSig DollSig DollSig DollSig
Sure if u compare apples to oranges. Which is what you are doing comparing a 15K rpm SCSI drive to a 7200RPM IDE drive. Compare two 7200RPM drives and u will see that the only thing a scsi drive has is better seek performance. For 30% more cost mind you.
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.
Glad I'm not the only one who thought that article was a waste of the lumens required to read it.
Russian Russian Russian RussianDollSig DollSig DollSig DollSig
I think its time we moved on to a 64 bit file systems, journeled, database like and pervasively multithreaded. Hang on, this is a Linux forum and I'm advocating something BeOS had from day 1.
Revolution = Evolution
Imbecile.
Unless you're exporting those file systems to anything other than Lunix clients.
Why? Is Linux 2.4's NFS incompatible with other NFS clients? Stoopid kernel developers.
cpeterso
Once you've had one of your users fill up you 200 GB filesystem with a 150 GB logfile, you'll never look back again. And yes, I really mean 200 GB, as in 5 of these filesystems give you a terabyte. There really are people with that much data.
Tob
p.s. good luck in the elections!
Thanks. we'll need it.
Weird... I did loads of testing for Vojtech Pavlik to ensure that the Xterminator *is* supported under the new 2.4 input devices architecture. This was last May, so I'd be surprised if it didn't make it in.
If, like me, you've been looking for a free NFS solution, you'll definitely want to try 2.4. There's really no other option at the moment if you need NFSv3 support, as well as reliable file locking (lockd on *BSD doesn't work worth a damn.) Client side NFS never worked completely correctly until 2.2.18, and as a server...I had to reboot it more than a Windows box and deal with stale NFS handles multiple times due to "soft down" situations. I've been using 2.4.0-test11 for about a month and a half now, and it has been solid. Granted, when I benchmarked it's performance against FreeBSD it got owned badly, but at least it can lock files correctly.
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.
See, now that is funny.
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.
That's a timing issue, not a speed issue. The difference lies in the fact that the shutdown process must sit and wait for the drives to shut down. "$foo=time(); while(time()$foo+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.
-Billco, Fnarg.com
Since you are mentioning dual head, Im guessing Matrox G400. There is a known problem with G400, XFree 4.02 and the 2.4.0 kernel at the moment. (my main reason for not upgrading). Looks like Matrox is working to fix this.
pere
Shut up. You're spoiling the party.
> I mean't, the kernel, I don't consider the rest of the distribution to be the O/S.
You said "full version release", so I suposed that it was the whole system.
Now, if you consider that the kernel is the OS, you "OS" is not even self-hosting. Pretty unfortunate, don't you think ?
And upgrading the kernel without upgrading modutils/libc/etc, is really asking for troubles. In particular in the context of the current article (A whole new 2.4. Most people would upgrade from 2.2)
Cheers,
--fred
1 reply beneath your current threshold.
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!
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.
Admit nothing, deny everything and make counter-accusations.
Dude, I've got a 20GB Maxtor, and HDTach reports (average) sustained rates in the mid 20's (over the entire drive.) That means for at least a quarter of the drive, it is saturating my UDMA/33 bus.
A deep unwavering belief is a sure sign you're missing something...
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.
Or... you could eat lunch.... just a thought ;)
A deep unwavering belief is a sure sign you're missing something...
" I've worked in the HD industry for 3 YEARS."
/dev/hda" (Or compile it as default into the kernel) A current generation IDE drive running in UDMA100 mode streaming data at 35MB/sec only uses 10-15% CPU on a P2-400."
;-)
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...
--
"It's tough to be bilingual when you get hit in the head."
I wouldn't want to be the monkey in charge of swapping backup tapes for that filesystem :) It would be a full time job.
-Billco, Fnarg.com
> The *full* version ? This means everything from the kernel to the applications, including the C library. On what linux distro did you do that ?
.debs if you tell it to "install" one. If not, then make dist-upgrade would be a binary-only thing (and you still have to fetch whole packages at once anyway).
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
Well, almost every piece of software sucks in the sense that it could be lots better. :-)
While this smacks of Microsoft style marketing (current product is flawless until new product comes out at which point current product has more holes than a piece of swiss cheese), I suspect it was more of a case of "This is what we have now, if you don't like it, help fix it.". How many of the flame replies that you got say something along those lines?
Need a Python, C++, Unix, Linux develop
> I mean't, the kernel, I don't consider the rest of the distribution to be the O/S.
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.
--
I've finally had it: until slashdot gets article moderation, I am not coming back.
That's what you have tapesilo's for. I know sites with 3 silo's, each containing 5000 tapes. That's about 100 TB of storage per silo (depending on the kind of tape). And despite that, they still have people working fulltime carrying tapes around.
Tob
right. sorry.
Anybody have info on how 2.4 behaves on old/slow machines...say, like a 66 mhz 486? I've been hearing reports that it's "faster" and "better", but there's usually a tradeoff involved.
It's 10 PM. Do you know if you're un-American?
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 [...]
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 to capture multiple small video clips[1] from my ieee1394 sony trv-900 camcorder and media converter (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. I opted to use SGI's XFS 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.
The Future of Human Evolution: Autonomy
I had problem with the NFS lockd exiting with an error... latter I found that it is no more required, since that lockd functionality is now built into the kernel.
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.
--
--
"It is now safe to switch off your computer."
> Incorrect. The ports system is superior to debian packages (in particular, upgrade.)
This is very good news for me, as I have a few FreeBSD boxes out there. Can you tell me how I am supposed to upgrade the installed ports/added packages binaries to the latest versions ? (This is a serious query)
In one word, where is the
apt-get upgrade / apt-get dist-upgrade
of FreeBSD ?
Cheers,
--fred
1 reply beneath your current threshold.
For example - the new ami megaraid driver in there contains a typo, a missing ! symbol which causes it to claim it can't register the IO range, if it can.
That caused me a _serious_ headache, and I'm surprised something like that slipped through (go to the AMI site and you can grab the latest, unbugged drivers)
--
ALL YOUR BASE ARE BELONG TO US!
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.
pkg_version -c > blah
sh blah
The Joystick setup is a little different on 2.4. These are the modules my machine has loaded to get this to work properly:
adi 6448 0 (unused)
ns558 2544 0 (unused)
gameport 1904 0 [adi ns558]
joydev 5568 0
input 3424 0 [adi joydev]
I have a SB-128, with a Logitech Wingman Extreme Digital (now the 'adi') driver. The ns558 is the gameport, which is new. Check the doc's!
> Rotfl. So does it means that 2.2 sucked despite all the claims that it was a server-class OS ? No. And I did not imply that it did. 2.2 was very good. I just said 2.4 is better. > Now, it is pollitically correct to talk about shortcomings of 2.2 ? It always has been. That's the advantage of open source OS's. Do I detect some fear of inferiority here?
The author does not present the standard deviations of his results. Does this mean that there is no average of the timings? Does this mean that there was only one timing? I suspect that for most of the tests, there is no significant difference between 2.2 and 2.4. Of course, had he reported the statistics, then we would not be confused and suspicious of his (useless) report.
--
"You're gonna need a bigger boat." - Chief Brody
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?
--
I'll try that, thanks.
Pretty poorly written article that comments on the improvements in SCSI are shown in the results, then gives you a graph showing a performace decrease...
jh
Heck - my /home partition comes to well over 2GB compressed. Putting that into a tarfile before 2.4 would have been virtually impossible.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
nah, the Create and Share Camera's chipset is NOT supported by the USB driver. I tried what you said and it didn't work.
Did some more searching on the web and found out that it is certainly not supported. Rather disappointing, but you'll have that.
I've tried 2.4.0 for a while now and am loving it
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.
Linux fan and Win32 developer
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.
Why not just record straight to MP3 format ? you'd fit all that radio into less than 500 megs.
-Billco, Fnarg.com
The only differance between SCSI and IDE is the protocol and controller. It's the same PHYSICAL hardware with a diff chipset.
...
Well that and if you want to pay for that 10K rpm drive, since there is no IDE drives at 10K right now
So, are the drives physically the same or aren't they? If they are, why aren't there 10K IDE drives, and why aren't there 40GB SCSI drives?
Despite your years in the HD industry, I think the answer is that they are not actually the same physically. Maybe back in the 4GB era they were, but now "SCSI" is industry shorthand for "designed for always-on server use" and IDE is shorthand for "designed for desktop machines". Not that that difference necessarily affects the speed, but it sure might because it's probably a safe assumption that a "desktop machine" doesn't necessary need great sustained disk performance.
--
Business. Numbers. Money. People. Computer World.
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.
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.
Need a Python, C++, Unix, Linux develop
Source installed by default takes up quite a bit of space. Just look at LFS, which recommends ~700 MB for all the source files (500 if you cut a few extra things out).
I keep a CD image updated that contains all the source I need to build a full system w/X, GNOME, GPG, Kaffe, and some other extra stuff. It takes up ~550 MB. Once compiled, you could easily take up 1 GB or more.
Being that I have lots of machines that are running off of 500 MB hard drives (I also have a laptop that has a 210 MB drive thats shared with FreeDOS), I'm glad the source isn't allways installed by default, but I like to keep it around when I can.
Also, in production systems, I love Debian's apt-get. Sometimes, compileing the latest stuff from scratch gets messy, so allways having the latest stuff in binary form is great. Still, at home I like to compile my own as much as possible.
------
Not a typewriter
Dang right, at the moment terrabyte sized systems are common place in the petroleum exploration industry.
A recent airphoto mosaic I automated, of a city at 1m resolution, came to about 32GB & compressed down to about 8GB or so.
In mid 2004 we'll probably have the $300 terrabyte standard size drive available in stores.
I don't think many people will want to be stuck with a poxy 2GB file limit.
>Debian's about as close as it gets to ports, and >it's smarter about downloading dependencies >simultaneously.
FYI, there is a ports system for Linux. See the Gentoo distribution at http://www.gentoo.org.
Gotta have the source... else why are we always going on about how open and free it is? The debian source packages are a nice idea, but every system should have the source installed by default.
EDA dump files are BIG too. Try simulating a 1 million gate design and see how big the dump file gets for a reasonable run. We're talking several GBytes very quickly. D'uh!
Have you compiled your kernel today??
> If I'm not mistaken, Debian can do this
/usr/src)
This is very possible (IMHO, Debian is the linux distro that sucks less). But generally debian is not at the bleeding edge, hence I suspect that the poster did not use debian to get a 2.4 kernel.
> Debian's about as close as it gets to ports
The few commands I posted are not related to ports. Ports is for the software that is _not_ included in the OS. The few command I posted upgrade the base OS (ie: what is located in
Btw, debian is superior to the port system. The port system sucks by many aspects (in particular upgrade).
Cheers,
--fred
1 reply beneath your current threshold.
> I suspect it was more of a case of "This is what we have now, if you don't like it, help fix it."
:-)
"Don't like" is not a good motivation to fix something. If it ain't broken, don't fix it.
More seriously, recall the mindcraft study. Sure, the benchmarks were founded by M$ and obviously biased, but the bottom line was that TCP/IP performance sucked on SMP (or, more precisely, the whole kernel sucked on SMP [*]). This study have been based to death here. People were screaming that the tests were wrong, that mindcraft lied, etc, etc. It tooks weeks to settle down. Beside few minor points, the study was right, and this helped tremendously the kernel development.
Saying "This is what we have now, if you don't like it, help fix it." is okay, but it often turn into "If you are not going to fix it, shut up", which is much less sane.
Unfortunately most posters here have the "Don't say anything bad about it" attitude that I was pointing to. (For instance the AC in another thread that tells me that the port system of FreeBSD is superior to apt, in particular for upgrades).
Cheers,
--fred
[*] Naked truth. I am/was a NeXTstep/OPENSTEP lover. Well, I can tell you that NeXTstep performance really sucked on SMP (ie: it just ran on a single CPU)
1 reply beneath your current threshold.
Thanks for this tidbit. I was just ready to upgrade to 4.0.2 from 3.3.6.
> > 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.
I think they were afraid the bogomips calculations would cause a numeric overflow.
--
Sheesh, evil *and* a jerk. -- Jade
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.
--
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
seems great!
This is the first release of Linux that is said to truly stack up against Windows as far as speed and compatibility go. It wasn't too long ago that Linux didn't have much support, but in the last year we've seen many vendors hop on the bandwagon. NVidia, ATI, Abit, Lexmark, 3dfx, and SMC are just a few of the vendors that showed their support in Linux over the last year. Still, many companies need to come around, as many third-party hackers were needed to even spur developments of drivers for Linux. Let's hope we have that kind of continued support in the future.
I am still rather disappointed w/the problems w/AGP and DRI support in the kernel. Can't have that stuff compiled in and keep Netscape open for more than 2 mins.
.02
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
On your lunch hour, download the next full version release of your operating system (service packs are for sissys). Configure it, compile it, install it and be back working with no problems by the end of the hour. That's what I did.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
If you're an idiot like me and know your way around Linux, but still can't get the hang of that 'new fangeld' kernel recompile thing, Linux Newbie is running a wonderful little Newbiezed Help File on How to install the 2.4.0 kernel under Rad Hat 7. Great for people who aren't yet up to the skill of 'kernel hacker'.
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
> Why not just record straight to MP3 format ? you'd fit all that radio into less than 500 megs.
Because maybe you want better quality than mp3 can give?
dave
"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"
I'll add my ten-pence worth. In Outlook on NT (sorry) mailboxes can sometimes reach multiple Gigabytes in size; a real headache for the Server team. If Linux was to be used in a corporate environment ever, then this would have been a major shortcoming.
Smokey, this is not 'Nam, this is bowling. There are rules.
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.
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 of the kernel development list or the weekly Kernel Traffic summary.
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
SO, are there more people who feel that the most important advantage on servers would be iptables?
As far as using it as a server, 2.4 is FAST. Much faster than 2.2. Our SCSI RAID goes about 3x faster and NFS goes twice as fast (over gigabit ethernet).