Regarding this from the 1.2 release thread
* Make PTP not use 50% of available RAM for buffer if there's lots available.
I did some investigation. Conclusion is basically that download performance is better with larger buffer size, up to at least 1mb or so. I tested both downloading a DNG file (which does file IO in units of the "buffer size") and using GetMemory (which still sends in "buffer size" units, even though it doesn't do any actual buffering)
Attached patch is the code I used for testing.
To time, i used the following in chdkptp
set cli_xferstats=true
set cli_time=true
To adjust the (max) size of the buffer
=set_usb_buf_max(1024*1024)
note it will still be capped at 1/2 ram, so you need to check how much you have free. For 1mb or more, exmem is recommended...
to test download speed
d -nolua DCIM/100CANON/CRW_nnnn.DNG
to test rmem speed
!con:getmem(0x1900,1024*1024)
Some results on D10
DNG file (18,801,888 ),
32k buf = 4.8 sec
64k buf = 4.2 sec
128k buf = 3.8 sec
512k buf = 3.5 sec
1m buf = 3.4 sec
Above is all with camera in playback mode, record mode is notably slower (~6 sec with a 32k buffer). I've seen the same effect in other situations, so this isn't a surprise.
I tested uploads too, but the difference was much smaller, possibly due SD writes being significantly slower.
rmem
1m data, 1m buf = 0.032 sec
1m data, 64k buf = 0.059 sec
In the end, I decided not make any changes in the trunk for now. It would be nice to be able to control it, but doing something useful would be a bit complicated. For max performance, you might want to allow > 1/2 free mem, while if you had a complicated script or shooting running at the same time, you might want to limit it to less.
I did notice that remote capture is using send_ptp_data (which always writes in buffer_size chunks) rather than calling data->send_data like live view. I suspect it could be sped noticeably using the latter, unless it all has to fit in some internal buffer.
