loop_myshoots TEST NEWS dcimdl delay 1.4sThis is interesting // here's how it developed.
Today's FAIL occurred after 2459 myshoots (4918 files - USB 1), JPG &CanonCR2 range 10M to 15 MB max total per download (1-1/2 days). ERROR this time: ReadFDir.c
I grabbed the romlog (and did the usual hand-cleaning of the camera to restart a new session at 1.6s delay). On the very first myshoot however, I got the ReadFDir.c error again. Hence something new ... a back-to-back failure despite the clean camera PUP state ... and .... it is the second such incident in a row. The cursory conclusion is that these back-to-back failure incidents seem occur at the longer delay times of >= 1.2s.
One perhaps, but two could not be a coincidence. So ... what's the reasonable explanation? This cannot be the camera or CHDK I figured. What's left is the SD card. I reasoned ... is it possible SD card write bit rates can vary from file to file of the same size?
This is the first hit I got ....
http://mbed.org/forum/mbed/topic/719/?page=1#comment-10055Having read the above and from my data, the failures seem to be more relevant to either wear-leveling and/or how the SD controller distributes a big write on a card.
My card is a C4 (10MB/s). So the clearer picture I'm getting is this:
1) Given a 15 MB file say, write speed is almost never the same, even if we delete the file and rewrite the same file;
2) Most typical writes may very in speed by a few percent and on this card are somewhat faster than 10 MB/s, what I will refer to as the typical write "fuzzy zone";
3) If we delay less than 750 ms then we are closer into the "fuzzy zone" where failures occur more frequently, about 1:50;
4) This suggests the average write for my average file pair of 12 MB is at least 16MB/s;
5) If we delay longer than 1.2s, most writes will be far outside the "fuzzy zone" and typically not happen (1:1000);
6) At 1.4s delay or more, occasionally, there may be a major data reorganization on the card that delays a write by a (still unknown) very large amount, and for a large file like ours it can be severe enough to fail if delay is not enough to account for the worst-case reorganization time;
7) Therefore assuming 10MB/s is the (advertised) guaranteed write rate under the worst SD card data reorganization condition, the equation is:
delay = {max file size} / {10MB/s} * {guarantee factor} + k
therefore
delay = (15 MB / 10MB/s) x 1.1 + k
= 1.5s x 1.1 + k
= 1.65s + k
For the present test I have it set to 1.6s. This may not be enough because there may a constant k that is needed to wait for the pre-write portion of the shoot command. I'd estimate that constant to be at least 300 ms because below this value failure rate is very high (1:4).
Hence by strict observance of the SD spec:
what the delay should really be for
S90 & Duracell 4GB C4 = 1.65 + 300 ms ~=
2 seconds.Of course that will be a huge waste of 1.3 seconds for each myshoot because more than 95% of myshoots will work with a delay of only 750 ms, just above the "fuzzy zone."
Hence the two back-to-back failure incidents I therefore attribute to an incomplete major data reorganization instance on the card that occurred across the boundary between two successive myshoots (4 files totaling about 25 MB).
This result lends very strong support for write detect you have planned direct USB transfer. So no, not CHDK, and no, not Canon .... and ...... not pointless after all, you see?
More perhaps Wednesday.
