Is there a hard drive out there that can even complete a write in 3ms?
Written linearly, most hard drives can complete a write in 3ms, averaged over multiple contiguous writes.
That's why database write ahead logs are on separate disks, written in linear fashion in large segments. Once in the log, a transaction is complete, and the data can be written asynchronously to the actual database table files when convenient.
As an example, given a not unreasonable sustained write performance to the log of 70MB/s, with an average transaction size of 70KB (including database overhead), that'd give you an average of 1ms per transaction. Now, 3ms is looking perfectly doable, especially throwing parallelism into the mix. Note, figures plucked straight out of my arse, but should not be too unrepresentative of actual work.
It surprises me how friends in the banking industry say how free of process their jobs are. If something is wrong, they just fix it (with electronic gaffer tape), no tickets, no process, no reviews, on the floor testing.
... so it's easy to see how someone might be lazy and just use whatever the vendor supplies.
Wow, I wouldn't want you managing my servers.
Home compiled software can easily be a source of security holes, as tracking what you have compiled versus what is patched using vendor updates adds significant management overhead and another point of failure. As an example, a popular open source project had its website compromised because the maintainer used a self compiled version of CVS, and forgot about it. Had the maintainer used a vendor CVS, the security hole would have been patched by the vendor update.
Lazy is good. If you can do the job and be lazy, that is a win-win.
I wonder what went wrong with the RH release?
The RH bugzilla ticket indicates this as the initial issue. http://rt.perl.org/rt3/Public/Bug/Display.html?id=34925
So it appears RH have not applied this fix, perhaps because the patch is included with a more cutting edge perl than is considered safe for inclusion with RHEL. Certainly, it looks like it was fixed in perl 5.9, but that may be an experimental branch more akin to the old 2.[135] linux kernels (and no vendor would have touched them in an enterprise targeted distribution.)
OTOH I bet it does reduce the memory bandwidth needed, which definitely is an advantage. Until the lack of registers causes spills to/from memory. Whoops.
Plucking figures form memory, x86 has an average instruction length of ~3.1 bytes for running code, whereas as RISC is generally 4 bytes. So, for a function that is 24 instructions long: - x86 = ~71 bytes - RISC = 96 bytes
Assuming the data IO overhead is the same, the x86 processor will be better off until it spills 3 registers to/from memory (3 out and 3 in), at which point it is losing out due to increased registermemory bandwidth. RISC does a much better job of keeping variables in registers.
This is for a short subroutine, which may be a simple "if this condition return this", but may also be a more complex iterative loop, which are common.
As the functions get bigger, more complex and/or loop more, so the gains from having register variables increase.
Not to mention that RISC can often perform the same functions in less instructions, as less register housekeeping is required. For the same reasons, Thumb and MIPS16 don't double code density of their respective architectures. There is just more overhead when working with limited registers.
The other big success is their constant work on making the entire system architecture better, and basically giving that work to the industry for free. PCI - USB - AGP - all directly driven by Intel. Driven by Intel to match the other architectures out there. Ie. catchup.
Remember, around the time of PCI, SUN had already designed, implemented and released SBUS to standards committees. It was simpler than PCI, though not as fast in burst mode (that could have been revved), and not crippled with legacy crap like PCI was.
And as for their processors, they were mostly crap until they got proper competition in the form of AMD, Cyrix et. al. The i486 and Pentium were hopelessly outclassed by their contemporary RISC competitors. P6 (from which Core was derived) is the only decent CPU architecture they've done.
that IBM got suspended or that IBM only earned 1.5 Billion dollars of the US business.
The government spends a fortune on IT, I can't imagine a company as large as IBM not having a bigger piece of the pie. Perhaps they don't pay Congress enough during elections?
My guess is that that is 1.5 Billion profit. Earnings are generally after expenses.
there was a study done recently which showed that the difference in attention payed to traffic between drivers that were using hands-free phones and hand-held phones negligible. In other words it really doesn't make that much difference whether you're using hands-free or not (except for the law off course)
Except with a hands free, you have both hands available, so you can accurately control the car and safely respond to safety issues. If you're holding a phone, driving becomes more erratic as you're trying to steer and change gear with one hand.
Sequential IO rate is most likely tied to the data density of the drive. So bigger disks generally have higher sequential IO rate, and enterprise drives (10K+) generally concentrate on the important performance factor, latency. Your hard disk spends most of it's time seeking between tracks and waiting for the correct sector(s) to spin under the head. Really, sequential IO is probably 5% of a drives performance characteristics, especially in a server environment.
I'll take a 10K RPM drive with 60% of the sequential IO rate of a 7K2 RPM drive any day.
There is really no such thing as RISC or CISC anymore. Even massive general purpose CPU's like the x86 family use cores that are basically RISC by the classical definition, at least at the microop level. Conversely, today's RISC processors have instruction sets that have grown considerably in complexity since the days of true RISC chips.
RISC is an instruction set thing, with the caveat that RISC instruction sets lend themselves to pipelined instruction execution as a by product.
Yes, modern x86 processors have RISC like microcode implemented using pipelined cores, but the x86 -> microcode converter is extra logic RISC processors just don't need.
There is no way you can implement an x86 chip in the same number of transistors as a RISC chip like ARM or MIPS, hence this VIA chip having considerably more power draw.
Cable, unlike DSL, is a shared medium. In other words, if some selfish jerk wants to trade torrents 24/7 and max the bandwidth then that can very well impact every other user on that line.
DSL is only point to point as far as the exchange. Beyond there, your onto shared DSLAMs with shared bandwidth upstream. So DSL is also a shared medium. That's what DSL contention is all about.
Does the license fee apply to monitors as well as TVs? You could just get a monitor (no tuner circuit, thus no capability of watching BBC) and use that to watch the DVDs.
The license fees cover receiving broadcast television.
Catalytic converters will not prevent black smoke if your engine is spent. Cats work mainly on NOx, Hydrocarbons and carbon monoxide, none of these are black smoke. Black smoke is generally soot, and would write off a catalytic converter in all likelihood.
Damages change with the circumstances. If you can't prove they knowingly violated your patents sometimes all you can win is an injuction and court costs.
An injuction, which would stop Intel selling their current processors. They would also have to negotiate a license for the past processors that violate the patent, which would result in considerable back pay.
As Intel would never consider stopping selling their processors, they are most likely to license the patent from Transmeta, which is much $$ for the volumes Intel shift.
The wilful aspect of infringing patents only affects the ability to award punitive damages. No wilful infringement, no punitive damages, but the license fee will still be there.
1. What really matters for a RAID implementation is Reliability, Size, cost and Speed. In that order.
2. SATA drives come close to SCSI drives in individual performance. Greater data densities help and lower spin rates hurt.
Spin rate is not a function of SATA or SCSI, as you know, so is moot. Most SCSI drives are still 10K RPM, so Raptor 10K SATA drives are of a similar performance, and considerably more expensive than regular SATA drives.
Latency dominates performance for most workloads other than pure streaming. Multi-user servers will be highly latency bound in throughput, so the higher the RPM the better. You just can't get 15K RPM SATA drives. But this is a price thing, not a SCSI vs. SATA thing.
For streaming workloads, performance bottlenecks are usually downstream anyway, so the raw sequential throughput of the disk or RAID array is unlikely to be limiting factor, making this largely a moot point as well.
3. So how dose a 7 disk RAID 5 arrays comprised of 300 GB SCSI drives compare to one made up of 500 GB or 750 GB SATA drives ?
Bottom line, if the SCSI drives have a higher spin rate, the array should be faster.
I understand that the probe gets faster when approaching an object with high gravity, such as Jupiter, however I don't know why it keeps the speed when leaving the gravitational field again. Where and how is the additional energy taken from?
The net gain in energy comes from the fact that the planet is not stationary, but moving. Were the planet stationary, then yes, there would be no net gain as the kinetic energy gained would be converted back to potential energy when leaving the gravitational field of the planet.
As the planet is moving, the vector of the force due to gravity changes also. When approaching the planet, the force is mostly in the direction of the probes velocity, thus speeding up the probe. As the probe flys by the planet, the planets movement along with the change in velocity of the probe means the force is not vectored against the probes velocity as much as it was vectored with it on approach, thus a net gain in speed. The energy itself is taken from the planet, which slows down ever so slightly.
Moreover I wonder how it slows down again so that the probe can successfully photograph pluto and does not do a very fast flyby.
I guess it won't slow down, and will just do a fast fly by and make what best use of that it can.
Split drives into small partitions, say 20-25 GB each. Since most drives available now are a multiple of 50GB, I suggest going with 25GB or 50GB per partition. Make software RAID devices out of sets of these partitions, one on each drive. e.g. md5 = sda5 + sdb5 + sdc5 + sdd5. Take all of those smaller RAID drives, and then LVM them together.
Technically, your multiple RAIDed partitions would not be RAIDs, because they are not independent devices. therefore, they would give no benefit being used as a RAID. And that LVM stuff sounds like it's just more overhead and another point of failure.
Each mdX is indeed redundant and can survive a single disk failure. In the scenario given before, you have md1, md2, md3 (using 50GB slices across 4 disks) and md4, md5 (using 50GB slices across 3 disks).
md1, md2 and md3 can survive a failure of any one of the four disks. md4 and md5 don't use or care about the 150GB drive, and can survive a failure of any one of the remaining 250GB drives.
That'll give 650GB of usable LVM storage, from 900GB of disk. Not bad.
(In fact Cutler could have made NT a full *nix Windows, as Microsoft owned Xenix at the time, and was willing to go with whatever the Cutler team decided would create the next great OS architecture.)
Microsoft had a contract with SCO that they specifically would NOT enter the UNIX market, in return for SCO supporting Xenix.
So MS couldn't do a full UNIX Windows even if they wanted to.
People can bitch about Windows and specfically Win32, but there is not a whole lof ot NT itself that is flawed or attackable in its design. It is still doing kernel and architectual concepts today that you cannot find any other consumer level OS. PERIOD.
What concepts?
I notice that OS such as Linux, *BSD, or any UNIX for that matter (expect, perhaps, MINIX:) can beat Windows in performance and resource usage on low end hardware. Linux and Solaris will have the legs of it at least on high end hardware. And the kernel is nothing without the user tools on top, and Windows must use Win32 for almost eveything. From what I've studied, it's not a radical kernel in any way.
...but would a turbo diesel configured as a hybrid make sense?).
Yup. Turbos increase efficiency, and anything that increases efficiency adds mileage. And as the engine would be designed to run at a single speed, you don't need to worry about such things as turbo lag.
Big (engine, not car), torquey turbo diesel hybrids, running on any fuel you have to hand (vegtable oil and the like) are the way of the future.
Slashdot Mirror
How the hell can you 'complete' a trade in 3 ms?
Is there a hard drive out there that can even complete a write in 3ms?
Written linearly, most hard drives can complete a write in 3ms, averaged over multiple contiguous writes.
That's why database write ahead logs are on separate disks, written in linear fashion in large segments. Once in the log, a transaction is complete, and the data can be written asynchronously to the actual database table files when convenient.
As an example, given a not unreasonable sustained write performance to the log of 70MB/s, with an average transaction size of 70KB (including database overhead), that'd give you an average of 1ms per transaction. Now, 3ms is looking perfectly doable, especially throwing parallelism into the mix. Note, figures plucked straight out of my arse, but should not be too unrepresentative of actual work.
It surprises me how friends in the banking industry say how free of process their jobs are. If something is wrong, they just fix it (with electronic gaffer tape), no tickets, no process, no reviews, on the floor testing.
Scary really.
... so it's easy to see how someone might be lazy and just use whatever the vendor supplies.
Wow, I wouldn't want you managing my servers.
Home compiled software can easily be a source of security holes, as tracking what you have compiled versus what is patched using vendor updates adds significant management overhead and another point of failure. As an example, a popular open source project had its website compromised because the maintainer used a self compiled version of CVS, and forgot about it. Had the maintainer used a vendor CVS, the security hole would have been patched by the vendor update.
Lazy is good. If you can do the job and be lazy, that is a win-win.
I wonder what went wrong with the RH release?
The RH bugzilla ticket indicates this as the initial issue.
http://rt.perl.org/rt3/Public/Bug/Display.html?id=34925
So it appears RH have not applied this fix, perhaps because the patch is included with a more cutting edge perl than is considered safe for inclusion with RHEL. Certainly, it looks like it was fixed in perl 5.9, but that may be an experimental branch more akin to the old 2.[135] linux kernels (and no vendor would have touched them in an enterprise targeted distribution.)
Plucking figures form memory, x86 has an average instruction length of ~3.1 bytes for running code, whereas as RISC is generally 4 bytes. So, for a function that is 24 instructions long:
- x86 = ~71 bytes
- RISC = 96 bytes
Assuming the data IO overhead is the same, the x86 processor will be better off until it spills 3 registers to/from memory (3 out and 3 in), at which point it is losing out due to increased registermemory bandwidth. RISC does a much better job of keeping variables in registers.
This is for a short subroutine, which may be a simple "if this condition return this", but may also be a more complex iterative loop, which are common.
As the functions get bigger, more complex and/or loop more, so the gains from having register variables increase.
Not to mention that RISC can often perform the same functions in less instructions, as less register housekeeping is required. For the same reasons, Thumb and MIPS16 don't double code density of their respective architectures. There is just more overhead when working with limited registers.
Remember, around the time of PCI, SUN had already designed, implemented and released SBUS to standards committees. It was simpler than PCI, though not as fast in burst mode (that could have been revved), and not crippled with legacy crap like PCI was.
And as for their processors, they were mostly crap until they got proper competition in the form of AMD, Cyrix et. al. The i486 and Pentium were hopelessly outclassed by their contemporary RISC competitors. P6 (from which Core was derived) is the only decent CPU architecture they've done.
My guess is that that is 1.5 Billion profit. Earnings are generally after expenses.
Except with a hands free, you have both hands available, so you can accurately control the car and safely respond to safety issues. If you're holding a phone, driving becomes more erratic as you're trying to steer and change gear with one hand.
My sinclair spectrum of 25 years ago had multiple shift keys. Prior art if ever I saw it.
Sequential IO rate is most likely tied to the data density of the drive. So bigger disks generally have higher sequential IO rate, and enterprise drives (10K+) generally concentrate on the important performance factor, latency. Your hard disk spends most of it's time seeking between tracks and waiting for the correct sector(s) to spin under the head. Really, sequential IO is probably 5% of a drives performance characteristics, especially in a server environment.
I'll take a 10K RPM drive with 60% of the sequential IO rate of a 7K2 RPM drive any day.
RISC is an instruction set thing, with the caveat that RISC instruction sets lend themselves to pipelined instruction execution as a by product.
Yes, modern x86 processors have RISC like microcode implemented using pipelined cores, but the x86 -> microcode converter is extra logic RISC processors just don't need.
There is no way you can implement an x86 chip in the same number of transistors as a RISC chip like ARM or MIPS, hence this VIA chip having considerably more power draw.
DSL is only point to point as far as the exchange. Beyond there, your onto shared DSLAMs with shared bandwidth upstream. So DSL is also a shared medium. That's what DSL contention is all about.
The license fees cover receiving broadcast television.
http://www.tvlicensing.co.uk/information/index.js
Notably, playing a DVD through a regular TV appears to NOT require a license.
Lots of people are harping on about GPL conditions etc. This software is not licensed under the GPL! Check the software's license.
Catalytic converters will not prevent black smoke if your engine is spent. Cats work mainly on NOx, Hydrocarbons and carbon monoxide, none of these are black smoke. Black smoke is generally soot, and would write off a catalytic converter in all likelihood.
An injuction, which would stop Intel selling their current processors. They would also have to negotiate a license for the past processors that violate the patent, which would result in considerable back pay.
As Intel would never consider stopping selling their processors, they are most likely to license the patent from Transmeta, which is much $$ for the volumes Intel shift.
The wilful aspect of infringing patents only affects the ability to award punitive damages. No wilful infringement, no punitive damages, but the license fee will still be there.
Spin rate is not a function of SATA or SCSI, as you know, so is moot. Most SCSI drives are still 10K RPM, so Raptor 10K SATA drives are of a similar performance, and considerably more expensive than regular SATA drives.
Latency dominates performance for most workloads other than pure streaming. Multi-user servers will be highly latency bound in throughput, so the higher the RPM the better. You just can't get 15K RPM SATA drives. But this is a price thing, not a SCSI vs. SATA thing.
For streaming workloads, performance bottlenecks are usually downstream anyway, so the raw sequential throughput of the disk or RAID array is unlikely to be limiting factor, making this largely a moot point as well.
Bottom line, if the SCSI drives have a higher spin rate, the array should be faster.
The net gain in energy comes from the fact that the planet is not stationary, but moving. Were the planet stationary, then yes, there would be no net gain as the kinetic energy gained would be converted back to potential energy when leaving the gravitational field of the planet.
As the planet is moving, the vector of the force due to gravity changes also. When approaching the planet, the force is mostly in the direction of the probes velocity, thus speeding up the probe. As the probe flys by the planet, the planets movement along with the change in velocity of the probe means the force is not vectored against the probes velocity as much as it was vectored with it on approach, thus a net gain in speed. The energy itself is taken from the planet, which slows down ever so slightly.
I guess it won't slow down, and will just do a fast fly by and make what best use of that it can.
Each mdX is indeed redundant and can survive a single disk failure. In the scenario given before, you have md1, md2, md3 (using 50GB slices across 4 disks) and md4, md5 (using 50GB slices across 3 disks).
md1, md2 and md3 can survive a failure of any one of the four disks. md4 and md5 don't use or care about the 150GB drive, and can survive a failure of any one of the remaining 250GB drives.
That'll give 650GB of usable LVM storage, from 900GB of disk. Not bad.
Microsoft had a contract with SCO that they specifically would NOT enter the UNIX market, in return for SCO supporting Xenix.
So MS couldn't do a full UNIX Windows even if they wanted to.
What concepts?
I notice that OS such as Linux, *BSD, or any UNIX for that matter (expect, perhaps, MINIX:) can beat Windows in performance and resource usage on low end hardware. Linux and Solaris will have the legs of it at least on high end hardware. And the kernel is nothing without the user tools on top, and Windows must use Win32 for almost eveything. From what I've studied, it's not a radical kernel in any way.
On Unix, you can replace an in-use file, so you do.
Not necessarily true. HP-UX can't remove or even move a binary in use.
But then, I'm sure HP-SUX is based on V7 UNIX anyway. (Not really, but the kernel is really old vintage with modern bolt ons.)
Flexibility? Cheaper infrastructure? The economics of trains has little to do with fuel prices.
Yup. Turbos increase efficiency, and anything that increases efficiency adds mileage. And as the engine would be designed to run at a single speed, you don't need to worry about such things as turbo lag.
Big (engine, not car), torquey turbo diesel hybrids, running on any fuel you have to hand (vegtable oil and the like) are the way of the future.
When we walk, we are about the second most ineffecient animal WRT energy consumption.
So, all the better for working off those burgers, then:)
This will also never happen because it would make driving in heavy traffic or hilly areas (or both!) next to impossible.
Eh? The rest of the world manages it. It's not that hard.
How about no private contributions at all.
In the UK, it's the parties that are funded, not the politicians, and people contribute to the parties who then run the election campaigns.
This way, anyone (not just the rich) can run for election provided they get the backing of their party.
It also doesn't stop independents, who can fund their own campaign if they are not affiliated with any particular party.
Reduces the scope for conflicts of interest.