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. |
|
|
|
|
One thread on this is enough. Please lock this one and point to the other.
|
|
|
|
this makes me sad now. I had much better earnings when i was able to use the software provided dependably. this is why i keep asking for it to return. But dr says it should work fine. it must be something on my end causeing issues.
i already obtained 1.4mhs. cpu with your software. it's not just the software but system configurations (unlocking your os) and hardware potential.
i've already withdrawn,,,for last year...i was hopeing to enable better earnings this year. I guess you can pm me suggestions for other cpu miners. google hasn't been helpful. i end up finding virueses and trojans instead.
How on earth are you making money CPU mining bitcoin now? That hasn't been profitable in years. Even with free electricity you can only earn about 1 cent per month with a modern CPU. |
|
|
|
On cgminer it for the most part shows up properly but drops the pool connections frequently. That doesn't make sense if you're implying the driver somehow causes this. What do you mean drops the pool connections? Most stratum connections on cgminer stay up for weeks when pools are stable. |
|
|
|
|
The more outgoing connections your bitcoind has, the faster it will pick up the block (provided you don't exhaust your bandwidth), and even better if you can find a supernode with ultra fast connection and consciously try and make your bitcoind detect it. Most of the bigger pools do that to minimise their risk of creating orphans.
|
|
|
|
There were some generic changes done to the windows libusb for 4.2.2 but no one has tested them or reported back.
Further to this discussion, are there any windows users who can confirm any change or otherwise of the latest version? Specifically any change from working to non-working, or those with USB3 slots that previously never worked that have tried this version? |
|
|
|
|
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.
|
|
|
|
No point stickying information on hardware that is only of historical value to bitcoin mining. |
|
|
|
|
Show Posts
