Transfer shows from 1 ehd to another

smjbh5

SatelliteGuys Pro
Original poster
May 3, 2007
414
5
SF Bay Area
I have 2 ehd on my hopper. Is there a way to move shows from 1 ehd to the other? Or do i have to move them to the hopper first, then to the ehd?
 
You can start the second leg of the transfers as soon as each recording has been moved to the internal.
This requires more of your time but can shorten the start-to-finish time.
You will only take the 1-way transfer time plus the time for the last or last recordings.
(Assumes recordings are about equal in size.)

-Ken
 
Last edited:
Ken:

If you are transferring in and out simultaneously you could slow the process down as the internal drive must service input and output queues which could cause contention issues as these aren't high performance drives. Especially when you consider that there's very little RAM for file system caching of the reads.

Also, that's a lot of time spent monitoring and keeping things going. I'd like to think my time is more valuable, but I could just be deceiving myself.

Sent from my Samsung Galaxy Note 2 using Tapatalk 2.x
 
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.

-Ken

John, edit looking at email version (did you change it?):
"If you are transferring in and out simultaneously you could slew the process siren as the internal drive must service input and output queues which could cause Dundee connection issues as these aren't high performance drives."

I don't recognize siren nor Dundee.

There can be little or no caching as the streams do not repeat in proximity.

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.
-Ken
 
Last edited:
KAB, if you can't say something nice...
Stay out of the conversation.

I say this after reading in the email version from you:
"WARNING: Anyone about to read the above post...please be sure you are stocked up on whatever headache remedy works for you.;)"

And a smiley doesn't help your apparently removed comment.
-Ken
 
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
 
John K, I think we both missed an important point. The external drives are only handling one stream in 1 direction. The internal drive is "designed" for multiple streams, which is what we have transferring to/from the externals. How many? Well, the 3 recording, OTA if available, 2 display streams, PIP if used, and only then add the 3 transfer streams. That's a lot.

I meant encrypting/decrypting for encoding/decoding. Is that on the ASIC? I had impression it was CPU processed and that's what slows the transfer process from the disk speed and it is a lot slower than the read/write speed.

I understand pre-fetch and such. I was thinking of caching for keeping a copy for later use. That just doesn't work with large data sets.

Again the only seeks that would contend are on the internal drive, which we hope Dish programmers have optimized.

Good reading your offerings,
-Ken
 
John K, I think we both missed an important point. The external drives are only handling one stream in 1 direction. The internal drive is "designed" for multiple streams, which is what we have transferring to/from the externals. How many? Well, the 3 recording, OTA if available, 2 display streams, PIP if used, and only then add the 3 transfer streams. That's a lot.

I didn't miss that, the contention is the single internal drive on a SATA II bus, with minimal caching available outside of the drive.


I meant encrypting/decrypting for encoding/decoding. Is that on the ASIC? I had impression it was CPU processed and that's what slows the transfer process from the disk speed and it is a lot slower than the read/write speed.

There needn't be any decrypting of the stream to move data from point A to point B. The encrypted stream is all that needs to be copied from point A to point B. The only time you need the stream "in the clear" is during playback. It is possible that the decrypt routine is part of the ASIC for decoding. I don't know if that is the case though.

There should never be a need for encrypting the stream IMO.

This is based on what I know from my job --- not from any inside information on this product.

I understand pre-fetch and such. I was thinking of caching for keeping a copy for later use. That just doesn't work with large data sets.

Again the only seeks that would contend are on the internal drive, which we hope Dish programmers have optimized.

Good reading your offerings,
-Ken

THere are large data sets, and there are large data sets. The size of these files isn't particularly large to be honest. But the design is resource constrained with the small available RAM for caching.
 
There needn't be any decrypting of the stream to move data from point A to point B. The encrypted stream is all that needs to be copied from point A to point B. The only time you need the stream "in the clear" is during playback. It is possible that the decrypt routine is part of the ASIC for decoding. I don't know if that is the case though.

There should never be a need for encrypting the stream IMO.

...But the design is resource constrained with the small available RAM for caching.
Wish it were true but Dish does not allow disk-to-disk transfers (no such pipe) so it must be decrypted from source and re-encrypted to destination. Curious about the ASIC, too.

The Hopper is a big step in assets from the VIP but yes it is likely still constrained--wish I had gotten HWS just a month later or so.

Dish could have provided a disk-to-disk transfer, but wishes and fishes.

Properly cached the transfers would be at least a factor of 2 faster, I agree.

-Ken