Difference between revisions of "ICH"

From AMule Project FAQ
Jump to: navigation, search
(Language corrections.)
(What are its results?)
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
 +
<center>
 +
'''English''' | [[ICH-de|Deutsch]]
 +
</center>
 +
 
== Description ==
 
== Description ==
  
Line 12: Line 16:
 
== What are its results? ==
 
== What are its results? ==
  
The best that can happen with ICH is that the first 180KB in the [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] are the [[corrupt]]ed ones. If so, only 180KB have to be redownloaded out of the 9.18MB the whole [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] is in size.
+
The best that can happen with ICH is that the first 180KB in the [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] are the [[corrupt]]ed ones. If so, only 180KB have to be redownloaded out of the 9.28MB the whole [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] is in size.
  
The worst case sould be when the last 180KB of the [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] are the [[corrupt]]ed bytes. In this case, the whole [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] has to be redownloaded. Anyway, since redownloading the whole [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] would have to be done anyway if ICH had been disabled, this is not a loss at all (except for some little CPU resources).
+
The worst case should be when the last 180KB of the [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] are the [[corrupt]]ed bytes. In this case, the whole [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] has to be redownloaded. Anyway, since redownloading the whole [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]] would have to be done anyway if ICH had been disabled, this is not a loss at all (except for some little CPU resources).
  
 
== Is it useful? ==
 
== Is it useful? ==
Line 22: Line 26:
 
== Is it CPU expensive? ==
 
== Is it CPU expensive? ==
  
Not at all. On any modern CPU, hashing the [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]]s takes less resources that you would imagine. Since it saves 50% corrputed data in average (and can even save up to 99%) and the hashing process is only done from time to time when necessary, the resources it makes use of are practically null.
+
Not at all. On any modern CPU, hashing the [[FAQ_eD2k-Kademlia#What_is_a_chunk?|chunk]]s takes less resources that you would imagine. Since it saves 50% corrupted data in average (and can even save up to 99%) and the hashing process is only done from time to time when necessary, the resources it makes use of are practically null.
  
 
Even on old CPUs you should still take into consideration not disabling ICH, since the amount of CPU it takes, compared to the amount of [[corrupt]]ed data it might save, is far enough to keep it active.
 
Even on old CPUs you should still take into consideration not disabling ICH, since the amount of CPU it takes, compared to the amount of [[corrupt]]ed data it might save, is far enough to keep it active.

Latest revision as of 10:29, 10 May 2008

English | Deutsch

Description

When a chunk is downloaded and results corrupted, aMule would normally redownload the whole chunk (9.28MB) in order to get the file correctly. ICH (Intelligent Corrupt Handling) is a workout to avoid redownloading the whole chunk when possible.

How does it work?

Once a chunk is known to be corrupt, it begins to redownload it. Instead of dropping the whole already-downloaded chunk, it keeps it and deletes the first 180KB. It then downloads the first 180KB of that chunk again.

Once it has downloaded it, it will add it to the rest of the already downloaded chunk and hash it, to see if the resulting hash is the same as the hash it should have. If it is, the chunk has been successfully completed. If it is not, then it will download the next 180KB of the chunk and so on.

What are its results?

The best that can happen with ICH is that the first 180KB in the chunk are the corrupted ones. If so, only 180KB have to be redownloaded out of the 9.28MB the whole chunk is in size.

The worst case should be when the last 180KB of the chunk are the corrupted bytes. In this case, the whole chunk has to be redownloaded. Anyway, since redownloading the whole chunk would have to be done anyway if ICH had been disabled, this is not a loss at all (except for some little CPU resources).

Is it useful?

It is said that it saves up to 50% of the corrupt downloaded chunks on average, which means that out of every 100MB of corrupted data, only 50MB are redownloaded. Which is quite good!

Is it CPU expensive?

Not at all. On any modern CPU, hashing the chunks takes less resources that you would imagine. Since it saves 50% corrupted data in average (and can even save up to 99%) and the hashing process is only done from time to time when necessary, the resources it makes use of are practically null.

Even on old CPUs you should still take into consideration not disabling ICH, since the amount of CPU it takes, compared to the amount of corrupted data it might save, is far enough to keep it active.

To disable it, go to Preferences -> Files -> ICH -> ICH active (disable)

Aditional notes: Take a look at the AICH documentation since AICH is the evolution of ICH.