$330 ata raid controller has an onboard risc processor and slots for SDRAM.
do you think the cpu in that card is fastest than the one on your mobo? some raid controllers have battery backed ram, which is a plus (though a large ups in front of the whole system is about as good).
For $330 you get native raid 5 support and the peace of mind
knowing when your OS fails, the raid array maintains it's integrity.
i didn't mean to imply that true hardware raid controllers aren't worth it. they are, in some cases. it's the fake ata raid software driver based cards that aren't worth it.
Tell me what
software rendering looks like in comparison to a GeForce 3 Ti. I'll take my RAID in hardware, Thank you.
that is not an argument for hardware raid. hardware raid cards use slow cpus. graphics cards use custom asics that are much faster (as you state) at certain tasks than a general cpu.
there is nothing wrong with backing up to another hd. i did it for years. it has many advantages, the main one being cost. also, those of you considering raid 1 or 5, think what happens when you rm -rf/. real time redundency gives you no ability to restore previous versions.
Just think what happens when the source
disk fails in the middle of the nightly backup. You have a failed source disk. And a half-baked backup disk.
why in the world would you spend $330 on an ata raid controller when you can use software raid for free? it's probably faster, too.
btw, some of those ata raid controllers are nothing more than normal ata controllers, they just use software raid drivers (patched into the x86 bios calls, i believe).
VLIW let's a compiler pack multiple commands to multiple execution units into a single long word.
The idea is to use very RISCy commands to keep a superscalar set of execution units more fully utilized.
Great idea, if your compiler can do it.
there's next to no advantage to using vliw in modern cpus. all it does is make instruction to exec unit assignment simpler. everything that a vliw cpu gains from a good compiler a risc cpu will also gain. it's just that vliw is extremely ineffiencent without a very good compiler.
No shit your US3 is 64bit and the Intel P machines are 32bit. RISC vs. CISC is not giving the biggest
performance boost the 64bit architecture is.
uh, more bits doesn't mean a faster cpu. in fact, it means pointers are twice as long, which means they take up twice the cache and twice the memory bandwidth. the fact that most 64bit cpus are faster than more 32bit cpus has absolutely nothing to do with them being 64bit.
ultrasparc III is a dud. it's performance is lacking, to say the least. i have never heard of any drive containing sun firmware and i don't know why one would. just cuz it's branded as a sun drive (like quantums have been branded as apple and dec drives), doesn't mean sun wrote it's firmware. the reason sun hardware is so expensive is cuz people are willing to pay that much (though, who knows why that is).
what about the fact that ia-64 SUCKS? compaq publishes papers about how superior alpha is, then turns right around and standardizes on ia-64! i thought it was sad when compaq bought dec and when sgi dropped mips, but this is by far the worst. intel has now bought out the superior competetion and will force another of their idiotic architectures on the world. once again, marketing and momentum win over superior design and preformance.
i think it'll be interesting to see if customers attempt to sue compaq, since they've been claiming a 20-25 year life span for alpha.
the BS about dsl not being shared is phone company propaganda. do you really think they don't over subscribe users? *every* internet connection shares bandwidth somewhere along the line. the only difference is with dsl it's a hop or two further upstream.
A good example of this is the MIPS
processor - everyone and their mom implements it differently. I remember attending a talk from the woman
who implemented the memory management system for VxWorks and hearing they had some amazingly huge
number of different implementations and feature set definitions for MIPS processors.
the reason there are so many mips implimentations is cuz companies license soft cores that people redesign.
Well duh, no shit the more work you offload to hardware the faster the machine becomes.
that's not always true. TLB loading is faster in software (running on general purpose circuits) than dedicated handware.
If you
really think about it, the whole idea of an OS is a little absurd. In fact, it wasn't untill computers actually
became "powerfull" was it even considered reasonable to let some middle-layer software (an OS) do the
work of dedicated hardware.
what hardware ever took the place of an OS? sounds like you'd prefer a dos-like program loader over an OS.
It is important to note that those three systems are monolithic systems running on top of a Mach
microkernel. Mach has not, in any of those cases, been modified to the extent that it no longer functions as
a true microkernel.
yes, but the whole point of a microkernel is to have a different fault domain for each subsystem (and to use message passing ipc between them). using a single server completely defeats that.
For example, take the fact that OSF/1 based systems use Mach message passing and VM, so they can
handle such fun concepts as reserve-on-write memory allocation with message-callbacks on failure. In
UNIX terms, that means that "malloc(1024*1024*1024)" does not reduce the amount of VM available...
which is both scary and useful at the same time;-)
linux and most other unix-like OSes (with notable exception of solaris) over commit memory as well. this is nothing new. recently people have complained about the inability to completely disable it in linux.
The proliferation of copy-on-write semantics in Mach-derived systems is also very useful, and again benefits
greatly from the way mach does message-passing instead just having signals to convey information from the
kernel to user space.
copy on write and signals have nothing to do with each other. also, message passing ipc is more expensive than just invoking a user space signal handler. message passing between user space and kernel space is pretty much useless, unless you want to export kernel interfaces (eg, vm pager, fs) directly to user space.
If mach is, indeed, a bad implementation of the microkernel, what would be a *good* implementation of the microkernel?
L4
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the
statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done
wrong in Mach, and can it be fixed?
search the l-k list archives for some examples. one point is that only one thread at a time can be in any module, as a result of messages being queued. mach is much slower than other microkernels when it comes to message passing. another issue is that when you shove use a monolithic unix server (eg, as do mklinux, bsd lites, next), you lose all the advantage of using a microkernel in the first place. if your single server dies, everthing's shot anyway. also, message passing is not the only way to isolate fault domains. (see here.)
i don't believe that message passing really gains you much abstration. if you had all the vm calls/messages placed in a generic way, it wouldn't let you optimize for the specific pager implementation. but, to allow an easy drop in replacement, you wouldn't be able to depend on the current vm's subtle behaviors. this is just my thought; i haven't exactly done a lot of kernel design, so take that with a grain of salt.
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that
Mach has the ability to host multiple kernels on the same machine at the same time. Is this true?
yes, it's definetly true. i know the mklinux server has been debugged using another running instance of the linux server. people have often talked about run time switching between mac os x and mklinux, but nothing's come of it. and to be safe, it would need some resource locking, eg, so that you don't have the two servers writing to the same disk partition.
afaik, the RFCs only say you can't route *to* 10. *from* is ok. do a traceroute to erol's dialups. you'll see that their side of the ppp link has a 10.
that is precisely way pgp and gpg use a symmetric cipher to encrypt your secret key. secret keys are too long to remember, so they have to be stored electronically and encrypted with a shorter key that can be remembered.
for those thinking "what if they break the symmetric cypher used to encrypt the asymmetric secret key?": you'd be screwed anyway. when you use gpg or pgp, it generates a random symmetric key to encrypt the message with, then uses rsa or el gamal and the public key to encrypt the symmetric key.
I've heard this from people before. Maybe it's just me, but I don't beleive them when they say this. Could
Slashdot readers reply to this and tell me if they can tell the difference between MP3s and CDs?
i can definetly hear the difference. it's most noticable in the higher freqs, in my experience. i've only heard one encoder, so others may do a better job. distorted guitar just doesn't sound right - the harmonics are all screwed up. i'd say it's about the quality of FM radio, when you have somewhat poor reception or a little interference.
test it yourself. mp3 encode a song and have a friend give you a blind a/b test between the mp3 and the cd version.
why would you want to pay for the bandwidth to download a song, everytime you want to listen to it, instead of recording it to media or buying the media pre-recorded?
also, mp3s (a standard stream format) do not sound as good as cd audio. hopefully, in the future, we'll have higher res audio (24bit 50khz, > 2 channels), not effectively lower rez (mp3).
Re:Has anyone actually measured the clock rate ofC
on
Clockless Computing?
·
· Score: 1
I know 'certain chip manufacturers' put in extra pipeline stages which increase the clock rate of the chip but
actually degrade performance
yes, it may reduce the number of ops per clock, but it more than makes up for that by allowing a much higher clocking.
there's no problem. busy wait loop delays are calculated at boot time. just cuz you don't have a distributed clock, doesn't mean the instructions aren't complete at regular intervals.
the only thing useful applications of solid state drives i can think of are:
1) doesn't require backing store, like main memory does
2) can use slower (cheaper) dram than main memory, since the bus is the bottleneck
3) if you're out of dimm slots, it could be useful to use as a swap device
4) as an fs journal device
unless they can sell these SS drives for less than the same capacity dimms, there's not going to be much of a market.
also, the article is wrong about pci. 64bit 33mhz and 32bit 66mhz pci slots have been available for quite a while.
Slashdot Mirror
believe it or not, telnet is useful for a lot more than just remote logins (which it is least useful for).
56 "k" modems are 56 kiloBITS, not bytes. and 128kbits is 16kbytes not 56. obviously you DIDN'T do the math! 8)
one word: dependencies
do you think the cpu in that card is fastest than the one on your mobo? some raid controllers have battery backed ram, which is a plus (though a large ups in front of the whole system is about as good).
For $330 you get native raid 5 support and the peace of mind knowing when your OS fails, the raid array maintains it's integrity.
i didn't mean to imply that true hardware raid controllers aren't worth it. they are, in some cases. it's the fake ata raid software driver based cards that aren't worth it.
Tell me what software rendering looks like in comparison to a GeForce 3 Ti. I'll take my RAID in hardware, Thank you.
that is not an argument for hardware raid. hardware raid cards use slow cpus. graphics cards use custom asics that are much faster (as you state) at certain tasks than a general cpu.
Just think what happens when the source disk fails in the middle of the nightly backup. You have a failed source disk. And a half-baked backup disk.
ever hear of incremental backups?
why in the world would you spend $330 on an ata raid controller when you can use software raid for free? it's probably faster, too.
btw, some of those ata raid controllers are nothing more than normal ata controllers, they just use software raid drivers (patched into the x86 bios calls, i believe).
there's next to no advantage to using vliw in modern cpus. all it does is make instruction to exec unit assignment simpler. everything that a vliw cpu gains from a good compiler a risc cpu will also gain. it's just that vliw is extremely ineffiencent without a very good compiler.
uh, more bits doesn't mean a faster cpu. in fact, it means pointers are twice as long, which means they take up twice the cache and twice the memory bandwidth. the fact that most 64bit cpus are faster than more 32bit cpus has absolutely nothing to do with them being 64bit.
ultrasparc III is a dud. it's performance is lacking, to say the least. i have never heard of any drive containing sun firmware and i don't know why one would. just cuz it's branded as a sun drive (like quantums have been branded as apple and dec drives), doesn't mean sun wrote it's firmware. the reason sun hardware is so expensive is cuz people are willing to pay that much (though, who knows why that is).
EPIC stands for explicitly paralle instruction computing. in other words, low performance. it can't re-order around cache misses.
what about the fact that ia-64 SUCKS? compaq publishes papers about how superior alpha is, then turns right around and standardizes on ia-64! i thought it was sad when compaq bought dec and when sgi dropped mips, but this is by far the worst. intel has now bought out the superior competetion and will force another of their idiotic architectures on the world. once again, marketing and momentum win over superior design and preformance.
i think it'll be interesting to see if customers attempt to sue compaq, since they've been claiming a 20-25 year life span for alpha.
the BS about dsl not being shared is phone company propaganda. do you really think they don't over subscribe users? *every* internet connection shares bandwidth somewhere along the line. the only difference is with dsl it's a hop or two further upstream.
the reason there are so many mips implimentations is cuz companies license soft cores that people redesign.
the only things that deal with register allocation are gcc and the asm macros in the kernel.
that's not always true. TLB loading is faster in software (running on general purpose circuits) than dedicated handware.
If you really think about it, the whole idea of an OS is a little absurd. In fact, it wasn't untill computers actually became "powerfull" was it even considered reasonable to let some middle-layer software (an OS) do the work of dedicated hardware.
what hardware ever took the place of an OS? sounds like you'd prefer a dos-like program loader over an OS.
yes, but the whole point of a microkernel is to have a different fault domain for each subsystem (and to use message passing ipc between them). using a single server completely defeats that.
For example, take the fact that OSF/1 based systems use Mach message passing and VM, so they can handle such fun concepts as reserve-on-write memory allocation with message-callbacks on failure. In UNIX terms, that means that "malloc(1024*1024*1024)" does not reduce the amount of VM available... which is both scary and useful at the same time ;-)
linux and most other unix-like OSes (with notable exception of solaris) over commit memory as well. this is nothing new. recently people have complained about the inability to completely disable it in linux.
The proliferation of copy-on-write semantics in Mach-derived systems is also very useful, and again benefits greatly from the way mach does message-passing instead just having signals to convey information from the kernel to user space.
copy on write and signals have nothing to do with each other. also, message passing ipc is more expensive than just invoking a user space signal handler. message passing between user space and kernel space is pretty much useless, unless you want to export kernel interfaces (eg, vm pager, fs) directly to user space.
L4
Will someone please attempt to assert or refute, using some kind of solid logic or numbers or something, the statement that microkernels are a good idea but Mach is a bad implementation of that idea? What is done wrong in Mach, and can it be fixed?
search the l-k list archives for some examples. one point is that only one thread at a time can be in any module, as a result of messages being queued. mach is much slower than other microkernels when it comes to message passing. another issue is that when you shove use a monolithic unix server (eg, as do mklinux, bsd lites, next), you lose all the advantage of using a microkernel in the first place. if your single server dies, everthing's shot anyway. also, message passing is not the only way to isolate fault domains. (see here.)
i don't believe that message passing really gains you much abstration. if you had all the vm calls/messages placed in a generic way, it wouldn't let you optimize for the specific pager implementation. but, to allow an easy drop in replacement, you wouldn't be able to depend on the current vm's subtle behaviors. this is just my thought; i haven't exactly done a lot of kernel design, so take that with a grain of salt.
and, btw, this is kind offtopic, but while we're VAGUELY near the subject: someone once told me that Mach has the ability to host multiple kernels on the same machine at the same time. Is this true?
yes, it's definetly true. i know the mklinux server has been debugged using another running instance of the linux server. people have often talked about run time switching between mac os x and mklinux, but nothing's come of it. and to be safe, it would need some resource locking, eg, so that you don't have the two servers writing to the same disk partition.
afaik, the RFCs only say you can't route *to* 10. *from* is ok. do a traceroute to erol's dialups. you'll see that their side of the ppp link has a 10.
that is precisely way pgp and gpg use a symmetric cipher to encrypt your secret key. secret keys are too long to remember, so they have to be stored electronically and encrypted with a shorter key that can be remembered.
for those thinking "what if they break the symmetric cypher used to encrypt the asymmetric secret key?": you'd be screwed anyway. when you use gpg or pgp, it generates a random symmetric key to encrypt the message with, then uses rsa or el gamal and the public key to encrypt the symmetric key.
i can definetly hear the difference. it's most noticable in the higher freqs, in my experience. i've only heard one encoder, so others may do a better job. distorted guitar just doesn't sound right - the harmonics are all screwed up. i'd say it's about the quality of FM radio, when you have somewhat poor reception or a little interference.
test it yourself. mp3 encode a song and have a friend give you a blind a/b test between the mp3 and the cd version.
why would you want to pay for the bandwidth to download a song, everytime you want to listen to it, instead of recording it to media or buying the media pre-recorded?
also, mp3s (a standard stream format) do not sound as good as cd audio. hopefully, in the future, we'll have higher res audio (24bit 50khz, > 2 channels), not effectively lower rez (mp3).
yes, it may reduce the number of ops per clock, but it more than makes up for that by allowing a much higher clocking.
there's no problem. busy wait loop delays are calculated at boot time. just cuz you don't have a distributed clock, doesn't mean the instructions aren't complete at regular intervals.
huh? arch endianess has NOTHING to do with patches being rejected. that doesn't even make sense.
the only thing useful applications of solid state drives i can think of are:
1) doesn't require backing store, like main memory does
2) can use slower (cheaper) dram than main memory, since the bus is the bottleneck
3) if you're out of dimm slots, it could be useful to use as a swap device
4) as an fs journal device
unless they can sell these SS drives for less than the same capacity dimms, there's not going to be much of a market.
also, the article is wrong about pci. 64bit 33mhz and 32bit 66mhz pci slots have been available for quite a while.