There is probably a lot of slack in the transfer that can be used to keep (both) / all streams active. What about the encoding/decoding times that can be overlapped with the transfers? CPU usage vs. channel transfers, assuming they have transfer channel(s)? We know it runs much more time than the actual transfer time to move a show.
Decoding isn't done on CPU, it's done on an ASIC (Application Specific Integrated Circuit). I think it's a Broadcom that does that work. So the data is passed off to the Broadcom.
I have no idea what you are talking about when you mention encoding. The recordings are the output of the single stream from the transponder for the channel (non PTAT/Locals) or multiple channels (PTAT/locals). They are just bitstreams at the disk level.
John, edit looking at email version (did you change it?):
Yeah, the keyboard app updated on my phone and I'm making lots of crazy boo boos with typing the last few days.
There can be little or no caching as the streams do not repeat in proximity.
I think you need to do a little reading on file system caching (FS Cache) algorithms
Warning: The next section is grossly oversimplified.
When you're using a file system cache you're reading additional blocks hoping that what you need is there so that you don't have the
very expensive read from disk if you can avoid it. Because the files are laid down contiguously, you get decent cache utilization -- but it is limited by the small amount of system memory.
Still, you have the contention of seeks back and forth to keep the cache populated as you write through the new data to disk from the transfer. So your heads are pivoting between block set A and block set B. This is where the contention issue comes into play. We haven't brought into discussion other hits to the disk which are also going on.
I don't have the appropriate environment to demonstrate it, but you will find that the time grows significantly based on the overall utilization of the system.
I was really suggesting that after say 1/2 of files are transferred, you could start the other leg of the transfer. This would take you only a few seconds of monitoring and set up for each half but would remove 1/3 to 1/2 of the elapsed time--1st guess.
Getting back full control of the drives being the objective.
It's possible, but I have serious doubts about that amount of time being saved when dealing with a single medium speed spindle getting hit with input/output simultaneously on a system with seriously constrained memory resources.
Sent from my ASUS Transformer Pad TF700T using Tapatalk HD
"
