http://forums.macrumors.com/showthread.php?p=6505512
sudo gpt destroy /dev/disk1
sudo diskutil list
sudo diskutil unmountDisk /dev/disk1
sudo gpt create /dev/disk1
diskutil unmountDisk /dev/disk1
sudo gpt add -b 40 -i 1 -s 69632 -t efi /dev/disk1
diskutil unmountDisk /dev/disk1
sudo gpt add -b 69672 -i 2 -s 819200 -t 5265636F-7665-11AA-AA11-00306543ECAC /dev/disk1
diskutil unmountDisk /dev/disk1
sudo gpt add -b 888872 -i 3 -s 1843200 -t hfs /dev/disk1
diskutil unmountDisk /dev/disk1
sudo gpt show /dev/disk1
diskutil unmountDisk /dev/disk1
gpt add -b 2732072 -i 4 -s 485665063 -t hfs /dev/disk1
sudo dd if=efi.dmg of=/dev/disk1s1 bs=1m
sudo dd if=recovery.dmg of=/dev/disk1s2 bs=1m
diskutil list
diskutil eject disk1
gpt remove -i 4 disk1
diskutil eject disk1
gpt show disk1
diskutil eject disk1
gpt add -b 2732072 -i 4 -t hfs /dev/disk1
diskutil eject disk1
newfs_hfs -J -v Media /dev/disk1s4
Monday, October 27, 2008
Thursday, October 09, 2008
Linpak vs. Prime 95
I've done some research on which programs you can use to test your overclock or stock cooling to determine if you have a stable system. Presently, the winner is Linkpak. You can get a copy with GUI front end here.
Setup:
1) BlackIce Xtreme 480
2) Laing DDC 3.25 pump
3) DTek Fusion waterblock
4) Delta AFB1212VHE 120x38mm fan
The fans were run at maximum speed.
CPU at stock was using 123W (measured via current clamp) at it's reported maximum. HWMonitor reported ~119-121W. CPU is rated for 136W.
Using a Striker II Extreme, 4GB DDR2 and a QX9770 the following overclocks were achieved:
CPU at this stage was consuming 143W (via current clamp) and 139W via HWMonitor.
This passed Prime95 quad-core for over two hours.
Running Linpak with 1/4 memory used over 5 iterations resulted in a mismatch (failure).
Increasing the voltage to 1.650V resulted in a pass on Linpak using the 5 iterations, 1/4 memory. CPU was now consuming 156W via current clamp (HWMonitor ~150-153W). The temperature, however, was sitting around 90C when under load per core. Idle was ~40C.
In an effort to see where Prime95 and Linpak diverged from their pass/fail I started decreasing the voltage till Linpak failed and then continued till Prime95 failed.
Each pass of Prime was run for 2 hours. Linpak took less than a few minutes. In an effort to "increase" Linpaks sensitivity I increased it's memory consumption to 1/2 and iterations to 10. This did show a more sensitive failure point.
Linpak's time to run each completed set of tests more than doubled but was still less than 10mins.
During this time Linpak created more heat then Prime95 as well, although Intel still provides tools that actually generate *more* heat then Linpak can do (about 5-10W more).
In the end, Linpak is a great tool and signficantly more sensitive and faster at finding stable clocks then Prime95.
Setup:
1) BlackIce Xtreme 480
2) Laing DDC 3.25 pump
3) DTek Fusion waterblock
4) Delta AFB1212VHE 120x38mm fan
The fans were run at maximum speed.
CPU at stock was using 123W (measured via current clamp) at it's reported maximum. HWMonitor reported ~119-121W. CPU is rated for 136W.
Using a Striker II Extreme, 4GB DDR2 and a QX9770 the following overclocks were achieved:
MHZ X FSB RAM CPU V
4200 10.5 1600 1333 1.5250V
CPU at this stage was consuming 143W (via current clamp) and 139W via HWMonitor.
This passed Prime95 quad-core for over two hours.
Running Linpak with 1/4 memory used over 5 iterations resulted in a mismatch (failure).
Increasing the voltage to 1.650V resulted in a pass on Linpak using the 5 iterations, 1/4 memory. CPU was now consuming 156W via current clamp (HWMonitor ~150-153W). The temperature, however, was sitting around 90C when under load per core. Idle was ~40C.
In an effort to see where Prime95 and Linpak diverged from their pass/fail I started decreasing the voltage till Linpak failed and then continued till Prime95 failed.
VOLTAGE PRIME95 LINPAK
1.650V PASS PASS
1.625V PASS PASS
1.600V PASS PASS
1.575V PASS FAIL
1.550V PASS FAIL
1.525V PASS FAIL
1.500V FAIL FAIL
Each pass of Prime was run for 2 hours. Linpak took less than a few minutes. In an effort to "increase" Linpaks sensitivity I increased it's memory consumption to 1/2 and iterations to 10. This did show a more sensitive failure point.
VOLTAGE PRIME95 LINPAK
1.650V PASS PASS
1.625V PASS PASS
1.600V PASS FAIL
1.575V PASS FAIL
1.550V PASS FAIL
1.525V PASS FAIL
1.500V FAIL FAIL
Linpak's time to run each completed set of tests more than doubled but was still less than 10mins.
During this time Linpak created more heat then Prime95 as well, although Intel still provides tools that actually generate *more* heat then Linpak can do (about 5-10W more).
In the end, Linpak is a great tool and signficantly more sensitive and faster at finding stable clocks then Prime95.
Monday, September 15, 2008
TeraCopy Performance vs. Vista's native file copying
According to Mark Russinovich, the copy operations have been significantly improved for copying files of all sizes in Vista, and then improved again in SP1.
I was curious about this program though and thought I should give an investigation. With TeraCopy's latest version, 2.0a4, I copied a 3.2GB file (email archive -- not in use) and see the results. Using Process Monitor, I monitored the file copy operation as it will give me detailed information as to what is going on in addition to giving me detailed timing information.
Here we can see TeraCopy reads the file at 10MB sizes at 3 intervals then writes out the data the same 10MB per 3 intervals. The read and write are non-cached. This method results in a copy that takes 01:43.5 seconds.
When we examine the copy done by explorer we see that explorer reads the file at a length of 1MB then writes it out in 64kB chunks (cached). This method results in a copy that takes 01:15.5. Almost 30 seconds faster than TeraCopy!
Explorer memory usage.
TeraCopy memory usage.
Reading comments on the Vista copy using memory and pushing out data to disk via the page file I put some performance counters on memory usage and then redid the copy. Doing this we see that explorer.exe does consume more memory during the copy then teracopy.exe (~50MB vs. ~400MB). Teracopy is correct and uses less RAM during copy and Vista could have a detrimental effect during times of low available memory usage. To test this theory I set my Maximum RAM to be about 1.5GB which should cause lots of paging (according to the available memory graph).
The results are: Teracopy.exe continues to use 50MB of RAM while executing and takes a little bit longer (01:46.5 vs. 01:43.5). Explorer actually reduces its memory consumption to 50MB as well during the copy, but instead of it being flat you can see it caching in reads then clearing the cache as it finishes the write as evidenced by the "waves". Explorer finished the copy in 01:28.2.
Seeing Explorer gracefully degrade it's memory usage as it was getting tight is encouraging, but maybe TeraCopy has it right, and if there is absolutely no available memory then maybe it's faster then explorer. To test this I further reduced my available memory to 512MB.
The results are: Explorer.exe continues to use it's reduced amount of RAM (50MB) and the copy time goes up to 01:38.2 (explorer-really-low-memory.jpg). Lastly, TeraCopy.exe's time increased almost a full second to 01:47.2 under the low memory conditions.
*********************************************
IN SUMMARY:
I don't think TeraCopy provides any real value and actually appears to degrade performance under all scenario's compared to using Explorer's native file copy processes. It is quite evident that Microsoft will gracefully degrade the caching algorithm Explorer uses to not consume all RAM while maintaining maximum file copy speed. Using a non-cached copy mode is a huge performance penalty as caching hard drives reads in RAM significantly increases performance for reads and writes as the hard disk has to do less physical movement. Since the hard drive is slowest link in the chain of read and write performance the less you actually need to go to it the better. Paging out data for Explorer appears to be a non-issue as Explorer will instead reduce it's cache to avoid paging during read/writes.
I was curious about this program though and thought I should give an investigation. With TeraCopy's latest version, 2.0a4, I copied a 3.2GB file (email archive -- not in use) and see the results. Using Process Monitor, I monitored the file copy operation as it will give me detailed information as to what is going on in addition to giving me detailed timing information.
Here we can see TeraCopy reads the file at 10MB sizes at 3 intervals then writes out the data the same 10MB per 3 intervals. The read and write are non-cached. This method results in a copy that takes 01:43.5 seconds.
When we examine the copy done by explorer we see that explorer reads the file at a length of 1MB then writes it out in 64kB chunks (cached). This method results in a copy that takes 01:15.5. Almost 30 seconds faster than TeraCopy!
Explorer memory usage.
TeraCopy memory usage.
Reading comments on the Vista copy using memory and pushing out data to disk via the page file I put some performance counters on memory usage and then redid the copy. Doing this we see that explorer.exe does consume more memory during the copy then teracopy.exe (~50MB vs. ~400MB). Teracopy is correct and uses less RAM during copy and Vista could have a detrimental effect during times of low available memory usage. To test this theory I set my Maximum RAM to be about 1.5GB which should cause lots of paging (according to the available memory graph).
The results are: Teracopy.exe continues to use 50MB of RAM while executing and takes a little bit longer (01:46.5 vs. 01:43.5). Explorer actually reduces its memory consumption to 50MB as well during the copy, but instead of it being flat you can see it caching in reads then clearing the cache as it finishes the write as evidenced by the "waves". Explorer finished the copy in 01:28.2.
Seeing Explorer gracefully degrade it's memory usage as it was getting tight is encouraging, but maybe TeraCopy has it right, and if there is absolutely no available memory then maybe it's faster then explorer. To test this I further reduced my available memory to 512MB.
The results are: Explorer.exe continues to use it's reduced amount of RAM (50MB) and the copy time goes up to 01:38.2 (explorer-really-low-memory.jpg). Lastly, TeraCopy.exe's time increased almost a full second to 01:47.2 under the low memory conditions.
*********************************************
IN SUMMARY:
I don't think TeraCopy provides any real value and actually appears to degrade performance under all scenario's compared to using Explorer's native file copy processes. It is quite evident that Microsoft will gracefully degrade the caching algorithm Explorer uses to not consume all RAM while maintaining maximum file copy speed. Using a non-cached copy mode is a huge performance penalty as caching hard drives reads in RAM significantly increases performance for reads and writes as the hard disk has to do less physical movement. Since the hard drive is slowest link in the chain of read and write performance the less you actually need to go to it the better. Paging out data for Explorer appears to be a non-issue as Explorer will instead reduce it's cache to avoid paging during read/writes.
Subscribe to:
Posts (Atom)