The pause feature requested is to be able to stop a 3 hour rebuild halfway through and not start over. The current method of pause does stop the program but you need to start the rebuild all over again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The speed of any PAR2 implementation is dependent on the speed of the CPU and Memory as well as how well optimised the data processing code is.
In the case of par2cmdline, the data processing code has no optimisation built into the way the code is written. The code is designed to be readable, not to be fast.
For QuickPar on the other hand, the data processing code uses hand crafted assembler to eek the maximum amount of processing out of the minimum amount of time.
The speed reported by QuickPar represents the rate at which data is being processed. Processing occurs 32-bits at a time, with each 32-bits of data processed requiring a total of 7 memory accesses. Of those 7 memory access, 4 should hit the CPU's level 1 cache and the other 3 will hit main memory. Therefore the actual memory bandwidth being used should be 3x the reported processing speed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As stated, the speed of each par program varies depending on how well it is programmed but this isn't the substantial effect. The most important measure of time is how big the set vs. how small the block size. Small sets with large blocks don't take but seconds. Large sets with small blocks can take hours. To see how this works, create a new PAR set, add a bunch of files, and slide the block size around to see how it affects the estimated build time. The more PAR data that Quickpar must use, the closer to that shown estimated time it will take to rebuild.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
i do not know if anyone already request it but ok:
Is it possible that the next Par2 (ex. 0.9) programm gets a "pause" button to temporarly "pause" the recovery process ???
ps: Par2 programm is really great!
It has been requested in a previous forum message.
It can already be paused. Press the stop button. When you're ready to resume, place a checkmark in 'Monitor'.
The pause feature requested is to be able to stop a 3 hour rebuild halfway through and not start over. The current method of pause does stop the program but you need to start the rebuild all over again.
3 hour rebuild ? how fast (bytes/sec) is parchive anyway ?
The speed of any PAR2 implementation is dependent on the speed of the CPU and Memory as well as how well optimised the data processing code is.
In the case of par2cmdline, the data processing code has no optimisation built into the way the code is written. The code is designed to be readable, not to be fast.
For QuickPar on the other hand, the data processing code uses hand crafted assembler to eek the maximum amount of processing out of the minimum amount of time.
The speed reported by QuickPar represents the rate at which data is being processed. Processing occurs 32-bits at a time, with each 32-bits of data processed requiring a total of 7 memory accesses. Of those 7 memory access, 4 should hit the CPU's level 1 cache and the other 3 will hit main memory. Therefore the actual memory bandwidth being used should be 3x the reported processing speed.
As stated, the speed of each par program varies depending on how well it is programmed but this isn't the substantial effect. The most important measure of time is how big the set vs. how small the block size. Small sets with large blocks don't take but seconds. Large sets with small blocks can take hours. To see how this works, create a new PAR set, add a bunch of files, and slide the block size around to see how it affects the estimated build time. The more PAR data that Quickpar must use, the closer to that shown estimated time it will take to rebuild.
The time to create or repair is given by:
time = total_size * repair_size / block_size / speed
e.g. for 800MB of source data, a block size of 0.5MB, a redundancy setting of 10% (giving 80MB), and a speed of 200MB/s should take:
800 * 80 / 0.5 / 200 = 640 seconds (or 10.7 minutes)
For 4GB of data, 10% redundancy and a 2MB block size it would take:
4096 * 409.6 / 2 / 200 = 4194 secods (or 70 minutes)