Perhaps CGMiner reports different than what is expected at the pool ? ...in terms of shares submitted ?
Obviously my hash rates seem OK, but my share count in Reaper is NO where near what CGMiner is able to produce.
As a reference, I am using the same Reaper settings as stated above.
I have a 5 card 7970 rig running with a 1800 Shares + 24 Stales in 1520 seconds of runtime...2.6 MH/s
Con, what does the POOL REPORT you as submitting ? (kh/s ?)
1800 shares in 1520 seconds of runtime is a utility of 71 shares per minute TOTAL. However, you don't specify where you're mining as the difficulty target will affect that. |
|
|
|
Are you running the cards all on the same rig? LTC mining is GPU memory bandwidth intensive, if all 4 cards are running at only 1x or 4x or even 8x you'll probably be bottlenecked.
Try using only one GPU in running at 16x.
Indeed it was using quite a bit of memory... investigating further. |
|
|
|
I'm going to ask for my bounty back Considering the bounty only just got reached and I was generous enough to even start working on it before it was reached, some patience would be appreciated since I never guaranteed it would be available yesterday. If not, you can have you money back, as can everyone else. |
|
|
|
not all of us have 7000 series cards so plz test with 5000 and 6000 series cards also can this be released for us to test and can you make it for windows
were not all linux buffs
Hang on a sec while I pull all that hardware out of my arse.... Oh wait, I don't have any of those in there. |
|
|
|
Thanks. Alas I cannot seem to get anywhere near these values with my 7970s. I remain very very sceptical. I can easily push the values up to those hashrates, but the amount of useful shares drops to 10%.
I'm going to ask for my bounty back if CGminer doesn't beat this score: What were your settings? |
|
|
|
have you tried just using reaper with those setting? and not just its kernel, although it shouldn't make a difference.
Same results. |
|
|
|
The request was for a GPU miner so I didn't intend to create a cpu miner.... Having said that, I incorporated the CPU mining code anyway for its sanity checking, but you won't be able to use it unless you compile it yourself once it's released, just like the current cpu mining code. Here's what I'm getting so far from 4x7970s. cgminer version 2.5.0 - Started: [2012-07-21 01:59:22]
--------------------------------------------------------------------------------
(5s):1491.8 (avg):1391.3 Kh/s | Q:157 A:16893 R:117 HW:0 E:10760% U:1276.5/m
TQ: 15 ST: 16 SS: 0 DW: 108 NB: 10 LW: 2508 GF: 0 RF: 0
Connected to http://lc.ozco.in:9332 with LP as user ckolivas.0
Block: 3481059ff985cf07dc7c223dba82c6c4... Started: [02:10:37]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 54.0C 5371RPM | 364.5/346.6Kh/s | A:4176 R:24 HW:0 U:315.54/m I:-3
GPU 1: 54.0C 5417RPM | 374.6/350.2Kh/s | A:4294 R:32 HW:0 U:324.46/m I:-3
GPU 2: 52.0C 5308RPM | 374.3/349.2Kh/s | A:4295 R:24 HW:0 U:324.54/m I:-3
GPU 3: 48.0C 5295RPM | 381.0/352.4Kh/s | A:4228 R:37 HW:0 U:319.47/m I:-3
--------------------------------------------------------------------------------
Note that you can increase the hashrate further, on both this and reaper BUT it starts generating garbage. I know people have claimed higher hashrates, but be wary of these claims and look at that successful share submission rate. My mining rig is really struggling behind the weak wifi it runs off when trying to submit 1300 shares per minute. I'll be tweaking the command line settings so they mean something more useful though since intensity of -3 will be rather confusing, so I'll change the scale for scrypt. There are settings for which reaper does not return high quantities of stales at high aggressions with few stales, they were being posted up on BTC-e the other day. As I recall the thread concurrency used was something around 10240 (maybe slightly higher, but still around 10k). edit: here they are, for ~450kh/s worksize 256 aggression 13 threads_per_gpu 4 sharethreads 18 lookup_gap 2 gpu_thread_concurrency 8192 and for 650kh/s worksize 256 aggression 13 threads_per_gpu 5 sharethreads 18 lookup_gap 2 gpu_thread_concurrency 10240 You must use the 12.6 drivers and the latest SDK to get these hash rates Thanks. Alas I cannot seem to get anywhere near these values with my 7970s. I remain very very sceptical. I can easily push the values up to those hashrates, but the amount of useful shares drops to 10%. |
|
|
|
Atm the reaper opencl code sucks. My 5870 generates about 420kh/s, to use as a reference. So it should be getting like 6-700 or more from a 7970.
But how many accepted shares does it generate at that alleged hashrate? |
|
|
|
The request was for a GPU miner so I didn't intend to create a cpu miner.... Having said that, I incorporated the CPU mining code anyway for its sanity checking, but you won't be able to use it unless you compile it yourself once it's released, just like the current cpu mining code. Here's what I'm getting so far from 4x7970s. cgminer version 2.5.0 - Started: [2012-07-21 01:59:22]
--------------------------------------------------------------------------------
(5s):1491.8 (avg):1391.3 Kh/s | Q:157 A:16893 R:117 HW:0 E:10760% U:1276.5/m
TQ: 15 ST: 16 SS: 0 DW: 108 NB: 10 LW: 2508 GF: 0 RF: 0
Connected to http://lc.ozco.in:9332 with LP as user ckolivas.0
Block: 3481059ff985cf07dc7c223dba82c6c4... Started: [02:10:37]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 54.0C 5371RPM | 364.5/346.6Kh/s | A:4176 R:24 HW:0 U:315.54/m I:-3
GPU 1: 54.0C 5417RPM | 374.6/350.2Kh/s | A:4294 R:32 HW:0 U:324.46/m I:-3
GPU 2: 52.0C 5308RPM | 374.3/349.2Kh/s | A:4295 R:24 HW:0 U:324.54/m I:-3
GPU 3: 48.0C 5295RPM | 381.0/352.4Kh/s | A:4228 R:37 HW:0 U:319.47/m I:-3
--------------------------------------------------------------------------------
Note that you can increase the hashrate further, on both this and reaper BUT it starts generating garbage. I know people have claimed higher hashrates, but be wary of these claims and look at that successful share submission rate. My mining rig is really struggling behind the weak wifi it runs off when trying to submit 1300 shares per minute. I'll be tweaking the command line settings so they mean something more useful though since intensity of -3 will be rather confusing, so I'll change the scale for scrypt. |
|
|
|
I guess theoretically it may be possible that there's an overclocking zone where the GPU doesn't freeze but doesn't compute the hashes correctly either and misses some shares (an error occasionally flipping one bit of the resulting hash to 1 even if it should be a 0 could reduce the utility while being undetectable by the miner software).
Even if possible I suspect this isn't very common : the error must be located in the last stage of the sha256d computation and only affect high bits to exhibit this behavior and not a simple hardware error as detected by miners (where a share candidate doesn't pass the software-only check). I don't know enough about OpenCL to guess if the way the OpenCL compiler works may make it more probable though (hash results may end up in registers/memory cells statistically more prone to errors for example).
Hardware errors would easily reveal this being a problem though. I would definitely advise to keep clocks below a level where HW errors start appearing. If you're not getting HW errors, there is no real mechanism for a lower utility at a higher hashrate. |
|
|
|
|
I've tried 2 approaches to the opencl kernel. First I ported reaper's kernel which should have been the least work but it kept returning garbage responses. Secondly I ported the entire scrypt c code to opencl code and had the same thing happen. Something I'm doing wrong in passing parameters to it or something but I've audited them hundreds of times and can't see wtf I'm doing wrong. Code is NOT public yet while it's a mess and in flux and the bounty is being collected.
|
|
|
|
|
I've had more than a "bit" of a crack at doing this since the bounty was started and I've gotta say it's far from trivial. I grossly underestimated how much effort it would take and am currently stumped by various failures with my attempts so far.
|
|
|
|
Sometimes,also, with a lower overclock setting and lower hashrate you will get a higher Utility.
Sam
Care to explain how that works? No,I can't explain how that works, but, ckolivas posted a suggestion a while back. He said that once you find your max GPU Engine clock that your card runs stable at try to drop your GPU clock 5Mhz at a time to see if there's a sweet spot where your Utility increases. I tried that and I did find a spot where my Utility went up a little at a lower GPU Clock. Maybe ckolivas could elaborate on that? YMMV, Sam I did not ever say that. I said there are certain engine/memory clock combinations where the hashrate rises more than linearly with engine clock speed with the unorthodox kernels like phatk. Utility is hashrate * random luck and it should just be linearly related to hashrate. |
|
|
|
 Tell me how do I fix this? windows 7 x64, version 2.5.0 #define CL_OUT_OF_HOST_MEMORY -6 Dunno what you're doing to suffer that. Probably too high intensity and/or worksize or something else... |
|
|
|
|
No, I'm pretty sure the ztex bug is a different thing.
|
|
|
|
|
We're still disagreeing about what the "expire=" means. cgminer can roll up to 7000 seconds into the future, but will only work on rolled work for $expire seconds before discarding it.
|
|
|
|
|
I don't understand. If p2pool can roll the time locally fast enough, there should be no need to tell the mining software to roll the time at all. Alternatively, if you let the mining software roll the time, why should p2pool roll time at all? There's some kind of catch 22 thing going on here, and yet it should be very low overhead to roll the time. Something is missing in this equation. The mining software should report if it supports nrolltime in X-Mining-Extensions: "longpoll midstate rollntime submitold". If it supports rollntime then p2pool should not be rolling the time itself and allow the miner to do it by advertising X-Roll-Ntime (potentially with some expire= but just "Y" should suffice here). If it does not support rollntime, then p2pool should roll the time itself and not advertise X-Roll-Ntime.
|
|
|
|
A damn fine bazillion moment there, congrats!  |
|
|
|
|
I would think you're better off making p2pool not roll ntime and leave it to the mining software.
|
|
|
|
I have the same 2.4.4 and 2.5.0 causing massive problems
So went back to 2.4.3 which seems the only good version for now
Well that's rather non-specific. Information regarding hardware, command line options and debugging output run with "--verbose --debug -T" added might be helpful, as it says in the readme. |
|
|
|
|
Show Posts
