UHS-I / SD cards investigation

[allemyr]

                     -->0x0202 and I obtain UDMA 6 speed (around 80MB/s) i suppose original value     

UDMA 6 is 133 megabytes per second, you can read it all over the internet. The limit is something else then UDMA6, UDMA7 will therefore not help much.

[12georgiadis]

Maybe we can change the name of the thread if we have to include CF cards investigation. And thank you all for the ressearch effort. And @reddercity, you are very helpful and you've participated a lot to the progress of D4 Raw. Let's try talking here about SD / CF investigation. If it's the chaos, I hope that someone from the forum moderation would split again the topic if it's necessary.

[waza57]

@A1ex

Can you try 102 or 201?

yes but nothing change.

But with the value of  1000102,  I have get a big improvement of around 30% speed write.
Sadly , this corrupt the card filesystem .  ( i can't read mlv file in card and i must format the card if i try to delete it)


........hey , reddeercity, do you hear this? 

[aprofiti]

I used DIGIC POKE to simply modify this values I found in  http://magiclantern.wikia.com/wiki/Register_Map#CFDMA :

0xC062850C --> 0x1213 and I obtain UDMA 0 speed (around 15MB/s)
                     --> ...........
                     --> ...........
                     -->0x0202 and I obtain UDMA 6 speed (around 80MB/s) i suppose original value
                     -->0x0101 and sadly I obtain UDMA 6 speed  too

Does this address refers to Word 88 of CF Software Interface specifications?

if so, bit 14 is for selection of udma6 and bit 15 is for udma7 (just a guess but can be right):
0x8CF  Select UDMA4 and support from 0 to 4
0x403F Select UDMA6 and support from 0 to 6
0x807F Select UDMA7 and support from 0 to 7

Code: [Select]

CF 5D3:
 0.932.277   CSMgrTask:ff6aa02c:MMIO : [0xC0628504] <- 0x04060503
 0.932.285   CSMgrTask:ff6aa050:MMIO : [0xC0628508] <- 0x010A1105
 0.932.291   CSMgrTask:ff6a9e4c:MMIO : [0xC062850C] <- 0x00000202

    0xC0628504 0xC0628508 0xC062850C
u7: 0x04060503 0x010A1105 0x00000202
u6: 0x04060503 0x010A1105 0x00000303
u5: 0x04060503 0x010A1105 0x00000303
u4: 0x04060503 0x010A1405 0x01000505
u3: 0x04060503 0x030A1405 0x01000808
u2: 0x04060503 0x060A1405 0x01000B0B
u1: 0x04060503 0x090A1905 0x01000F0E
u0: 0x05040402 0x04060503 0x01001616

Can you try 102 or 201?

Maybe 403 for udma6 and 807 for udma7???

Code: [Select]

825FE>  CSMgrTask:00095f98:00:00: *** register_interrupt("CFDriver", 0x82, 0xffb8b8cc, 0x0), from ffb8bb58
Does this initialise supported features of the reader? (Word 82 Features/command sets supported from specifications)
Or maybe is Word 130 (Vendor unique bytes). Does this changes in logs?

[waza57]

I noticed that the speed of writing (under the red icon of the top) varies according to the frame rate.
I do not use the card benchmarks speed test yet, but is it normal that the speed of writing depends on the frame rate?

[a1ex]

Yes, it's normal.

If capture speed is greater than writing speed (i.e. recording is not continuous): memory bus is the main limit. If you capture at a higher data rate (e.g. higher resolution and/or FPS), there won't be enough bandwidth left for file I/O at full speed. I'm not sure how DMA priorities are working, or whether there's any way to adjust them. This is why the hacks that freeze LiveView are able to achive slightly better speed - they turn off some "useless" image streams, freeing some memory bandwidth.

Otherwise... the buffer will be mostly empty and the speed will be limited by image capture speed. In this case, mlv_lite will try to "benchmark" only when the card is actively writing, and may print the "idle" time as well. However, this method is just an approximation: there will be some overhead caused by small buffer sizes (as the raw recording task starts writing to card as soon as it has completed frames in the buffer, rather than waiting for a huge contiguous chunk to be completed). No big deal, as in this case, recording will be continuous anyway. It may affect the estimated time for the next recording.

[waza57]

OK , thanks.
I just use the cf card benchmark and I get between 30-40 Mb/s while the 5d2 is rather 70-80 Mb/s. (value under red icon foe example)
I wonder what's going on?

[a1ex]

Card benchmark does not apply any of the LiveView hacks used during raw recording. Try benchmarking outside LiveView, although that would overestimate recording speed by quite a bit.

30-40 Mb/s sounds a bit too small though...

[mothaibaphoto]

How to safely activate some default preset (without any testing) during camera startup?
I mean, to place that code at the module initialization is bad idea (I tried ).
Need some delayed activation, when everything is loaded and no more card activity...

[Danne]

Lua?
https://bitbucket.org/Dannephoto/lua_magic/src/default/SDoverclock.lua

[mothaibaphoto]

And how do you run that Lua script? Manually? What the point of that script then?
There is no problem to run some code.
The problem is to choose right time to do that.
And, by the way, no need to disable RAW video mode to enable overclock itself.
Problem with allocating buffer for write tests only. 

[Danne]

Set the script to autorun on start up. Basic function if you worked any lua script.
Did you modify code to run with raw video set to on? Right now I use a version which partly skips the test and it works better with raw video set to off. Feel free to modify.

[mothaibaphoto]

This is the starting point of my message: by running that code at startup you risk to corrupt your card.
I did.

[Danne]

Well, so what do you want then? One way or the other you will need to execute the code. Lua script is one way, maybe not the safest but a script could interact and wait for things to settle etc and easily done.
Safer code, ask a1ex...

[mothaibaphoto]

I want to find the answer on my question
And i want to warn others, experimenting with code from sd_uhs:
1. Card overclock and reinitialisation should be performed when there is no card activity.
2. Last version corrupts filesystem(record several files with one filename) when "driver strength" is changed.

[a1ex]

2. Last version corrupts filesystem(record several files with one filename) when "driver strength" is changed.

Are there any driver strength values that are "better" (less likely to cause issues) than others?

Just to cross-check with my own findings.

[mothaibaphoto]

Wow, you ask me as if i know, what it's all about
This is why i can to some extent be sure, that the "strength" is the source of problem:
First, I experimented with precompiled version, and has no any problems.
Than i compiled the version from repo, and got the corrupted filesystem.
I commented out all the SDR104 testing  - and no more corruptions.
I have only one SDR50 card, it records fine at 120Mhz. 12bit FHD losless continuous.
For now, i'm happy with that.
If you eventually will deсide to reimplement card spanning, that would be fantastic

[Bropa]

FYI : 700D/1.1.5 using Danne's Sept11 build with SDoverclock slipstreamed and SD_UHS hack

For reference, I purchased a ProGrade 64GB SDXC V90 UHS-3 Card - looking to exceed the 50-60 MBps Write numbers ive seen posted recently.

Numbers are shown here in the Image. Very impressive results. I'll perform video shooting this weekend and report back my results

[ludzik3d]

Hi! Is Samsung 128GB microSDXC Evo Plus good choice for Canon Eos M with UHS Hack? Sorry for my english

[Walter Schulz]

Write rate (without overclocking) is 23 MByte/s according to Cameramemoryspeed.com.

[ludzik3d]

Thank you, in specs it have write 90MB/s. Could it reach 60 MB/s (actually limit with overclocking for EosM from what I was saw) with UHS Hack? Is someone using this model?

[Walter Schulz]

Actually there are 2 versions named "Samsung EVO plus"

old (slow): MB-MC128DA/EU
new (fast): MB-MC128GA/EU

The new one replaces "Samsung EVO pro" and is in fact quite fast.
Make sure to get the newer model.

[ludzik3d]

Walter Shulz - Thanks, I will check this models.

I think also about safety with overclocking on not used by this way SD/microSD cards.

[vincent pierre]

Hello everyone

I read all the pages of the topic. I did some testing with the "hack sd overclock" a few weeks ago.

1. First : thanks you so much. Your work is amazing.

2. I try to sumarise this topic adapting it for my case.

3. My goal : in 2019 i will shoot a short film. at this moment i try to validate my workflow.

4. My config : canon eos 700d / T5i. canon 50mm STM. canon 10-18mm STM. With Magic Lantern Firmware 

5. I would shoot in : raw 14b lossless or 12b lossless or 10b lossless. 2.5k. 24fps.

6. Final delivery: at a minimum: 1080p 24fps.

7. Video Apps : MLV App  + Da Vinci Resolve.

8. I would like to extend by a few mega per second the writing capacity of my camera.

9. I would like to use the experimental branch: "4K raw video recording; lossless compression / crop_rec module with higher resolutions"


This is my two question :

A. which version of "hack module" I should use and where I can download it. thanks for your recommendations.

B. what is the card (128gb, is the more adapted i presume for RAW) that is the more fiable and compatible with the hack ? thanks for your recommendations.

Thank you in advance
And really really: BRAVO for your work.
From France
Best regards

[Bropa]

FYI : 700D/1.1.5 using Danne's Sept11 build with SDoverclock slipstreamed and SD_UHS hack

For reference, I purchased a ProGrade 64GB SDXC V90 UHS-3 Card - looking to exceed the 50-60 MBps Write numbers ive seen posted recently.

Numbers are shown here in the Image. Very impressive results. I'll perform video shooting this weekend and report back my results

Update here;

My goal was to find a way to shoot 720P RAW with the 700D/T5i, what I discovered with the single sample unit I had access to from Prograde was, the camera would shoot 5-10 seconds of footage, and then stop. It would intermittently drop the memory controller after being pushed to the 50 MBps + threshold. I tried this in 2 of my 4 T5i's and it happened on both cameras. Ultimately proving to be unstable even with this top-end SD Memory card.

Having said that, with the SD Hack, this is the fastest SD Card access I have been able to achieve with this Camera.