SD Overclocking - DIGIC 5 only

[names_are_hard]

Probably all you need to try is low-level format card in cam, and choose to keep ML.

All the other steps, you don't care about.  You're not trying to make comparable benchmarks each time.

[names_are_hard]

You (And the other Devs) will need to validate what I am saying here, as I do not code.

So I will describe the problem: You record let's say 10 clips, then all of a sudden, there is a "Frame Order Error slot XXX frame XXX expected XXX". This stops recording prematurely, but usually recording again will work for a while until the error happens again.

As you describe it, this is too complicated for me, I don't know the mlv_lite module well and don't want to spend a lot of time in this area.

The "frame order error" occurs here, in mlv_lite.c:

Code Select Expand


3538                 if (slots[slot_index].frame_number != last_processed_frame + 1)
3539                 {
3540                     bmp_printf( FONT_MED, 30, 110,
3541                         "Frame order error: slot %d, frame %d, expected %d ", slot_index, slots[slot_index].frame_number,      last_processed_frame + 1
3542                     );
3543                     beep();
3544                 }
3545                 last_processed_frame++;


This is in a loop designed to mark frames as free so the memory can be re-used.  It suggests there is a logic error around which frames have been written to disk, and can thus be freed.  Annoyingly, the exact same error text is used in a second place, so that's also possible (never use the same error message twice ).

I wouldn't expect the recording to stop because of this, it looks non-fatal.  You say it can take 5 seconds before recording stops.  I think the recording stopping is not *directly* related to this error.  It could easily still be a symptom of whatever the root cause is.  If a dev with more raw video experience wants to look at this, working out why the slot ends up being freed when it shouldn't is the obvious place to start.

[gabriielangel]

thx a lot. will try. exciting.

I overlooked one thing: You seem to be using the 650D and 100D exclusively, So you won't be able to use Danne's custom build for now.

Therefore, You'll have to use bilal's original build.
You can follow the instructions here to enable all the modules: https://www.youtube.com/watch?v=V0M7n2cAHMM

Sorry about that!

[gabriielangel]

I wouldn't expect the recording to stop because of this, it looks non-fatal.  You say it can take 5 seconds before recording stops.  I think the recording stopping is not *directly* related to this error.  It could easily still be a symptom of whatever the root cause is.  If a dev with more raw video experience wants to look at this, working out why the slot ends up being freed when it shouldn't is the obvious place to start.

Thanks for looking into it.

[Danne]

As you describe it, this is too complicated for me, I don't know the mlv_lite module well and don't want to spend a lot of time in this area.

The "frame order error" occurs here, in mlv_lite.c:

Code Select Expand


3538                 if (slots[slot_index].frame_number != last_processed_frame + 1)
3539                 {
3540                     bmp_printf( FONT_MED, 30, 110,
3541                         "Frame order error: slot %d, frame %d, expected %d ", slot_index, slots[slot_index].frame_number,      last_processed_frame + 1
3542                     );
3543                     beep();
3544                 }
3545                 last_processed_frame++;


This is in a loop designed to mark frames as free so the memory can be re-used.  It suggests there is a logic error around which frames have been written to disk, and can thus be freed.  Annoyingly, the exact same error text is used in a second place, so that's also possible (never use the same error message twice ).

I wouldn't expect the recording to stop because of this, it looks non-fatal.  You say it can take 5 seconds before recording stops.  I think the recording stopping is not *directly* related to this error.  It could easily still be a symptom of whatever the root cause is.  If a dev with more raw video experience wants to look at this, working out why the slot ends up being freed when it shouldn't is the obvious place to start.

I commented out this from eos m. It never caused any real life issues to me.

[names_are_hard]

Printing the warning doesn't stop recording.  So yes, I would not expect commenting it out to cause a *problem*.

But gabriielangel finds that recording is stopped some time after the warning.  You won't have any clues, because you hid it.  So it's not the best idea, even though it doesn't directly cause a problem.

[Danne]

Probably not. I did not investigate this further unfortunately so can't say much about it.

[mlrocks]

I overlooked one thing: You seem to be using the 650D and 100D exclusively, So you won't be able to use Danne's custom build for now.

Therefore, You'll have to use bilal's original build.
You can follow the instructions here to enable all the modules: https://www.youtube.com/watch?v=V0M7n2cAHMM

Sorry about that!

i don't have m. thx for the video.

[gabriielangel]

A Little Primer On Exposure

In order to come up with a representative enough chart for possible record times for a given resolution (To help choose the right card for a given budget),
I needed to establish a few things first. As data rates are heavily influenced by the average exposure of the scene, we need to have a good idea of how low we can go before getting too much noise.

So, the first thing is to find out where the sweet spot is; the goal being to get the lowest decent Data Rate while keeping noise at bay.

Once you factor in all the hours needed to really understand those cams (Eos m, in my case), it's definitely not a $300 cam anymore! Hopefully, those posts will help those beginning getting straight to making movies...

DISCLAIMER: This is not an absolute Dynamic Range test. I did not have access to the proper tools to get to that level. So I used a computer monitor, which already has some sort of polarizer applied to it, plus the Variable ND on the lens, which is 2 stacked polarizers. So the illumination is uneven.
But for the present purposes, it is fine.

The chart I used:

I created the file on Photoshop Mac. If you use a PC, you'll need to adjust your brightness and contrast a little, as the gamma is different (This matters only if you plan on replicating the test.)
There is 1/2 stop difference between each level on top, and 1/4 stop difference at the bottom.

The values when using the RGB Spotmeter on the EOS M (In Red):

I recorded the chart slightly off-focus, to eliminate the Moiré (it is an LCD Monitor right?!)
Those are the values you get when exposing the Chart ETTR without any highlight clipping.

The Marshall False Color Key:

To help decide how low of an exposure we can use to get a good Signal-To-Noise Ratio (SNR) we'll use the False Colors on the EOS M, set to Marshall. In that case, The Pink has been replaced by Orange, and Black means your Highlights are clipped. Magenta (Fushia on that picture) means your Blacks are clipped. Orange is the ballpark for well exposed skintones.

So given this scene:This is taken with a phone. I will put the actual MLV output in the next post.


With False Colors applied, we get this:

(Exposed ETTR, whithout any clipping)

If we were to clip the highlights:

If you do this on the EOS M, you'll only get a few seconds of recording time. You can have Red, but Black is a no-no.
Black means your highlights are clipped.

With a slight underexposure:

In that case, anything in the area below the 9 1/4 Stop will give you an ugly kind of noise where the Magenta dots appear,  if you try to do any shadow recovery (Actual examples in next post).

Heavily Underexposed:

Here, anything lower than 8 stops below the highlights won't look nice if boosted in post.
So, you need to leave Magenta for only the darkest blacks you know you'll never try to recover!

As a last resort:

This would give you 8 clean stops of Dynamic Range, plus a full stop of shadows you can recover relatively cleanly. If you get a little Magenta in a very dark area (For example, under a tree) no one will notice. If I do something serious, I'll add some kind of reflector or light to bring the shadows up a little. If I just walk by for fun, I may just choose a better spot

At night:

If this was a nightly or dimly-lit scene, it could still look good, as long as the subject is around the 2nd stop and you crush the lowest shadows a little.

So the next step is to find out when the noise becomes obtrusive... In the next post.

Here's a very good short Youtube link if you want to see false colors in action, in a more natural context: https://www.youtube.com/watch?v=nncazai0Ei4

[gabriielangel]

Exposure vs Noise (EOS M)

(It will be easier if you download all the images first. The file names are descriptive.)

The end goal here is to come up with a realistic minimum average exposure, to establish an approximate Data Rate for any given Resolution / Bitrate / Framerate.
That way, someone could decide if they want to invest $100 for a lexar card, or settle for a $15-$20 Samsung if it gets the job done at one's preferred resolution.

So, to find out how low we can underexpose to save some bandwidth, while keeping a good image quality...

Given that the chart I used in the previous post:


Is exposed like this:

(Exposed ETTR, whithout any clipping)

We get images like these:


14bits


12bits


11bits


10bits


14 bits, with exposure lowered in MLV app to check highlights.


10 bits, with exposure lowered in MLV app to check highlights. Highlights are comparable to 14 bits.


So far, we can see that without any shadow recovery, noise starts being visible around Stop 6. Slightly before 6 at 10bits, but barely (Not easy to judge with a static frame)
This will vary according to the color of course.
A slight red tint appears in the low level noise at 11bit, and becomes obvious at 10bits.

Let's investigate the shadows. We'll add a shadow boost of 100 in MLV app:

14bits with Shadows +100


12bits with Shadows +100


11bits with Shadows +100


10bits with Shadows +100


Now we see a huge difference in the quality of the noise that is recovered along with the shadows.
at 14 bits, the noise starts to become really coarse at 9 3/4 below Highlight level.
at 12 bits, the coarseness starts at around 9, but there is a clear difference starting around  Stop 7 compared to 14 bits.
at 11 bits, the difference compared to 12 bits starts at Stop 7, but the coarseness start being visible at 8.
at 10 bits, noise becomes quite visible at Stop 6, at Stop 8 there is a lot more noise than at 11bits, and what is at 9 and below is uncomfortably coarse. Also, there is a red tint all over the shadows.

Let's see if using Darkframe subtraction improves the noise a bit.
I filmed clips with the cap on, one dark clip per bit rate. I exported those dark clips with the exact same 4 second length as MLV fast pass and then as MLV Averaged frame (To get same length averages).

14bits, shadows+100, Darkframe subtraction:


12bits, shadows+100, Darkframe subtraction:


11bits, shadows+100, Darkframe subtraction:


10bits, shadows+100, Darkframe subtraction:


10bits, shadows+60, Darkframe subtraction: (To see what it looks like in a slightly more realistic context)


At 14bits and 12 bits, the difference is subtle, but still noticeable as the red tint is removed.
But at 11bits, slight vertical lines begin to appear and at 10bits, those vertical lines become quite obvious.

So, what does this all means?

1st thing is to avoid shooting at 10bits if you plan on making any color or exposure modifications in post. I would start with 11bits minimum and prefer at least 12bits.
(This has been stated before by several members on this forum).
Because exposing close to ETTR maximizes the amount of light the sensor receives, and the bit reduction happens once the signal is digital Edit: This is not 100% exact, it appears that the bit depth reduction is obtained by gain reduction at the analog stage and a 14bit container is always used. (This is one of the reasons why the quality of the noise degrades rapidly at the lower end of the scale, as bits of the shadows sharply get crushed to pure black. You end up with larger black blocks once you bring it all up);
I am under the impression that adding a 13 bits option would be a good idea to help gain a few MB/s, as this would still allow to ETTR while allowing a slightly lower Data Rate, as opposed to significantly Underexposing 14bits while recording.

Now, we want to make sure that Skintones are always above the visible noise level, which is between Stop 5 and Stop 6 below highlights;
But we also want to keep the grainy parts as low as possible...

The EOS M is rated at 11.2 Stops of DR according to DxOMark :https://www.dxomark.com/Cameras/Canon/EOS-M---Measurements
We definitely want anything important enough to be seen to be above Stop 9, because of the coarse noise happening below that point.

Based on the false color images above, the average showing up on the Histogram should be above 2.6 to minimize the grainy noise in the visible parts.
I know, by experience, that outside on a sunny day, I can shoot 30 seconds + whatever, at 2.8k/14bits with histogram showing 1.2 (up to 0.8 every now and then) As long as the highlights are mostly yellow with a hint of red (On the false colors).

So the target seems to be somewhere between Histogram 2.6 and 1.0 (Histogram set to ETTR Hint).

Again, the goal here is to come up with a realistic minimum average exposure, to establish an approximate Data Rate for any given Resolution / Bitrate / Framerate.

Your comments are very welcome...

[benoit]

Thanks a lot for a such good detailled information !   

[Walter Schulz]

Because Samsung PRO Plus 128 GB has been reported as unstable (in "real life", benchmark looks good) both cards (2021 and 2023 edition) got a "NO" flag in Wiki card list.
Better save than sorry.

[gabriielangel]

Here is a tentative chart for the recording possibilities of different cards at various resolutions, for the EOS M.
If you own one of the cards I tested (Listed in the second sheet), you could try recording a scene or two, to see if the predictions are robust.
All the instructions are in the spreadsheet.

To download it :  Here

EDIT: I added a Scene complexity Dropdown menu, to have an idea of how scene complexity can affect data rates. The chart is a lot more complex than I would have liked to see it, if I were to look at it for the first time, but I think it beats having to learn this by trial-and-error
EDIT2:There is now a dropdown menu to choose cards instead of entering the numbers manually.

[gabriielangel]

Speed Test: Samsung Evo Plus microSDXC UHS-I 512GB
R130/W130
Product Number: MB-MC512KA/CA
MDT: 2023/07

Highest CropMood speed reached for a 1 minute Clip (Peak Orange): 86.67 MB/s @ 2.8k/14bits
Highest CropMood speed reached for "Continuous"   (Steady Green): 76.79 MB/s @ 2.8k/14bits
Highest CropMood speed reached for a 15 seconds clip (Red Speed): 89.3 MB/s @ 2.8k/14bits
240MHz / SDR104



Card has been formatted in camera (EOS M), moved to a Mac to copy the CropMood files, then back to the camera to make it bootable.





The method is outlined here: https://www.magiclantern.fm/forum/index.php?topic=25841.msg245694#msg245694

I recorded more clips this time, to hopefully expose any Thermal Throttling or Burst Speed Wizardry implemented by the manufacturer. I recorded about 10 clips of various lengths (Light orange / red) prior to beginning the test (Not in the picture, to save on transfer time)

This card did not exhibit any problems and was consistent. Unlike the other cards tested so far, this card did not trigger a single "Frame Error" message during the tests.
This card is about the same price as a Lexar Silver Series 1066x 256GB, for TWICE the size, and the performances seem comparable so far.

[Walter Schulz]

R130/W130 for EVO Plus?

There are no decent spec sheets by Samsung for sure!

[gabriielangel]

R130/W130 for EVO Plus?

There are no decent spec sheets by Samsung for sure!

At least they wrote something   Some cards say "Transfer Speeds of up to 120 MB/s!" Then after looking for write speed everywhere on the package, what you find somewhere on the back:
Numbers stated are for read speeds of up to 120MB/s, when using a compatible reader. Write speeds lower.

[Walter Schulz]

Please check wiki entry: K means 2021 edition. 2023 has S suffix. Date in third culumn doesn't refer to production or purchase.
A (or other suffixes like EU, US) refer to market region and should be ommited in this column.

[gabriielangel]

Please check wiki entry: K means 2021 edition. 2023 has S suffix. Date in third culumn doesn't refer to production or purchase.
A (or other suffixes like EU, US) refer to market region and should be ommited in this column.

Well, I took the MDT  from the CID Info Menu (2023/07).
The PRV (Revision Number) is: 3.0
The number written behind the microSD card is MB-MC512K
The Number written next to the UPC code (See on the picture): MB-MC512KA/CA .
I made the assumption that the CA (Canada) was the market part, as there is also a model called MB-MC512KA/EU (!)

But you're right, it is 2021 according to this link: https://www.samsung.com/uk/memory-storage/memory-card/evo-plus-512gb-microsd-card-mb-mc512ka-eu/

Will fix shortly, thanks.

Have a look at this (I could not find the rev3.0), maybe this could be of use to those who know how to tweak the controller to get more out of the card?

https://download.semiconductor.samsung.com/resources/data-sheet/2023_samsung_data_sheet_microsd_card_evo_plus_rev.1.0.pdf

At the very bottom (Fine print) it says:
2)SDR104: 1.8V Signaling, Frequency up to 208 MHz, up to 104MB/sec, Max. Current Consumption 800mA (varies by test conditions)
3) DDR200 : 1.8V Signaling, Frequency up to 208 MHz, up to 200MB/sec, Max. Current Consumption 800mA (varies by test conditions)

[gabriielangel]

Speed Test: Samsung EVO Plus microSDXC UHS-I 128GB
R130/W130
Product Number: MB-MC128KA / MB-MD128S (Important precision, thanks @walter)
MDT: 2023/05

Highest CropMood speed reached for a 1 minute Clip (Peak Orange): 62.64 MB/s @ 2.8k/14bits
Highest CropMood speed reached for "Continuous"   (Steady Green): 55.13 MB/s @ 2.8k/12bits
Highest CropMood speed reached for a 15 seconds clip (Red Speed): 66.4 MB/s @ 2.8k/14bits
240MHz / SDR104

(Item "H" in the picture below)


Card has been formatted in camera (EOS M), moved to a Mac to copy the CropMood files, then back to the camera to make it bootable.






The method is outlined here: https://www.magiclantern.fm/forum/index.php?topic=25841.msg245694#msg245694

To hopefully expose any Thermal Throttling or Burst Speed Wizardry implemented by the manufacturer, I recorded about 10 clips of various lengths (Light orange / red) prior to beginning the test (Not in the picture, to save on transfer time)

*Something new, I added a "Red Speed" to the test, which is the maximum speed which a card can sustain in the red for 15 seconds.
This doesn't make much of a difference when recording at 12 bit, but with the high resolution presets at 14 bit, it shows if the card can tolerate sudden changes in the scene (Like confetti exploding or anything entering the scene that's brighter than when you first hit record) I updated the other card tests as well.

This card exhibited a weird behaviour in which every other recording gave a "Frame Order" error as soon as I recorded clips over 30 seconds, in the Orange zone !?
If I recorded in the Green zone, no problem. This happened recording at 2.5k 2.39:1, 14bits and 12 bits, 1 minute clips and clips over 30 seconds.
I tried at 240MHz, 192MHz, SDR104 and SDR50; No difference.

As @walter pointed out, the model number written on the card itself makes a difference, but this number isn't written anywhere on the package, which looks identical to the package of K variants, at least here in Canada. So there is no way to know which variant (K or S) you are getting before opening the package.

So far, the Samsung cards (Along with the Lexar) have the steadiest, constantly repeatable across takes speed.

[gabriielangel]

I updated my EOS M Data Rate Estimator Chart: Here
You need to save it locally or copy it to your google drive in order to use it properly.

No need to enter the numbers manually, you can now select one of the tested SD/micro SD cards using a Dropdown Menu.
Hopefully, more people will test their cards so that we can have a larger database.

What I have gathered so far is that, unless one plans on using only the 3x3 Modes, a card which can remain in the Green Zone at 76 MB/s or more
is required to be able to use most presets comfortably @23.976 fps. The higher resolution presets require one of the fastest cards.
It appears that some manufacturers have some cards run with a series of short "Bursts", so that those look good on benchmarks.
Although ok for file transfers, what we need here are steady sustained speeds! So, a different kind of benchmark is necessary.

If the quality of the image is important, 14 and 12 bit are to be preferred. At 12 bit, due to the way the bit depth is reduced,
we are already running almost 2 stops below optimal exposure. So trying to underexpose further to lower the data rate is not ideal (Would progressively make the image noisier).
I have seen a few posts on the facebook group where people are complaining about the noise, not knowing that recording at 10 bits is not ideal, and requires a very bright scene to look decent.
In such cases, choosing a faster card / higher bit depth is the best cure. This may all be obvious for most people on this forum, but it is definitely not so for someone first putting their hands on the cam!

[gabriielangel]

By how much can we reduce the Data Rate with Underexposure?
Another chapter in the quest for Data Rate Optimization on Eos m.

Several people report long recording times on the various social media, but after close inspection, one sees that the footage is often severely underexposed.
So, how much gain (or rather, loss) can we expect, while keeping the quality as high as possible? See the attached animated .png below.

at 2.8k 1:1 14bit, The Data Rate can be reduced by 7%, by underexposing 1 Stop; and 13% by underexposing 2 stops (Will vary slightly depending on the scene being shot, of course).
Because the Bit Depth reduction is obtained by reducing the Analog Gain in the camera, Underexposing 2 stops equals switching to 12bit (3 Stops=11bit, 4 Stops=10bit).
BUT, as you can see in the image below, Underexposing is a lot noisier than reducing the bits with Analog Gain(!)
Therefore, as soon as you need to underexpose significantly, it is better to lower the Bit Depth to the closest match instead.

The color chart was lit by 2 LED panels, and was exposed so that the white square was right below the clipping point.
I recorded 1 clip per aperture, in 1/3 stop decrements. I then boosted the exposure accordingly in MLV App to normalize the smaller aperture clip's brightness against the first clip (Wide Open).
This clearly shows that the clip recorded at 12bit (12bit-ML) is cleaner than the clip recorded 2 stops underexposed (12bit-Equivalent). The same goes for 10 and 11bit at the transition points.
Also, the Data Rate is lower for the clips recorded with Analog Gain Bit Depth reduction (When you change the Bit Depth in the Movie / Crop Mood menus), because of the lower noise.
You can also see that at image 13, 4 Stops below, the noise is already quite apparent.

So, again, it would be a good idea to add a 13bit option, as this would allow a significant reduction of the Data Rate, while having almost no impact on image quality.
This would also give about 1 extra stop of cleaner exposure (Compared to underexposing by 1 Stop).
With a good card, it would be easier to reap the benefits of recording at higher Resolutions / Bit Depth / Exposures.
(Click on the image to load the full resolution animated version)




All the images in a .zip file, if you get dizzy: https://bit.ly/3SB7FoP

[Danne]

Interesting.

[gabriielangel]

Speed Test: Lexar Professional 1667x SDXC UHS-II 256GB
R250/W120
Product Number: LSD256CBNA1667 / A0185-V60-256BSL A (Written behind the Card)
MDT: 2020/12
PRV: 1.0

Highest CropMood speed reached for a 1 minute Clip (Peak Orange): 88.8 MB/s @ 2.8k/14bits
Highest CropMood speed reached for "Continuous"  (Steady Green): 78 MB/s @ 2.8k/14bits
Highest CropMood speed reached for a 15 seconds clip (Red Speed): 91 MB/s @ 2.8k/14bits
240MHz / SDR104



Card has been formatted in camera (EOS M), moved to a Mac to copy the CropMood files, then back to the camera to make it bootable.





The testing method is outlined here: https://www.magiclantern.fm/forum/index.php?topic=25841.msg245694#msg245694


This card did not exhibit any problems and was consistent. 
The card triggered a few "Frame Error" messages during the test.

This card has a high enough Data Rate to handle good brightness at 2.5k 14bits / 2.8k 12bits 1:1.

So far, I have noted that the difference in data rate between the camera stopping by itself at around 1 minute, and it going past the 2 minutes mark is often of 1-2 MB/s for most cards.

Unless you plan on recording clips at 3K 1:1/12bits (or Bright 2.8k 1:1), Samsung EVO Plus, Sandisk Extreme Pro and Lexar Silver 1066x are a better value, as this is one of the most expensive cards.

[gabriielangel]

Speed Test: Samsung EVO Plus mSDXC UHS-I 256GB
R130/W130
Product Number: MB-MC256KA (MB-MC256K written behind the Card)
MDT: 2023/10
PRV: 3.0

Highest CropMood speed reached for a 1 minute Clip (Peak Orange): 87 MB/s @ 2.8k/14bits
Highest CropMood speed reached for "Continuous"  (Steady Green): 76.6 MB/s @ 2.8k/14bits
Highest CropMood speed reached for a 15 seconds clip (Red Speed): 88.9 MB/s @ 2.8k/14bits
240MHz / SDR104 (Benchmark is identical with SDR50)



Card has been formatted in camera (EOS M), moved to a Mac to copy the CropMood files, then back to the camera to make it bootable.


     

The testing method is outlined here: https://www.magiclantern.fm/forum/index.php?topic=25841.msg245694#msg245694


This time, I filled up the whole card's capacity with tests. This gave me more data: (The cam stops recording by itself)

30 Seconds: 87.6 MB/a
23 Seconds: 88.2 MB/s
18 Seconds: 88.6 MB/s
10 Seconds: 91 MB/s

The card is not as consistent as the Lexars in the red zone, but is very consistent in the Orange and Green Zones.
The performance is on par with the Sandisk Extreme Pro 256GB R200/W140, and costs 30% less even at regular price.
No Safe Mode triggers, no throttling, only a few sporadic "Frame Order" error messages (4 messages out of 90+ clips recorded), where the recording stops early.

Regarding the Benchmark:

The benchmark runs between 8-10 seconds and the number it gives is close to the 10 seconds results I got in the test. In this area, there is a lot of variability, except for the most expensive cards.
As discussed previously, a 1-2 MB/s difference can double the possible recording time at the higher end, and add up to several minutes in the low orange zone.

Most compatible "Pro" cards can perform reliably in the Green Zone (76-78 MB/s), but around this data rate, 1x3 4.4k/12bit and 1:1 2.5k/12bit are the highest settings where you'll get reliable recordings.

So, the most interesting zone to test is the Orange zone, where the cam can record continuously for 1 minute +. This is where the door opens to the highest resolutions.
1 minute is plenty to record about everything I see posted as examples on the facebook group...

Very few people will go through the trouble of testing the cards manually, and most people return the cards immediately if those don't work as expected. This makes it hard to know what can be done with a particular card, and those vary, sometimes substantially, between revisions.

So it would be nice if the Benchmark could test for SUSTAINED speeds for a given length of time,
which would make it a lot more useful and make it easier to build a reliable Card Database, as reporting would be simplified.