Looks like CGMiner broke other things in 2.5.0, killing performance on BFL Singles and declaring ModMiners sick. If you use either of these FPGAs or encounter other problems ( please report them!), feel free to use 2.4.4 until I get them resolved: I have many singles running at all kinds of different firmwares, and they seem to be operating at the proper hashrate/U they always have, regardless of pool, or miner. Whether it be CG, BFG, 2.4.4, or 2.5.0. Are you certain something is amiss? Until I figure out exactly what's going on, I can't be certain. So far I've just observed that my hashrate is much worse with 2.5.0 than it was with 2.4.4. |
|
|
|
For some reason when I use 2.4.4 and save out the configuration file. When I restart it comes up with fatal JSON error.
And I have to enter all my pools again.
Phil
Can you PM me the config file it writes (with passwords X'd out)? |
|
|
|
Wrong.
...
Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing
If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.
Well, in my setup, on Windows 7, abort time changes the hash rate. the utility does not change much, but hash rate is very sensitive to abort time. Abort time lower than 8 seconds (80), increases the hash rate, higher than 8 secs (80) lowers the hash rate. BTW, I've played with many timings, and 6.5 seconds abort time produce best utility rate. I don't care about the hash rate reported by the cgminer. Number of submitted, valid shares per minute is what makes money. So who cares if cgminer is reporting 410 or 210 Mh/s. If utility is 5.35, I'm a happy camper. On Windows 7 (64bit), the new icarus code barely gets utility of 5. Kano, maybe you optimized too much for Unix and Windows performance took a hit. It takes about 3 days to get Utility precision to even 1 decimal place on a single Icarus. I've seen both CGMiner and BFGMiner 2.4.4 keep well over 5 Utility on average (and I'm pretty sure there weren't any changes to this in 2.5.0) |
|
|
|
What version of cgminer works with the new firmware. I'm still using the mmq special version at the moment. I recommend BFGMiner 2.4.4 at the moment, though CGMiner 2.4.4 should also work and depending on the circumstances 2.5.0 of either might work. |
|
|
|
Looks like CGMiner broke other things in 2.5.0, killing performance on BFL Singles and declaring ModMiners sick. If you use either of these FPGAs or encounter other problems ( please report them!), feel free to use 2.4.4 until I get them resolved: |
|
|
|
We have a working firmware for testing.It only works at up to 200 MHz, and doesn't support temperature sensors yet, but it should be able to get you guys up and mining on your ModMiner Quad immediately. Download the firmware binary hereInterested programmers can see the source code hereUpgrade instructions (Linux):- Install GNU mtools on your host system: sudo apt-get install mtools
- Hold BOTH the buttons (orient the board so these are facing you)
- Release the left/Reset button, while still holding the right/ISP button
- Release the right/ISP button (ISP)
- Unplug USB and plug it back in, the board will now show up as a mass storage device (note it may take a minute to show up!)
- Use mtools to delete the old firmware: mdel -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0 ::/firmware.bin
- Use mtools to copy the new firmware: mcopy -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0 modminer-20120709-50c63a3.bin ::/
- Ensure the data is flushed to the USB: sync
- Unplug USB, hit the Reset button, and plug USB back in
Upgrade instructions (Windows):- Hold BOTH the buttons (orient the board so these are facing you)
- Release the left/Reset button, while still holding the right/ISP button
- Release the right/ISP button (ISP)
- Unplug USB and plug it back in, the board will now show up as a mass storage device (note it may take a minute to show up!)
- Open the MSD and you should see one file named firmware.bin
- Delete firmware.bin and copy the new firmware file to the device
- Unplug USB, hit the Reset button, and plug USB back in
|
|
|
|
Moores law man (kinda). At some point ASIC will become the "new" GPU and it will have to be upgraded or completely changed at some point. Will it destroy bitcoin? That was just a title to entice readers. It will only strengthen competition for miners which can only be good right?
And what can be wrong with strengthening the power of the miners? It will only make it more difficult for a 51% attack.
you don't use ASICs for gaming how will it strengthen competition for miners? strengthen competition amongst the 2% that are left? who cares about a 51% attack when nobody cares about bitcoins anymore? surely i'm not the only one that solely became interested because I could use my existing equipment to procure my 'own' bitcoins i wouldn't have thought twice about it had it required some POS that was useless otherwise. ed: (and why in the hell would more people have ASICs than GPUs, making a "51% attack" less likely? since when does total hash power figure in here, rather than # of players?) What does gaming have to do with anything? That doesn't help Bitcoin. Perhaps after eliminating all the illegal botnets and miners who are just mining for "free money" with no real interest, there might just be 2% of total miners now - but that's still better than the status quo. Total hash power has always been the important factor of Bitcoin mining, and it was designed to be intentionally highly competitive (and therefore just barely profitable). If you don't care about Bitcoin, that's another problem entirely. Perhaps you should look into reasons Bitcoin is better than conventional currency. |
|
|
|
Bugs should be reported on GitHub, but I don't think this is a bug. Bitcoin-Qt and bitcoind don't support N-of-M multisig transactions yet except for the one case where 1) it has all the keys; 2) it is explicitly told about the multisig address before the coins are sent (-rescan probably works too). |
|
|
|
The original author of the codebase was Jeff Garzik. Con added GPU support. I added FPGA support. Con then took the FPGA support into his, and eventually forked from the main FPGA codebase. As of right now, CGMiner as it is, is a fork of BFGMiner. That is the truth. Forking really is relative. Selectively choosing which updates to pull while pushing your own doesn't make you a fork. Forking is when the maintainer changes. In this case, BFGMiner has the same maintainers (Con still indirectly maintains the pool and GPU code, and I still maintain the FPGAs as I always have) and CGMiner has had a hostile change of maintainership (cutting me out of the loop because Con likes Kano better, initially, and more recently as a way to slander BFL by claiming they don't support the project). |
|
|
|
OK, kind of new I should have stuck to supporting kano and con for their cgminer work and just STFU on Luke.
Good call, my bad, carry on.
I honestly have no f'in clue what Luke does, so I won't comment about him again. I took CGMiner, the GPU miner, and rewrote significant pieces to make it modular and support FPGAs additionally. Everything FPGA-related in CGMiner is based on that work, but Con has opted to fork it in CGMiner and force me to continue the original modular/FPGA project independently as BFGMiner. Don't buy into the trolls and their FUD. Despite Con's renewed interest in maintaining CGMiner as a fork of BFGMiner now that he realizes GPUs are history, the original (BFGMiner) is still better.  You ought to be hanged from a tree for making it sound as though you were the original writer of cgminer. Quit using such weasel language. The original author of the codebase was Jeff Garzik. Con added GPU support. I added FPGA support. Con then took the FPGA support into his, and eventually forked from the main FPGA codebase. As of right now, CGMiner as it is, is a fork of BFGMiner. That is the truth. |
|
|
|
OK, kind of new I should have stuck to supporting kano and con for their cgminer work and just STFU on Luke.
Good call, my bad, carry on.
I honestly have no f'in clue what Luke does, so I won't comment about him again. I took CGMiner, the GPU miner, and rewrote significant pieces to make it modular and support FPGAs additionally. Everything FPGA-related in CGMiner is based on that work, but Con has opted to fork it in CGMiner and force me to continue the original modular/FPGA project independently as BFGMiner. Don't buy into the trolls and their FUD. Despite Con's renewed interest in maintaining CGMiner as a fork of BFGMiner now that he realizes GPUs are history, the original (BFGMiner) is still better. |
|
|
|
The one concern I have is that it makes it effectively impossible to fork the network for any protocol change that would alter mining, because >95% of hashing power will be these ASICs, and so it would be impossible to get a majority of the hashing power to switch. This may be totally unfounded on my part, as I don't know how likely such a requirement is, but regardless I'll be getting out of BTC once these start shipping until the dust settles and price+difficulty stabilise The ASICs don't do the actual transaction validation part, just the proof-of-work, which is unlikely to change ever (the only reason that's ever been put forward for it was an attack from a single big ASIC miner - but having ASICs available to the general community mostly prevents that). Even quantum computing doesn't break SHA256. |
|
|
|
My GPU's would still be (barely) profitable with 12.5 BTC as a reward if difficulty stays lower than 3,000,000, yes 3 million.
If yours aren't you are doing something wrong. ASIC will ruin GPU's. 25BTC a block shouldn't unless you are doing it wrong Mr. FUD Jr.
I don't get free electric either. Even if ASICs are the main cause of GPUs being unprofitable, it doesn't justify making up FUD about ASICs harming Bitcoin. |
|
|
|
Strange things are happening to this useful patch. Author and followers abandon support for it constantly. More than a year has passed, but there is nothing about it in official client, even "experimental" and "for advanced use only". WTF... P.S. Just my 0.02 btc, nevermind  Actually i remember reading somewhere that this will be implemented in 0.7. Am I wrong ? No, since the author and subsequent maintainer have both abandoned it, there is nobody to address the problems still left unresolved. Until that happens, it will not likely be merged. For the time being, I am keeping it minimally up to date for my next-test branches. |
|
|
|
except for Con's "workaround" which discards valid shares from BFL devices in order to avoid stales. Lol. It still discards them Re-check your code there Luke Care to elaborate? I did another look over the code and seem to have properly handled every case that discards work. OK, since you still haven't found it yet (I'm looking at git btw): restart_cond I don't see any case where that actually aborts the job, but you're right about it being a bug (which I suppose would make it start polling too early). Thanks. |
|
|
|
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented. Speaking the truth by calling out false claims is not FUD. |
|
|
|
After running 2.5.0 overnight, the reported rejects are only 0.5% now vs. 1.5% before (with the BFL singles).
That's (partly) because they're not reported. There's also about as many valid shares being silently dropped, as the shares actually being prevented. |
|
|
|
except for Con's "workaround" which discards valid shares from BFL devices in order to avoid stales. Lol. It still discards them Re-check your code there Luke Care to elaborate? I did another look over the code and seem to have properly handled every case that discards work. |
|
|
|
except for Con's "workaround" which discards valid shares from BFL devices in order to avoid stales.
It's a feature, not a bug, and it's been in the firmware of the Single right from the beginning. There's no reason to not use it, and you can't guarantee that a nonce was valid, especially after a longpoll. It's a bug. There is nothing to gain (except false advertising of lower stales), and plenty to lose (valid shares discarded). Fix your pool then, because a longpoll is only supposed to be sent when the current work has been invalidated. If you accept previous work as valid after a longpoll, you risk orphan blocks.  No, that is not correct. Longpolls can be sent for a variety of reasons, not all of which result in orphans. Edit: And pools that don't longpoll outside of new blocks are either producing orphan-shares more often, or are harmful to the Bitcoin network. |
|
|
|
except for Con's "workaround" which discards valid shares from BFL devices in order to avoid stales.
It's a feature, not a bug, and it's been in the firmware of the Single right from the beginning. There's no reason to not use it, and you can't guarantee that a nonce was valid, especially after a longpoll. It's a bug. There is nothing to gain (except false advertising of lower stales), and plenty to lose (valid shares discarded). |
|
|
|
|
Show Posts
