aha! It's the nonce I haven't discovered yet. That isn't in the stratum protocol, which is why I missed it.
So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce. That's plenty of space.
Normal 4 byte nonce. thank you. I take modern miners are aware if they reach the end of the space for the nonce and then increment something else, like ntime? M No need, as 8 bytes total is already a ridiculous amount of hashes. |
|
|
|
aha! It's the nonce I haven't discovered yet. That isn't in the stratum protocol, which is why I missed it.
So that means the proxy tells the worker you have a pool minus 2 byte counter to work with, and then the miner uses that and the normal 8-byte nonce. That's plenty of space.
Normal 4 byte nonce. |
|
|
|
|
You are mining bitcoins with GPUs which no one informed today would be doing due to the massive difficulty in the current bitcoin network which is why no one's around to help any more. If you want to get back into bitcoin mining affordably, buy yourself a USB stick like the AntminerU2 instead which does 2GH for much less cost than your GPU and use your GPU for graphics the way it was intended.
|
|
|
|
|
It's virtually impossible to mine blocks with a CPU full stop, and it is no easier to mine blocks without transactions.
But yes, it is possible to mine blocks with zero transactions, but then that would defeat the purpose of mining, which is actually to proliferate transactions and secure the network, and the block reward is a reward for their work, though miners seem to forget that... If enough people/pools mined blocks with zero transactions it would make bitcoin suffer and the value drop as a result of lost confidence in its reliability and whoever was mining them would lose indirectly due to the drop in value.
|
|
|
|
|
The question was rhetorical. Only altcoin miners and botnets are cpu mining these days, neither of which is relevant here.
|
|
|
|
|
Share diff is chosen by the pool to find an optimal spread between bandwidth to the pool and variance to the miner. The choice of value chosen by the pool is arbitrary but most target diff to work out to somewhere around 20 shares submitted by the miner per minute. Difficulty of the share submitted is paid only based on the share difficulty asked for by the pool, though it can be much much higher (and ideally higher than the network difficulty in order to solve a block for the pool). Difficulty is internally determined in cgminer by checking the ratio of the share hash to diff1 where diff 1 is 26959535291011309493156476344723991336010898738574164086137773096960. Imagine every share's hash is just one massive number.
The 65536 constant mentioned earlier has nothing to do with bitcoin. Ignore it.
|
|
|
|
I do recall a push by the bfgminer author to put longpoll into the bitcoind client to inform mining software of block changes but no such thing exists, so perhaps he does nothing special to make sure you're working on a new block. Cgminer checks every 0.5 second when mining solo to bitcoind.
Can cgminer be set up to mine with a network device? (I have ASICminer Block Erupter Cubes) I wanted to try it but I think I would need a miner that I could connect directly by USB to my computer running cgminer. I don't see an option to specify a network port where it should listen to my miners... Or is there a way to use it with BE Cubes? Nope, cgminer doesn't act as a proxy to other mining software (and the cubes have their own primitive mining software). |
|
|
|
Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.  The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something. Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first. Maybe a "T" hotkey to do a toggle? Thanks again, Sam You can already toggle it from the display menu. |
|
|
|
I've been testing version 4.2.2 for 2 days now and it looks like the memory utilization is stable at 16.5 MB RAM with GBT now. Also it seems stable and reliable with BE's. I would still like the ability to sign the block though. Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit. I sent a donation for solo mining support. Thanks Sam. The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something. Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first. |
|
|
|
|
We (the cgminer developers) don't own, were never offered a twinfury or had support sponsored, nor had anyone push code for them, so there is no support for the device in cgminer, though the device type 03eb:204b comes up the same as one of the other devices cgminer knows which is why it tries to initialise it as something else and fails (since most manufacturers don't bother putting a unique identifier and all cgminer gets to see is the communication chip identifier). I doubt it would take much code to get it going, but there's no path for it to happen at this stage, and I don't know if they're even in production any more.
|
|
|
|
I think its honestly just a compatibility issue with the getwork software poolside.
The miner is showing actual hashrate clientside and then share hashrate poolside and its submitting shares at a rate of 16gh aka 1.06% share submission rate(99% stales/rejects). My guess...
getwork has nothing to do with modern mining. It's almost certainly just a minimum share diff in their broken driver implementation, as discussed before. |
|
|
|
but but...there was some network protection statement about KNC and their mining operations.)
See with their new found logic they're protecting the network by increasing the overall hashrate. |
|
|
|
If someone wanted to get per-chip statistics, the better way would be to have a dynamic list, which grows automatically when a new chip is mentioned in the results.
Of course, with the number of chips growing into the hundreds, the value of knowing exactly what happens in each individual chip starts to diminish. EDIT: also, measuring these statistics in the driver, with a high difficulty setting, produces very erratic per-chip results, unless you measure over very long times.
I'm well aware of ways to work around it, but I don't think anyone's using the data so with so much else to work on, unless it's requested I'll just leave it as is. |
|
|
|
I was referring to how its sent its work from the controller. If the controller can process more data then it can provide faster workloads and yield higher hash-rates?
such as for a controller the ras pi is 30 flops
this paralle board is 90 flops...can this be a faster system with gridseeds attached...
Controllers don't need much power at all to send and receive work. The cointerra (which is currently the single most powerful standalone mining hardware) uses a beaglebone black to produce 1.6TH. Bad design implementation (hardware and driver) is the only reason one might need lots of power in the controller. |
|
|
|
...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...
All drivers return the number of hashes done. You must have messed something (else?) up somewhere. Not true - BaB driver returns the nonces found: hashcount += 0xffffffffull * babinfo->new_nonces; My driver was returning the actual hashrate of the chip, which does not change with the luck and hardware errors, but with voltage fluctuations only. I have switched to nonces found and provide the actual hashrate separately now. (EDIT: it doesn't fluctuate much anyway) No driver directly displays the raw hashrate because virtually every piece of hardware has a wastage rate, be that lost work or hardware errors, and as a rule in our mainline drivers only the effective hashrate is shown based on share return since that is the one that most accurately represents the effective useful hashrate to the miner. Some drivers like to have their raw hashrate in the API as well but it's mostly used for debugging or finding when a large discrepancy occurs between that and the share based return hashrate. The most comprehensive hashrate breakdown exists in the cointerra driver, as per the example below: From API devs (all drivers get this from cgminer but it's still a share based hashrate): [MHS av] => 799191.36
[MHS 5s] => 835744.05
[MHS 1m] => 802133.15
[MHS 5m] => 814257.17
[MHS 15m] => 813622.90
From API stats (device specific implementation): [Calc hashrate] => 809023317013
[Hashrate] => 809235851416
[Share hashrate] => 799187431945
[Total calc hashes] => 66713335626117819
[Total hashes] => 66730861547342974
[Total raw hashes] => 66856703711606415
[Total share hashes] => 65902253067730944
[Total flushed hashes] => 5497557985280
[Accepted hashes] => 66573727231544920
[Accepted hashrate] => 807330305483
[Rejected hashes] => 370758174404046
[Rejected hashrate] => 4496132673
[Core0 hashrate] => 98977953653
[Core1 hashrate] => 72667358378
[Core2 hashrate] => 101483724632
[Core3 hashrate] => 102736610121
[Core4 hashrate] => 101483724632
[Core5 hashrate] => 120277006971
[Core6 hashrate] => 85196213271
[Core7 hashrate] => 96472182675
[Asic0Core0] => 120:fffefffefffefffefffefffefffefffe
[Asic0Core1] => 120:fffefffefffefffefffefffefffefffe
[Asic0Core2] => 120:fffefffefffefffefffefffefffefffe
[Asic0Core3] => 120:fffefffefffefffefffefffefffefffe
[Asic1Core0] => 120:fffefffefffefffefffefffefffefffe
[Asic1Core1] => 120:fffefffefffefffefffefffefffefffe
[Asic1Core2] => 120:fffefffefffefffefffefffefffefffe
[Asic1Core3] => 120:fffefffefffefffefffefffefffefffe
|
|
|
|
I'll leave it as is then  Only real concern is trying to write outside the bounds of the array and causing corruption but I think I accounted for the possibility of illegal values already. |
|
|
|
|
One can mine bitcoin through proxies. Your other questions are offtopic in this forum section.
|
|
|
|
The protocol is exactly the same as for the bi*fury devices (and also the same for the One String Miner), so cgminer already supports them.
The code assumes 2 job queues so I assume you worked within that framework despite the extra chips? Not sure where the 2 job queues come from, but the firmware internally uses a single queue with room for 4 jobs. That's the same on bi-fury and hex-fury. The only difference is that the hex-fury jobs are processed faster because there are more chips, but this should be transparent for the driver. I wrote the driver for BXF aka Bi*fury at the time and while it sends enough work based on the request for more work, it stores data in its API assuming 2 chips exist because that's all the original devices had. As I said earlier, it probably only affects the data that's shown in the API. A string of invalid chip number messages in verbose mode and lack of debug support for the extra chips is likely the only consequence, but I don't know how many people ever looked at the API output of these devices which I originally added to aid debugging of which chip was doing what: [STATS3] =>
(
[STATS] => 3
[ID] => BXF0
[Elapsed] => 79099
[Calls] => 0
[Wait] => 0.000000
[Max] => 0.000000
[Min] => 99999999.000000
[Version] => 1.2
[Revision] => 1
[Chips] => 2
[NonceRate] => 0.663417
[NoMatchingWork] => 0
[Temperature] => 48.400000
[Max DeciTemp] => 525
[Clock] => 54
[Core0 hwerror] => 598
[Core1 hwerror] => 142
[Core0 jobs] => 8458
[Core1 jobs] => 8227
[Core0 submits] => 5239
[Core1 submits] => 5581
[USB Pipe] => 0
[USB Delay] => r0 0.000000 w0 0.000000
[USB tmo] => 46161 0
)
EDIT: Shouldn't be hard for me to generically change it to as many chips are reported in chips, but I believe some earlier samples/firmware didn't report that so I'll add a workaround. |
|
|
|
Slushs pool holds too small a market share of hashing. Slushs is only 2% of the hash power... its only going to get worse as the two or three largest hashing pools get even bigger. Ghash, BTC Guild, and Discus... Heck even Eligius are way to big. Its unfortunate that they could not have worked some more even distribution limits into the BTC math to keep it more evenly distributed. Those big ones should burn to the ground... seriously... They should all burn...
While I agree more decentralisation is ideal, there is no way to stop people from pointing their hashes wherever they want, and market forces dictate this more than any logical reason. |
|
|
|
|
Show Posts
