With additional debugging (a7629d3490d18a64a5eb2e0e3e0f593190940f0e) we can see that timeouts occur even when the block is still being downloaded (i.e. many examples of download progressing within the last few seconds prior to being disconnected).
debug.log extract:-
02016-12-11 15:36:23.372866 block download timeout. nDownloadingSince=600s nLastRecv=2s nLastSend=40s sipa disconnect peer=38
12016-12-12 13:06:12.458955 block download timeout. nDownloadingSince=900s nLastRecv=2s nLastSend=7s sipa disconnect peer=30
22016-12-12 13:16:03.047371 block download timeout. nDownloadingSince=900s nLastRecv=160s nLastSend=552s sipa disconnect peer=38
32016-12-12 13:16:12.656307 block download timeout. nDownloadingSince=600s nLastRecv=102s nLastSend=2s sipa disconnect peer=31
The debug above is prior to me adding the LastRecvBlk variable, but tests so far show that the data being received is block data at time of disconnection. E.g. the 1200s timeout often disconnects peers currently providing blocks also. This does not imply that it takes >1200s to download a block, as obviously that would be too slow given the average 1MB of block data every 10 minutes, but what can often happen is that internet connections become temporarily slow (e.g. in shared places, such as hotels) and this can cause several blocks to be downloading concurrently, therefore many blocks taking > 1200s to download but still achieving an average download speed of more than 1MB per 10 minutes.
