as any selective college will be reading essays you wrote themselves.

Ha, I know someone who sells college admission essay help.... Basically, give them some money, your essay gets corrected/rewritten.

Its nice to have money..

I was pretty shocked too, I didn't know you could get in anywhere with under 700. Christ, those have to be athletes because a 700 on the SAT is like 6th grade education.

It doesn't say what percentage of the students getting aid are under 700. Even so, how does one function in college if you don't have a grasp of algebra or any kind of reading comprehension?

The "slow interconnect" you're talking about to main memory, PCI Express v3.0 has an effective bandwidth of 32GB/s which actually exceeds the best main memory bandwidth you'd get out of an Ivy Bridge CPU with very fast memory, so no, that's not a bottleneck for bandwidth, though yes, there is some latency there.

Its both, for my application, the GPU is roughly 3x-5x as fast as a high end CPU. This is fairly common on a lot of GPGPU workloads. The GPU provides a decent but not huge performance advantage.

But, we don't use the GPU! Why not? Because copying the data over the PCIe link, waiting for the GPU to complete the task, and then copying the data back over the PCI bus yields a net performance loss over just doing it on the CPU.

In theory, a GPU sharing the memory subsystem with the CPU avoids this copy latency. Nor does it preclude still having a parallel memory subsystem dedicated for local accesses on the GPU. That is the "nice" thing about opencl/CUDA the programmer can control the memory subsystems at a very fine level.

Whether or not AMD's solution helps our application remains to be seen. Even if it doesn't its possible it helps some portion of the GPGPU community.

BTW:
In our situation its a server system so it has more memory bandwidth than your average desktop. On the other hand, i've never seen a GPU pull more than small percentage of the memory bandwidth over the PCIe links doing copies. Nvidia ships a raw copy benchmark with the CUDA SDK, try it on your machines the results (theoretical vs reality) might surprise you.

Without sounding like too much of a jerk, I have hundreds of commits in the linux-2.6 fs/* tree. This is what I do for a living.

Well, then your part of the problem. Your idea that you have to be correct or fast is sadly sort of wrong. Its possible to be correct without completely destroying performance. I have a few commits in the kernel as well mostly to fix completely broken behavior (my day job in the past was working on an enterprise unix). So, I do understand filesystems too. Lately, my job has been to replace all that garbage, from the scsi midlayer up, so that a small industry specific "application" can both make guarantees about the data being written to disk while still maintaining many GB/sec of IO. The result, actually makes the whole stack look really bad.

So, I'm sure your aware that on linux, if you use proper posix semantics (fsync() and friends) the performance is abysmal compared to the alternatives. This is mostly because of the "broken" fencing behavior (which has recently gotten better but still is far from perfect) in the block layer. Our changes depend on 8-10 year old features available in SCSI to make the guarantees that aren't available everywhere. But it penalizes devices which don't support modern tagging, ordering and fencing semantics rather than ones that do.

Generally in linux, application developers are stuck either dealing with orders of magnitude performance loss, or they have to play games in an attempt to second guess the filesystem. Neither is a good compromise and its sort of shameful.

Maybe its time to admit linux needs a filesystem that doesn't force people to choose either abysmal performance, or no guarantees about integrity.

99% of software doesn't need to call fsync() on a sanely designed filesystem.

Really? please, show me the part of POSIX which says the data you wrote has now been flushed to the medium and you can respond with 100% certainty, to the user, or API making a request that if power fails this transaction will be safe.

Well, if linux is a toy (your basic argument) then why are all the subsystem maintainers paid by large companies a salary same as the developers at Microsoft, or any other OS company?

My point doesn't preclude people showing up and writing the next great filesystem. Its simply a question of why everyone thinks its a good idea for a guy PAID to maintain a filesystem to drop it and go write another one. If you worked for _BIG_ company and were paid to maintain their application, and you decided one day that maintaining their application was a PITA cause it was old crufty and not sexy anymore and instead refused to fix problems in it, rather spending the next 4 years writing a replacement (complete with another set of bugs) how long do you think your job would last?

Of course, this stuff happens in a lot of software projects, new developer shows up, and writes buggy new system cause they think they are smarter than the last guy. It frankly speaks of immaturity and an "artist" mentality rather than an engineering process. Sure, software isn't all engineering but linux is an OS, its a fundamental part of a computing platform and one that is expected to provide some basic level of service to applications (you know the things actually doing the work). When it fails at that, because its a patchwork of art, then you have to question why.

Ext3 is still chugging along and doing what you want. A filesystem that sacrifices everything for stability.

EXT3, is actually fairly good, and the performance isn't bad _EXCEPT_ for one issue. fsync(), which causes a massive IO barrier against all the other operations in the filesystem. fsync() should only be assuring the named file is consistent, and yet it basically stalls the entire FS to assure that one file. Its a problem with lack of proper IO tagging and actually is a fundamental problem with the block layer in linux. A recent LSML posting about SYNCHRONIZE CACHE hints at the problem too (complete device flush when only a small portion of the IO needs to be flushed).

No, that's FUD and/or misunderstanding on your part.

"data=ordered" is ext3/4's name for "don't expose stale data on a crash," something which XFS has never done,

Actually, I think your the one that doesn't understand how a journaling file system works. The problem with XFS has been that it only journals meta data, and the data portions associated with the metadata are not synchronized with the metadata updates (delayed allocation an all that). This means the metadata portions (filename, sizes, etc) will be correct based on the last journal update flushed to media, but the data referenced by that meta-data may not be.

A filesystem that is either ordering its meta data/data updates against a disk with proper barriers, or journing the data alongside the meta data doesn't have this problem. The filesystem _AND_ its data remain in a consistent state.

So, until your understand this basic idea, don't go claiming you know _ANYTHING_ about filesystems.

That will probably get 95% done before the next cool kid on the block takes over.

Filesystems on linux never seem to be 100% done. By that I mean, they are bulletproof and reasonably fast.

Just think, if instead of having dozens of primary fileystems (ext[2,3,4], reiserfs, ocfs, ocfs2, xfs, jfs. gfs2, zfs) over the last 15 years, someone had actually spent the time and designed/researched a general purpose filesystem, implemented and slogged through all the issues on one of them. Linux might have a good filesystem. The ext2/3 combination appeared to be on that path, but instead of fixing the fsync problems, and a couple other issues, it was basically abandoned in favor of ext4 which while maintaining the ability to mount ext3, and is named the same could have just been called "we took some bad ideas from XFS for performance reasons and now we have the same data integrity problems".

Your happy with XFS because your machine has never lost power or crashed. If either of those things happened with the older versions of XFS it was nearly a 100% guarantee you would lose data. Now i'm told its more reliable.

So, if you told me you have been running it for the last year and it was reliable I would have given you more credit than claiming you have been running it for a decade and its been reliable. Because, its had some pretty serious issues that if you didn't hit them means your not a good test case.

I'm still skeptical, because AKAIK, XFS still doesn't have an order data mode.

MS gave Word away.

I don't remember MS ever giving word away except at events, as they still do with much of their software. If anything it was darn expensive.

The reason Word won, has more to do with WordPerfect than Word. Wordperfect was THE DOS editor everyone used. But it was a real PITA, without the keyboard overlays it was impossible to learn to use. Oh, and formatting your output was a nightmare of control codes sprinkled all over the text which visually bore no resemblance to the output. To enjoy a modern version of the experience you could try TeX in emacs on a 80x25 terminal...

So, along comes word for windows, and its WYSIWYG (for the most part), and pretty much overnight everyone was like wow that rocks, except for a few die hard wordperfect lovers. Wordperfect responded to word for windows by writing the ugliest VGA application possible (version 6 BTW) which came out a good year or two after word for windows 2. It bombed because it was both SLOW and BUGGY and the WYSIWYG function was barely better than the print preview function they had in 5.1 aka, it was more like WYSIWY Might Get.

Meanwhile, windows was getting better, you could buy accelerated 16 bit video cards,etc and with each video card release windows apps looked better and ran faster. Plus the printer functions in windows were maturing and you could get nice fonts/etc for windows and print them on basically any printer. Unlike wordperfect which had limited fonts and printer support.

Eventually word 6 was released, which was a very nice piece of software and pretty bug free. By the time wordperfect came out with an even buggier windows version it was game over for them. Word was stable, fast and quite usable on windows.

The only real competitor at the time was Ami pro which didn't waste any time bringing a windows app to market.

though I'm trying to figure out how they didn't manage that back when it was 6% only a decade ago.

I don't know what state you live in, but if its like the one I live in the answer is easy and its three fold.

First the population of the state is expanding fairly rapidly, but the laws on new development don't require the developers to pay for the privilege of adding to city services (water/roads/electric). So, everyone moving into town is effectively subsidized by all the existing residents. Sure they have been paying for these services elsewhere, but they didn't bring them with them and they are left rusting/underutilized in places like Detroit.

Secondly, the state itself has been reducing business and franchise taxes as fast as possible. This in turn is reflected in the state paying a smaller percentage back to the communities for education/infrastructure/etc. The local communities then turn around and do the only thing they can, raise sales and property taxes and in many communities its insufficient to make up the shortfall.

Thirdly, the police forces have been expanding nationally at a frightening rate, and they are becoming significantly more expensive. 20 years ago police choppers, SWAT teams, armored vehicles, infrared cameras, etc were unheard of. Now every 3rd rate city in the country has a minor army. We don't even need the national guard anymore because the police force is like a second military. Combined with the fact that the police unions are the only unions in the country that haven't been destroyed by the 'R's means that its likely average salary for the officer handing out tickets is significantly above the salary of the general population. So the city budgets are overwhelmingly paid to the police departments. Librarians get laid off, and the police get a raise.

Only a bunch of ideologues or people complete ignorant of power generation would fail to count nukes as clean energy. When your "waste" after decades of use can be contained in a few shipping containers and used to generate more electricity then its cleaner than the manufacturing byproducts of equivilant "Green" energy sources. The ERI numbers for nukes are staying fairly constant, while even the numbers for coal/NG are going up.

At this point the planet would be better off if we irradiated 99% of it to Chernobyl levels. Simply because it would then be allowed to revert to a sustainable fairly natural state. The current state of affairs is going to be much worse.

Most of these systems are single purpose and fit in more as an embedded system than anything else.

So, what is the attack vector? Most of the XP exploits in recent memory are related to peoples browsing habits and pieces of the OS used by the browsers being susceptible.

So, the fact that people aren't surfing the web probably removes 99% of the threat, leaving the remaining possibilities of a worm on the internal network exploiting an open system service (network share etc) that could be blocked or disabled.

If an exploit is found in a direct system service like that I'm betting MS rolls out a security patch anyway. Probably, just to avoid the liability issues (same way you get recall notices on 20 year old cars if the problem is severe enough and considered a manufacturing defect).

Its only once the installed base drops below 5% or so would I guess that MS really stops supporting it for critical problems. Once that happens its not going to be a target for new exploits anyway.

I'm just wondering how long it takes before they stop doing activations. I have a copy of XP that has never been activated, I'm keeping around just to see what happens. I suspect they release a no authorization patch at some point but right now if they did it I'm sure XP installs would take off again.

For some reason I can't find the paper linked in that article. But accessing 64k devices is basically nothing, especially if they are a bunch of virtual mod3s and mod9's like just about every mainframe config I've seen. And really its less than 64k because your terminals, tapes, etc are also in that address space. Its like saying I have 4 Gigabytes of IO space and each adapter only takes 16 bytes of it. Useless BS information. Really, I was thinking about the address space issues on the mainframe last year, and came to exactly the opposite conclusion. Its a limitation, especially since the address space is shared between LPARs. AKA if you have 20 LPARs, with independent devices its actually only 4k devices per LPAR, which could be really limiting, especially if you can't run EAVs and the max capacity per volume is 54GB.

But the real problem is that even if you attached 256 devices on multiple 8Gbit ficon channels, the CEC to IO drawer interconnect is going to be the bottleneck. Thats assuming you can start enough ficon commands to keep each channel busy.

Here are real numbers from IBM on their ficon performance at 8Gbit (still current speed).

ftp://public.dhe.ibm.com/common/ssi/ecm/en/zsw03127usen/ZSW03127USEN.PDF

Go look at emulex's site. Their numbers are over an order of magnitude better and they offer a 16Gbit board too.

Anyway, did you ask EMC why the numbers were worse on your other platform? I'm betting you can "tweak" it up to speed too. Rarely is the machine the bottleneck when talking on a SAN. Its almost always the disk subsystem. Linux out of the box on nearly every platform needs "tweakage" Many of the fiber channel drivers on linux have very shallow queues and need to be significantly deeper for IOP benchmarks.