How can this be possible...?
And anyway why there is difference between processed and submitted?
It is possible because you can have either 0, or 1 or more than 1 possible "solutions" for a single getwork. What is "abnormally high"?
It would be very useful to know the number of "real" stale shares and the invalid ones to diagnose hw problems.
For example, I've an efficiency of around only 90%: is this an "abnormally low" number?
(I suspect it should be near 100%)
Without -D I guess anything below 3% would be OK, with -D probably more. Stale percentage of 20 for example smells rather fishy. |
|
|
|
|
I would put much more hope in the upcoming 22nm southern islands GPUs. Even if there are no architecture changes at all, theoretically performance per watt ratios could reach up to 4x the current 69xx ones. We might reach 10000 SPs in a dual GPU.
|
|
|
|
|
cur % is the percentage of the keyspace of the current getwork already calculated and checked. You have ~ 4 billion possible nonces per getwork that need to be tried. 50% would mean that we are currently trying nonce ~ 2 billion.
subm is the number of successfully submitted shares. It might be higher, lower or equal to the number of processed getworks.
stale is not quite appropriate as it includes both stale and invalid shares. Under normal circumstances, there shouldn't be any invalid ones, however with higher temperatures and too much OC, it is possible that the hardware starts calculating hashes incorrectly. Abnormally high stale numbers mean that there are hardware problems.
|
|
|
|
|
It should reconnect unless it's the first connection attempt in which case it bails out (as most likely it's due to bad hostname/port). Retry period is 20 seconds.
As for the file redirection, this will never happen as it is rather inconvinient to parse. While I am planning and building a mining rig at home, I am currently extending it to dump status data in a text file in a specific (more easily parsable) format to be used by a couple of monitoring scripts with a web frontend and mail notifications. Still don't know what portion of it will be released though - as I am doing this mostly for my personal use and don't have enough time. Probably only the status exports.
|
|
|
|
|
It should never ever try to run clc alone. clc is invoked (was invoked) by the OpenCL runtime itself. With 2.4, clc is deprecated and it should be not exec'd at all.
Hm it could be somehow trying to use an older SDK. Please check again what the LD_LIBRARY_PATH variable contains (it is the only envvar you need with 2.4 as ATISTREAMSDKROOT one was deprecated). Also, you can check the SDK version in effect by doing:
ldd /usr/bin/hashkill |grep OpenCL
this will print out the exact path to the OpenCL library used.
As for the CPU usage - there are a couple of potential causes for this. One is the SDK itself as it uses spinlocks for synchronization. On linux, there is an environment variable that overrides that behavior, which is set automatically by hashkill. It works on most occasions, but I have seen this failing on some systems though for no apparent reason. On windows, that variable is not available.
Another reason would be the miner itself. I have tried to minimize CPU usage, but indeed there is nothing you can do if the root cause for that is the SDK.
P.S you are advised to play with -G1/-G2/-D flags until you find the ones that best work for you. Basically, -G2 -D tends to be fastest on most systems, but sometimes they may not be optimal.
Unfortunately, windows version is not planned soon.
|
|
|
|
|
Hmmmm...perhaps I should add a build log output option. That's rather strange indeed, it's a generic one and there should be no reason it fails on 5870 while compiling on 5570 for example....
Ah I see now...you are reaching a hardcoded limit for a binary size. OK this will be fixed.
|
|
|
|
|
Yeah, there are some optimizations in the kernel, specific for 2.4 SDK. It should not be failing to build the kernel though, that's rather strange. Did you install the icd-registration.tgz stuff from 2.4?
|
|
|
|
|
Hmm you did not forget to do sudo ./install.sh, not just ./install.sh ?
|
|
|
|
|
What GPU do you have, bolapara?
|
|
|
|
|
It's not hashkill.
Just do smth like:
echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
|
|
|
|
|
BTW...performance is more stable with -D if you switch from ondemand to performance cpu governor. I am not sure the increased CPU power consumption is worth this though.
|
|
|
|
|
Network connectivity restored.
|
|
|
|
Apparently there are connectivity problems. Unfortunately I am away and can't do anything for the next 4-5 hours  |
|
|
|
A bugfix/performance improvement release: * Fixed random crashes when ATI SDK <= 2.3 * Removed some unnecessary code that can lead to performance degradation on multi-gpu systems (or single-gpu ones with -G2 used) * ATI Stream SDK 2.2 supported (without -D) and also SDK 2.1 (without -D) * Improved host code, removed unnecessary synchronization, tuned NDRange, improvement about 0.5% (without -D) up to 2.5% with -D. It now peaks at 279M/s with -D on my 6870, stock clock (previously 272M/s). * Fixed a stupid bug in the long polling code, stales should decrease * Added minor performance optimizations in kernel, available with SDK 2.4 only. * Added some minor tweaks to lower down CPU usage. This would make hashkill a bit more energy-efficient. Known issue: with 32-bit builds, you might experience kernel compilation failures with SDK2.3 (reason:unknown,64-bit version does not have that problem). Just try another SDK. SDK 2.4 is best tested and works flawlessly for both architectures, with any command-line tweaks like -D or -G3. It also tends to be fastest. Known issue: with SDK2.1 and SDK2.2, both 32-bit and 64-bit versions when used with -D are buggy and return wrong results. Please do not use -D with old sdks Known issue: Thermal monitoring fails to map devices properly in some configurations (mostly related to onboard video adapters not supported by OpenCL). Known issue: performance with -D is now more flaky and not as stable as before and desktop is slightly less responsive. This is the tradeoff for higher performance and won't be fixed. Not implemented yet: fail-over extension used in deepbit. Download: 32-bit build: http://www.gat3way.eu/poc/hashkill-0.2.4-x86.tgz64-bit build: http://www.gat3way.eu/poc/hashkill-0.2.4-x86_64.tgz |
|
|
|
|
I use sourceforge's SVN, but I haven't commited the bitcoin code yet
|
|
|
|
if you use linux, with hashkill, you get get 20% more than phoenix, or at least that's what i heard.
That would be impossible unless you compare it to an older version that does not support BFI_INT. Should be no more than 3-4% and there are systems on which the opencl compiler generates underperforming code on hashkill that is slower. Most GPU miners are very well optimized and there isn't much that you can do to improve speed. |
|
|
|
|
No communist state ever existed is a good example of that. There were never good examples and there are not even today (and I can assure you everything beyond that is a matter of propaganda, much more vigilant than you can imagine). Communism is flawed beyond redesign. Well, I guess all the leftist guys that never ever lived through that deserve to do so and see for themselves how this works (bad thing is that even if you reconsider your position, they usually shoot at you at the border if you try to escape that utopia).
This does not necessarily mean that the communist system does not have advantages - oh yes, it DOES have many, like e.g. the better education system (I really mean that). Or like that risk elimination which can be in fact much better for people that don't like taking initiatives.
Overall though it's wicked, it's anti-human and not natural and no wonder why it has collapsed. BTW I don't understand why you claim that the USSR implementation was bad - it was good in a sense that it was self-sustaining for a long period of time. The Latin American experiments would definitely not last that much.
|
|
|
|
|
Hm, don't try -G4, you need really fast CPU for that. It does not matter for bitcoin at all, you are just rising your power consumption for no good use. There are some cases with hash cracking where it helps (again you need fast CPU and lots of RAM). I would not recommend anything above -G2.
OK so -D does not bring much of performance (not enough to round up to the next integer MH/s, 71 that is). It brings about 2MH/s on my 6870 (from 270 to 272) and it brings a lot for 6990. I guess it does not matter that much for slower GPUs.
As for the segfaults....ummm well probably the static-built binary is not really optimal for all users. Probably the best way to get full performance and avoid crashes is to build it yourself like you did. Mmmm this means I should work on the build stuff as currently it's too complicated and makes a lot of assumptions.
Hm BTW just one last question, is your GPU at stock clocks or OC'd ?
|
|
|
|
Looks like the -G1 option fixed this (if I understand correct and the prebuilt version also works with -G1). Unfortunately this is not optimal performance-wise, you are losing about 1.5% due to that (which is not much though, about 1M/s, you are likelly to get more with -D). Well, I am not sure what's the root cause yet. SDK2.3 should be thread-safe, it could be either my code or the ADL library. I am more inclined to blame my code though  Stupid thing is I cannot reproduce that here. OK just one more thing - could you try running that with -G1 -D and also -G2 -D ? I guess -G2 -D would crash, still that would be an interesting experiment. P.S this is the same as the entry in my estimations table though - at least I am glad about that http://www.gat3way.eu/est.php |
|
|
|
|
Hmmm could you try with -G1 command line option?
|
|
|
|
|
Show Posts
