The CPU's could be in an bloacked IO stage simply asking in a loop: Is it ready yet?, Is it ready yet? ...

In Linux watch top and not the amount of time CPUs have allocated to '%wa' That accounts partly for IO blocked processes. So a CPU can be at 0% idle and still doing nothing effective, just simply trying to write tot he disk that is too busy to accept the data.

That polling is not processor intensive. So adding cores will not help much except to reduce cache misses due to task swapping. But even there that only works if the OS is smart enough to prevent unnecessary process/CPU migration.

This may sound silly but we do something like this. On performance critical systems, we have one or two 'OS' and communication dedicated processors and then we use the rest (up to 14 more for 16 total) for the actual data crunching.

Those off-CPU processors may exist but if they bind up, your main processors trying to read or write IO will go into wait states until the IO unbinds. having your data process unbind data crunching from IO helps quite a bit to smooth out the IO spikes that exceed instantaneous IO throughput capabilities.

Skip RAID6 and move straight to RAID10. Maintaining redundancy internally, it is as fast as it gets with optimal RAID hardware. And it does scale as more drives are added to the stripe(s) up to the maximum performance of the RAID controller chip and PCI(e) throughput.

The problem with bigger RAM and more battery is that if you have sustained IO that exceeds your write performance, your buffer no matter how large is eventually going to fill and either bind or drop data.

More RAM simply allows you to handle larger IO spikes. Sustained performance is an entirely different animal. Only real IO performance helps there.

I n my environment we have to deal with spikes and high baseline sustained throughput.

Even if you 'offload' IO, there is the problem that many programs are still blocked until the IO is completed. Watch top when you system is bogged down and see how much time each processor loses to '%wa'. That represents not how much time is spent by that CPU on IO, but how much time is lost to waiting on IO (is it ready yet?, is it ready yet?...).

I also work in an environment developing massive computing embedded systems all based on x86/x86_64. Our smaller systems start with four cores and we currently ship up to 16 although we have a 24 core x86/x86_64 system in house for testing.

We run into pure processing limits in some cases and in other IO throughput (using high performance PCIe based Areca RAID cards in RAID10 configuration). For absolute performance IO throughput we are looking at Violin-Memory systems which implement storage as an external device that is attached via PCIe. The increased throughput is astounding (up to 5x increased insert record rate into a database over a internally hosted PCIe connected RAID10). Yes the Violins are not cheap, but customers that need that kind of throughput will pay the price for it.

RAID5 is ultimately a net performance loss over RAID1 and even a single disk. Simple RAID1 mirroring provides better throughput (single disk write performance, split disk read performance is the RAID1's read algorithm is implemented correctly (on Adaptec's cheaper stuff it appears not as an example; all on-board assisted softRAIDs I have tested do not optimize on the RAID1 and RAID0 performance, however Linux softRAID (md) does). Add striping to the mirror and you get boosted write performance on a RAID system that implements the write algorithm correctly.

RAID10 (2n disks) will of course increase your storage costs over RAID5 (n+1 disks) because you need twice as many disks as the space you want to offer for storage. But the performance gain will justify the costs if you are truly IO limited.

Has it occurred to anyone that you are used to the vibration as a form of feedback. Additionally you associate certain vibrational sensations with certain speeds and conditions.

Chances are that your older perception of speed and control may not co-inside with a younger person's perception who has not driven older vehicles?

Even more, take a simple test, drive at 65MPH for a long distance, then drive at 85MPH for a long distance, then go back to 65. It will not feel as fast as 65 did the first time. Why? because your perception of 'regular' speed has adjusted for handling 85MPH.

Perception is simply natural comparison allowing you to compare relative events and experiences. Driving around a tight corner at high speed when you first learned to drive felt risky because your perception has been against not driving fast around corners. Once you force yourself to accept that that speed at that radius is safe, then you get more comfortable and your baseline perception adjusts.

Therefore I argue, you just need to learn how to feel your new vehicle. And face it, newer vehicles do corner better (sway bars, suspension, tires, etc...) and hold the road much better so the fact that your perception allows you to feel as safe at faster speeds is an accurate adjustment.

The poster and the article title also leap to a conclusion not supported by the article itself. The main thesis of the article, the Peltzman effect (as defined in the article) indicates a relatively even trade, not a tilt towards less safety. You are simply trading one set of issues for a different set. Bad road grip for inattentive driving for example. Both can be equally unsafe.

Has anyone else notice the coincidental (?!) connection in sound and appearance of "EULA" and "eulogy"?

From Wikipedia: A eulogy is a speech or writing in praise of a person or thing, especially one recently deceased or retired.

So a EULA would then be a death speech for the software or device for which it is written. ...We think this is great software, but now due to this EULA, it's dead (or at least we are going to make it that way)...

Working for salary should not imply working 'free' hours. Being paid salary means you get paid to do a job, not just to be present. Now there are *many* companies that abuse the concept of salary pay to get free over time, but that does not mean all of them do it nor that you should put up with it. I work for a company that at times makes large demands of my time with occasional trips out of town (effectively all of my time is eaten). But on the same token, when the big push is over, no one cares if you show up a bit late or leave a bit early (yes it does happen). I am really lucky in that during (youth) baseball season, my work overlooks all the time I am present, but dealing with baseball matters, parents, coaches, umpires, scheduling, lineups (I coach in addition to working on the board) and various board matters. Not to mention the times I leave very early to prepare for and coach or umpire games.

So long as I delver on time and am around so proper communication can occur, no one complains. If I miss my deadlines, then I either need to spend more time per day to get the job done or need to give better estimates and set reasonable expectations. My schedule is not much less flexible than 1099 development work have done full time in the past. Customer needs dictated much of that work occurred at specific times and I still had schedules and expectations to make. Not to mention that you generally do not work 1099 jobs for 'as long as it takes' (yes some contracts are open-ended). Customers expect much like my current job, that I can gather the necessary information to make accurate time estimates and thus make reliable cost estimates which are negotiated up front. I then give a price for the *job*. Chances are if you underestimate the time it takes you to write a contact application, that you 'eat' the extra hours. If you are smart, you do not allow much in the way change orders without additional payment and time being added. If you have open ended development work, then you either are very good at negotiation or have a very dumb customer (I have seen this too, and happy to comply of they are that stupid).

Working 1099 is much like working mini salary jobs. You get to negotiate your salary more often depending on the length and number of 'jobs' or contracts.

Now you may be working a support type contract in which you get paid for number of 'base' hours with an open-ended agreement for extra paid hours as-needed, but then you have to live with the times when you are not needed and get the minimum hour payments. You DO make them pay for a base amount of hours even if not used, right? That's how they get to pay you $100/hr instead of $120 those months they needed you for five times the base number of hours. Yes you are not working 'free' hours but then you may not get many hours at all. Now if you are smart, you have many of these contacts and total of all the base hours is at least the needed income to get by comfortably but not so many hours that you have no free time, otherwise, what is the point, right?

Yes and TMI is also a success story. By use of the designed and built-in multiple layers of control and safety procedures, both automatic and human manipulated, the situation was CONTAINED.

A full blown accident happened and were it not for them (the power company per NRC requirement) telling you about it, you would have NEVER known. You would have been unable to externally determine there was any issue other than the total facility maximum output reduced by one third.

The only (non-reactor) damage was the (most likely) hanging by the balls of personnel that allowed a very expensive reactor core to melt.

Let's keep the examples in the proper perspective and ponder the actual continual radiological release occurring at every single coal burning plant in the world.

Or they could see that with a MS, you are likely to start looking for a better position (not entry or even second level programmer) as soon as the economy improves. Companies do not like to hire 'known' transient people for permanent positions. They want to be able to hire and forget. Think of it as the overqualified complex.