I have been experimenting with a fast logger using an Adafruit Data Logging Shield and a sketch to log 8-bit data from an Arduino analog pin. Any SD shield/module could be used.
I have been able to log data to an SD card at 100,000 samples per second.
If there is any interest in this sketch I will polish it a bit and post it.
Plots, pictures and more info is here http://forums.adafruit.com/viewtopic.php?f=31&t=30557
If there is any interest in this sketch I will polish it a bit and post it.
Sure, there is..
p.
What's the SNR on such high-speed readings?
I did some tests but mostly looked at other people's work.
This is a good article on the AVR ADC and agrees with other tests ATmega ADC tutorial | Open Music Labs.
Here are the results of the SNR tests expressed as ENOB.
Where
ENOB = (SNR – 1.76dB)/6.02dB
At 100 ksps I must clock the ADC at 2 MHz so the above test says I get an ENOB of a little under 7.5. Not too bad since I am recording 8-bit data.
At rates lower than about 70 ksps I can use 1 MHz for the ADC clock for better SNR/ENOB.
The ATmega datasheet makes it sound like an ADC clock above 200 kHz will kill accuracy but all test I find give results like the above for the 328p.
I posted the sketch that can log up to 100,000 samples per second as AnalogIsrLogger20120810.zip Google Code Archive - Long-term storage for Google Code Project Hosting..
fyi - there is stm32f3 CM4 coming next month - with up to 9MSPS ADC (12bit 5MSPS, 50KSPS 16bit S-D ADC).. but none SDIO 
Yes you can buy faster hardware. Compared to the area of science I came from your new chip is molasses.
If it isn't a flash ADC in the GHz range it's slow. Big experiments also handle incredible amounts of data.
The Atlas experiment at CERN discovered the Higgs Boson. Atlas digitizes 40,000,000 events per second and each event has 1.6 MB of raw data. That's 64,000,000,000,000 bytes per second.
This data is processed by fast hardware in real time and most is discarded. Atlas only records 320 MB/sec, one event in 200,000.
The first level processing has 72 racks like this:
I record 100 KB/sec in my sketch, a factor of 3,200 less.
All of this little use to the average hobbyist. I find few takers for my fast AVR logging programs.
The typical email I get asking about fast logging is for something like an accelerometer with three channels at 1000 samples per second. Most hobbyists don't realize that digitizing all channels of an event at the same time and at precise time intervals is key to good data.
Here many of the STM32 chips have something to offer. Some of the STM32 chips have three ADCs that can be trigger at the same time.
The single ADC in AVR chips make it impossible to digitize multiple channels properly. You can use several self-clocking external ADCs to do much better.
I like playing with the AVR because it is a challenge to do good measurements. I did a lot of work on this sketch to reduce jitter and signal to noise.
I start the ADC on a timer compare event, not an interrupt. I make sure the timer triggers at a multiple of the ADC clock period. This reduces time jitter. I use DIDR to disconnect the pin's digital input. An analog input floats all over the place, and causing the digital input to constantly toggle high and low. This creates excessive noise near the ADC.
..in early '93 I spent some time at DESY, walking through the underground pipe, touching all the detectors.. The beam was off, of course 
I would be happy to see LHC as well.. Even Desy and Hera were monumental gadgets, so I cannot imagine the size of the LHC detectors.. That is one thing I would be curious about - the detectors and the input ADCs etc. I guess the events are something like nanosecs events (pulses) coming from semiconductor detectors (at least desy had it) you have to catch and S/H for further ADC..
I built a homemade detector with PIN diodes and a preamplifier, so I get needle shaped pulses 5-200mV++, ~10-50usecs long, random of course (5 to hundert a minute based on irradiation). Since then I am thinking about how to make a spectral analyser (a histogram with energy bins) with an MCU. I have to detect the pulse (ie. comparator), then catch the amplitude, then ADC it.. I've been thinking on direct sampling the signal at ie 1MSPS and to do the analysis of the data on the fly so I must not mess with analog stuff.. Would be interesting to see the spectra of various sources then
64,000,000,000,000 bytes per second.
All of this little use to the average hobbyist.
No shit
I'm interested in your fast logging, but I'm working with LPCs at present and can't use the library.
Rob
The Atlas experiment at CERN discovered the Higgs Boson.
No they didn't. May be you should read peer reviewed papers not tabloid newpapers. 
At 100 ksps I must clock the ADC at 2 MHz so the above test says I get an ENOB of a little under 7.5. Not too bad since I am recording 8-bit data.
The Atmel spec says you won't get full 10bit accuracy above 200 kHz ADC clock, nor below 50kHz. The site from which you pulled the graph shows that the hit from running beyond the spec is not as bad as one may imagine. Though I have not has the time to see what is really meant "effective" in ENOD. It's some statistic that needs to be understood before jumping to conclusions.
A major problem is that adc clock is a binary sub multiple of system clock meaning the only in spec possibility is the default arduino which is not that high. (circa 75kHz IIRC)
Changing the main clock has knock on effects in library routines like millis() and probably on SPI timings etc.(ie downloading a sketch to Arduino) Needs to be done with care.
Clearly if you are only looking for 8bit data the spec sheet range is not applicable, you can sample quicker but don't forget all the errors in a single 8 bit reading. Probably +/- 2LSB
I'm also working at getting a fast ADC logging to SD.
Could you give more details about your "experiments" an what you found?
ENOB (not ENOD) has a very precise meaning.
I included two papers with the fast logging sketch that describe how it is determined for the AVR ADC.
I'm sure it is well defined , I was just stating my caution about drawing conclusions having not looked into it.
I don't see the papers you refer to , are we taking about : fastLoggerBeta20110802 ?
The papers are included in AnalogIsrLogger20120810.zip. There are two tests of the AVR ADC.
Have you read the Analog Devices papers Unformatted write to SD - #4 by fat16lib - Storage - Arduino Forum?
They describe evaluation of ADCs.
At least read this one http://www.analog.com/static/imported-files/tutorials/MT-003.pdf.
If you want to get serious about understanding issues with ADCs, Walt Kester has many good articles.
Here is a link to his Handbook on Data Conversion Analog Dialogue Technical Journal | Analog Devices. It covers both ADC and DAC issues.
Ooh, great link! I am downloading that when I get home.
When I made a multichannel digital delay line in 1985 (12 bit sampling at I forget what speed, storing in SRAM, reading back out after a delay time, mixing the 4 channels of delay with opamps and feeding some back to the input for fadeout, all data done in parallel) I experimented with what sounded good by ear for the filtering to use. All wirewrap, LS logic, ran kinda warm! I've thought about redoing it with a menu for selecting stuff vs read out of values on 4 7-segment displays, and PCB vs this big wirewrap card.
All done in software these days (and back then even) with high speed processors and different hall/room effects, so kind of a moot point, but an interesting project none the less.
CrossRoads:
When I made a multichannel digital delay line in 1985 (12 bit sampling
At that time we made FFT spectral analysers for 1/f noise measurements in semiconductors. It was a serious r&d so when people are connecting something to arduino and do FFT today is funny to see We spent months with decoupling, denoising, optimising our low noise preamplifiers, high order low pass filters, adconverters (at that time a discrete construction - DAC, successive aprox reg., S/H, comparator, etc) so we had a lot of control over it. We needed a lot of FFTs to make (and a lot of math, the spectra precision is related to sqrt(N), where N is number of FFTs done) for a single spectral plot - quite a time consuming exercise at that time