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. |
|
|
|
I think I know what's going on now. P2pool assumes that the miner will not roll ntime more than 10 seconds into the future (because it sets X-Roll-NTime to "expire=10"). At every work request it increments ntime by 12 and returns that.
cgminer doesn't respect the short expire, and rolls more than that. The two programs rolls independently and every so often they clash. Thanks, see my post in the p2pool thread. This is more about interpretation of the expire= parameter than anything else. |
|
|
|
|
Actually this is a major problem. If p2pool is rolling ntime and telling the mining software it can roll ntime, there is nothing to guarantee they wont collide. The expire=10 seconds tells the mining software how long it can roll work for, not how far into the future it can roll time. Potentially the software can roll time up to 2 hours into the future within that 10 seconds, so there can be no guarantee the work source and mining software won't clash. If you're asking the mining software to roll time, you shouldn't be rolling it within p2pool, or vice versa. Since p2pool generates its own work locally, I see no point even asking the mining software to roll the time if it's going to roll it itself. Since rolling time requires a lot less CPU than generating fresh work, it really is a matter of where you want the time to be rolled - the source of the work (in this case p2pool) or the mining software. It should not be done at both ends.
|
|
|
|
Was just curious if they were okay with that.  Yes. That's the closest they came to "sponsorship" of the work. |
|
|
|
Expire was added in cgminer 2.4.4
Expire=10 was a bug in much pool software. It did not make sense at all to have that value for anything but p2pool so the scantime is used if it is longer than expire (expire should be more like 120 seconds). This can't be creating duplicates though.
p2pool has a recent bug where duplicate work items are sent out regardless of the mining software. Anyone on p2pool?
Lots going on folks.... There is always more than meets the eye.
Well yeah, I'm on p2pool. So, if expire doesn't make any sense what headers should be used by p2pool? Should I set --scan-time to 10 perhaps? Neither the p2pool software nor cgminer logs the getwork reply, so I'm adding that and sees what happens. Yes I guess you should set scantime to 10 seconds for now. In a future version I'll actually honour what otherwise appears to be a bogus roll expire time if the pool really wants that. |
|
|
|
cgminer has stale x2 greater than DiabloMiner
on deepbit
(0.24%) Prop.
(0.21%) Prop.
(0.19%) Prop.
(0.23%) Prop.
(0.11%) Prop. - DiabloMiner
(0.20%) Prop.
(0.20%) Prop.
(0.23%) Prop.
(0.22%) Prop.
(0.24%) Prop.
(0.37%) Prop.
(0.22%) Prop.
Try dropping intensity by 1 or number of gpu threads by 1. Perhaps you're just over the efficiency/time to search peak. |
|
|
|
|
Expire was added in cgminer 2.4.4
Expire=10 was a bug in much pool software. It did not make sense at all to have that value for anything but p2pool so the scantime is used if it is longer than expire (expire should be more like 120 seconds). This can't be creating duplicates though.
p2pool has a recent bug where duplicate work items are sent out regardless of the mining software. Anyone on p2pool?
Lots going on folks.... There is always more than meets the eye.
|
|
|
|
|
sdk 2.1 and amd drivers 12.4 onwards are totally incompatible
|
|
|
|
|
Show Posts
