its cause of the aggresion at 16, when I put it on 15 it shows again but the miner is idle a lot according to the log and the khash/s are at 0 however its still mining and getting hashes accepted.
with 14 its working fine but slightly lower mhash/s then with the older one kernel at aggression 17. (417 compared to 418 mhash/s.)
This is because above 12 or 13 is insane aggression - the miner hogs the GPU so much that the Windows GUI can't even draw stuff like the status line on the screen. It was fine with the older kernel. Does that mean anything? I think this kernel is slightly faster then the older one. It is possible that the previous kernel and miner parameters didn't work the GPU so hard; as kernels are optimized, they use more of the GPU resources available, approaching 100%, leaving less chance that OS draw instructions will make it through in a timely fashion. |
|
|
|
I'm having issues keeping my 2nd GPU busy.  Using the above method with the updated miner script for 2.6, I'm able to keep GPU1 at 99% utilization, but GPU2 bounces between 91-98% on my graph. I've put both on their own CPU to see if that would help but it doesn't seem to have an impact. GUIMiner Settings on both: -k phatk AGGRESSION=12 FASTLOOP=false VECTORS2 WORKSIZE=64 Has anyone tried the above with multiple GPU's?? On Vista and Win7, try the command line Start /REALTIME phoenix.exe ... This sets the miner to the highest possible process priority, ensuring that other OS background stuff don't steal any CPU time from the miner sending work to your GPU. Additionally, after the realtime option, you can add the command line option setting single-CPU affinity for each miner. /AFFINITY 01 = first CPU core /AFFINITY 02 = second CPU core /AFFINITY 04 = third CPU core /AFFINITY 08 = fourth CPU core Finally, if you have two console windows open, each with a miner, the selected/highlighted one will get more CPU. Click on the wallpaper so neither are selected. Alternately, under Control Panel -> System -> Advanced -> Performance settings, you can optimize for "background services" instead of "Programs" to avoid a foreground window hogging resources. |
|
|
|
its cause of the aggresion at 16, when I put it on 15 it shows again but the miner is idle a lot according to the log and the khash/s are at 0 however its still mining and getting hashes accepted.
with 14 its working fine but slightly lower mhash/s then with the older one kernel at aggression 17. (417 compared to 418 mhash/s.)
This is because above 12 or 13 is insane aggression - the miner hogs the GPU so much that the Windows GUI can't even draw stuff like the status line on the screen. |
|
|
|
| | worksize: | 64 | 128 | 256 | | phatk2 | VECTORS | 1000MHz | 197 | 205 | 195 | | dia_new | VECTORS2 | 1000MHz | 215.71 | 220.37 | 212.23 |
phatk2 VECTORS WORKSIZE=128: 61.54 MH/s
phatk_dia VECTORS2 WORKSIZE=128: 67.15 MH/s
That corresponds closely with the two-vector results I quote, however in finding the highest output possible from a GPU, VECTORS 4 (@ 64 or 128, depending on card), phatk2 still eeks out a win for me. |
|
|
|
Again, it's pretty clear that someone left some "insufficient funds" sell orders while buying.
I watched the whole thing live too, the sell simply came too quickly.
I wonder why Mt. Gox left such orders open at all, did any real-world exchanges do that?
You mean an "oops, your BTC are now all our fees?" |
|
|
|
6.5(give take .1) can be considered a stable price ?
For small values of stable. That lol.  Seriously, is that a single person paying for the volatility? Looks like 50k of unlimited/panic buying in a situation where there was a downtrend, isn't that hellishly expensive? Spiking above 6.7 instead of slowly filling around 6.2 is 0.5 USD per BTC premium... why the heck? Extreme impatience? For every 10k BTC, that is 5k USD just wasted! Not if that's the last time you can get a Bitcoin for $6.7. Maybe one of these days Bitcoin may cross such a price, never to return that cheap again. Alternately, look back five months, you might say "why are people selling big and dropping the price down to $14 when it's been steady at $17 for over a week?" |
|
|
|
still quits after 10 sec
Its totally buggy
If by "quits", you mean "this version randomly crashes my computer with a frozen screen when using AGGRESSION=12, even at lower overclocks than before", then that's what I see too. I just tested with AGGRESSION=12 and the only problem I can see is extreme desktop lag. (to be expected though, on a GTX 580 this gives a kernel execution time of close to 2 seconds) I would test with higher values but this would trigger a TDR and driver reset due to the kernel execution time exceeding 2 seconds. Can you post your system specs and command line? I haven't really investigated, since this is my main PC where the symptom emerged, the problem only cropped up doing benchmarks, and things still work at an unintrusive phatk2 Worksize=128 Aggression=6 Fastloop=True. I got at least 5 lockups in an hour of testing on both phatk & dia's kernel at worksize=64 aggression=12, usually when clicking any other app but the miner. I would suspect it is something similar to diapolo's 8-27 kernel, where it's optimizations made a previous good overclock unstable (although that symptom was the kernel returning bad hashes). Catalyst 12.1a/OpenCL2.6/Radeon HD 5770 @ 970/970 (stable up to 990/1300)/win7x86/phoenix.exe 1.7.3. Benchmarks and more details of the config. |
|
|
|
What are the chances that Satoshi Nakamoto wrote a dissertation? And if you think he did, what keyword would be in the title of his dissertation?
Game theory: Extracting wealth from a globally-distributed crypto-ponzi? |
|
|
|
The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.
When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message: [13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3 thanks to these lines in __init__.py: # output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT) The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?) Ah, I must have missed some of the files when I was messing around with it trying to fix the delay getting work. The _cl.pyd file is from 0.92. I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip. still quits after 10 sec Its totally buggy If by "quits", you mean "this version randomly crashes my computer with a frozen screen when using AGGRESSION=12, even at lower overclocks than before", then that's what I see too. |
|
|
|
|
See who has an interest in proof-of-work, multiple hashing, partial hash collisions, merkle trees, randomness statistics, and maybe someone who has some wxWidgets programming or even Japanese in their coursework. Bonus hint: email spam micropayments.
|
|
|
|
Do you think Satoshi attended MIT?
Note that the list is graduates in mathematics, not computer science or electrical and computer engineering. |
|
|
|
|
MIT has six people in that list, compared to my alma mater's five....
でも私も日本語が分ります。
|
|
|
|
I have re-uploaded 1.7.3 with this fix applied. The old version of 1.7.3 has been re-uploaded as phoenix-1.7.3_old.zip.
Same hashrate, using -a 100 and running for five minutes until the last digit stops changing, but the reported version is 0.98. Thanks. |
|
|
|
I only started mining on that pool about two weeks ago, and so far have been paid everything I was entitled to. As long as I'm paid for my hash rate, I really don't give a shit what it's used for. The way I see it is we buy pool management service from Luke for a small fee, and he buys our hashing power with bitcoin. If he pays for it, he owns it.
I would consider pure PPS as the only "mining for hire", you agree to mine for a particular payment per share as disclosed on the pool web site. SMPPS is rewarded partially on block finding and the pool reserve, so it deviates from this, and you are more participatory. In a pool where rewards partially depend on pool luck like SMPPS, you aren't getting paid for a block you found if there is merged mining going on behind the scenes. |
|
|
|
|
MagicalTux is Satoshi Nakamoto, of course. English speaker in Japan, who else would choose a Japanese name for a Pseudonym? Runs the big exchange and has extracted the forum from his former alias by "acquiring" it with MtGox...
|
|
|
|
The Windows binaries for Phoenix use PyOpenCL 0.92. I have tried both PyOpenCL 2011.1 and 2011.2, but for some reason they introduce a substantial delay to getting work. These versions also have a 1-2% hashrate loss compared to 0.92.
When running Dia's kernel on the 1.7.3 Win32 exe, it spits out this message: [13/01/2012 12:58:20] using PyOpenCL version 2011.1beta3 thanks to these lines in __init__.py: # output used pyOpenCL version
self.interface.debug('using PyOpenCL version ' + cl.VERSION_TEXT) The hashrate loss in 2011.x is similar to what I've seen running from source, so if 1.7.3 exe has 2011.1, maybe a repackaging can get a bit more hashrate(?) |
|
|
|
hi there,
I'm not sure this is going to work for you, however on my linux rig I was affected by the 100% bug when using Catalyst >12.1 and AMD APP 2.6. I noticed on a quick glance that the problem was pyOpenCL(I got suspicious when running hashkill, which did not have the bug). So I tried using an older version of pyOpenCL which I compiled myself, and it resolved the issue without any impact on my mining performance. I then had a friend mining on windows who complained about the 100% issue himself, and I told him that using a selfcompiled pyOpenCL did solve the problem. He then went on and installed python, a self built windows version of pyOpenCL and ran poclbm himself on windows. (manually without GUIminer). this solved the 100% bug for him as well, without hurting performance. So you might just try doing that if you have some beer and experience to do this. However, no guarantee here, since I only have what my pal reported back to me ...
Phoenix 1.7.3 win32 exe reports that it is using pyOpenCL 2011.1beta; I believe 0.98 was used in older versions, so this may help multi-cpuers. ( Note: Jedi95 fixed, no difference in hashrate) It seems that early reports "11.12 solves CPU bug" may have been premature, as we can see many still have the problem depending on OS, hardware, and miner. |
|
|
|
Why is it so neccesarry for phatk kernal variations to have the memclock at 1k.... Some people cant deal with that extra heat...
This is something that has changed in SDK 2.6; The best performance at the best settings after trying all options comes at a GPU RAM speed of 1000MHz (stock speed for most cards) instead of at an underclock of 300MHz-370MHz. Version 2.6, included with driver 11.12 and 12.1, is significantly different in how it responds to worksizes, vector settings, and OpenCL programming than the previous SDKs. It is a benefit in that one doesn't need oddly tweak memory speeds from stock to get the best performance (annoying to tell noobs over and over to underclock RAM), but bad in that this old quirk was actually an electricity saver if you did it. |
|
|
|
Benchmarks on a 5770 (VLIW5, 800 stream processors, 980MHz core [scales more like 5870 than 5830]), Catalyst 12.1a/SDK 2.6, Phoenix 1.7.3 exe, win7 x32: Typical command line (single cpu affinity, realtime priority): start /AFFINITY 08 /REALTIME phoenix.exe -v -u http://xx/ -k dia VECTORS4 AGGRESSION=12 FASTLOOP=False WORKSIZE=64 | | worksize: | 64 | 128 | 256 | | phatk2 | VECTORS4 | 1000MHz | 223.88 | 226.34 | 181.40 | | phatk2 | VECTORS | 1000MHz | 197 | 205 | 195 | | dia_new | VECTORS4 | 1000MHz | 223.28 | 225.48 | 195.75 | | dia_new | VECTORS2 | 1000MHz | 215.71 | 220.37 | 212.23 | | dia_last | VECTORS4 | 1000MHz | 207.27 | 200.41 | |
less MH/s than phatk2, peak performance at 1000MHz RAM... |
|
|
|
i know from msdn that placing a dll in the same directory as a executable will cause the program to load that dll instead of the one in system32 or syswow64.
Not so fast, Cowboy  http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspxPay close attention to the folowing point: If a DLL with the same module name is already loaded in memory, the system uses the loaded DLL, no matter which directory it is in. The system does not search for the DLL.Copying the file into application directory is not enough if the library from SDK 2.6 has already been loaded into memory. System reboot is mandatory. Only then can you guarantee that the correct library will be used. There are of course ways to forcefully unload a library without rebooting the machine but they are geeky, thus hard to recommend to the general public. In my experience, the DLLs are only locked and loaded when an OpenCL application is running. You can shut down your miner, replace the files, restart your miner, and immediately see the different hash rate of the other SDK. |
|
|
|
|
Show Posts
