I talked to Sonny today at BFL, the default temp-cutoff for BFL units in cgminer is set way too low. He advised at the default should be around 85C... right now it seems to be set at 30C or so (I've not checked the code) - so trying to startup a BFL unit with a stock cgminer at rev 2.3.3 starts with an immediate temp cutoff warning and the unit goes into REST.
Manually setting the cutoff gets around the issue, but 30C is even above idle temps for a powered on unit. Sure you (or Sonny) aren't confusing C and F? He told me BFL Singles need 72 F / 22 C) ambient temp to run at full speed. My on-FPGA temp for BFSingle is 149 F / 65 C even with an ambient temp of about 80 F. There shouldn't be a 30 C cutoff... |
|
|
|
Not sure if this was covered but is there going to be support for the x6500 fpga. If someone sends me one, I can code it. |
|
|
|
cgminer version 2.4.0 - Started: [2012-04-20 16:40:08] [1 hour ago]
[P]ool management [D]evice management [S]ettings [Q]uit
------------------------------------------------------------------------------
Block: …abdc040d7363549aecca1746 @ 17:00:26 Pool: Eligius
HW:0 1769/1777 R:0.17% E: 3.00 ST:1 GF: 0 RF: 0 NB: 3
5850: 82.0C 308/ 310 R:0.15% | 6870: 74.0C 275/ 276 R:0.17%
BF S: 66.0C 823/ 825 R:0.30% | Icar: 363/ 366 R:0.07%
------------------------------------------------------------------------------
[2012-04-20 16:51:02] Accepted 2e1b3382/…baeac1c4 Radeon 5850
[2012-04-20 16:51:35] Accepted 36edf606/…15b1f2b6 BitForce Single
[2012-04-20 16:52:06] Accepted 6984daff/…bc3431e0 BitForce Single
[2012-04-20 16:53:51] Accepted 6aeb97ad/…788b5831 Icarus
[2012-04-20 16:54:39] Accepted 5863cba3/…8ca693d8 BitForce Single
[2012-04-20 16:54:41] Accepted e12c4c4f/…ceb3c76b BitForce Single
[2012-04-20 16:55:11] Accepted 9bda7e9c/…b9814a91 BitForce Single
[2012-04-20 16:55:55] Accepted d0adf8db/…d2423c69 Radeon 5850
[2012-04-20 16:55:56] Accepted 0a8978ab/…78f8dabd Radeon 6870
[2012-04-20 16:58:49] Accepted dae4c9ff/…e7e3e12d BitForce Single
[2012-04-20 16:59:27] Accepted 5a95e666/…51f6e5ec BitForce Single
[2012-04-20 16:59:58] Accepted 640dd886/…2f5edcd9 Icarus
[2012-04-20 17:00:26] LONGPOLL detected new block on network
[2012-04-20 16:59:58] Accepted 3549dffa/…786fd89d Icarus
[2012-04-20 16:59:59] Accepted f8fa89ac/…86f8dfaa Radeon 6870 |
|
|
|
By the way, another example to demonstrate multiple points that have come up tonight...
Gigavps recently came in the #CGMiner channel to report a bug about the "semi-graphical" command line display malfunctioning with more than 16 devices - he had just turned on a total of 17+ FPGAs.
How did I confirm this bug? Not with 17 FPGAs - can't expect every developer to have that kind of equipment handy for testing - but by using CPUmining to generate 17 CPU threads. So yet another thing CPUmining helps test is CGMiner's basic frameworks themselves.
Unfortunately, ckolivas expressed that he would refuse to merge a fix for this issue even if I wrote it. Pretty much defeats the point. (Though I did still offer to debug and write the fix for Gigavps, at a reasonable per-hour cost; I can't blame him for declining, considering it wouldn't get merged)
P.S. Kanoi, thanks for digging out the logs which show you alone agreed to abide by your poll, but #CGMiner is a private channel and posting logs publicly is technically forbidden.
Yes, I'm a real bad guy, I don't accept code, and I keep the cgminer channel private. Playing on words makes this whole discussion look ridiculous. There is no rule about posting IRC logs publicly. It is not even remotely a private channel, and I happily accept code when it's good, useful, and not controversial. The code in question, Kano had a reasonable objection to in an area that affected him and his code, and I don't have an opinion regarding it, so I wasn't going to make the decision (unlike other times). I don't care how you spin this, but unless you and Kano can agree on it, I will continue to refuse to accept it. No, there was no objection to this fix. You're thinking of something else, where Kano admitted his objection was unreasonable. |
|
|
|
I've merged BitPennyd with the latest 0.5.x branch to bring it up to speed. This is not affected by the bad blocks issue, and has many other bugfixes made to bitcoind since BitPennyd was originally released (it was based on a 0.5.1 RC): https://github.com/luke-jr/bitcoin/tree/bitpenny |
|
|
|
|
bitlane is already a known troll, no idea why he's not banned yet.
|
|
|
|
The problematic things he seems to like to do are related to changing the way things look because he wants it to look different - and they have been rejected in the past.
Otherwise, I think most of his code changes have gone in. No, generally I haven't touched (nor have any particular interest in touching) display/output. The only times I've affected it were accidental/secondary from the real code change; the first, refactoring the code to support different drivers (this initially moved the driver-specific information - temperature and fan speed for GPUs - to the end of the device info line), and the second, fixing a bug I introduced with that first change when I used "BFL" to represent "FPGA" in the internal driver API (this was fixed by correcting it to "PGA" which kanoi suggested). |
|
|
|
|
By the way, another example to demonstrate multiple points that have come up tonight...
Gigavps recently came in the #CGMiner channel to report a bug about the "semi-graphical" command line display malfunctioning with more than 16 devices - he had just turned on a total of 17+ FPGAs.
How did I confirm this bug? Not with 17 FPGAs - can't expect every developer to have that kind of equipment handy for testing - but by using CPUmining to generate 17 CPU threads. So yet another thing CPUmining helps test is CGMiner's basic frameworks themselves.
Unfortunately, ckolivas expressed that he would refuse to merge a fix for this issue even if I wrote it. Pretty much defeats the point. (Though I did still offer to debug and write the fix for Gigavps, at a reasonable per-hour cost; I can't blame him for declining, considering it wouldn't get merged)
P.S. Kanoi, thanks for digging out the logs which show you alone agreed to abide by your poll, but #CGMiner is a private channel and posting logs publicly is technically forbidden.
|
|
|
|
As far as needing a test platform wouldn't just using I don't know ... any GPU be a better test platform? Except then you have to stop mining for real on that GPU. Given the near universal nature of GPU and their low cost (especially used low end cards) seems silly to test using a code base that 99.9% of your users aren't using. CPU mining and GPU mining use 99% of the same code, ever since I refactored cgminer to add FPGA support. I presume you aren't referring to the 'bug' regarding device naming? No, I was referring to other bugs, like the scantime bug. The one that we both agreed to abide by the response of the poll I created, but you not only ignored the poll results, but also went ahead and added more code changes to the git pull against the results of the poll ... No, you agreed to abide by the poll, not me. That was why I let you make it, as biased and misinformative as it was. The results express nothing, since the poll had nothing to do with the actual bugfix we were talking about. |
|
|
|
Luke-Jr, as you already know, there are known bugs in the CPU code (and some unknown ones) As I know, there are known bugs in both CPUmining code and non-CPUmining code that ckolivas simply refuses to allow anyone to fix. If it wasn't for that, they wouldn't be bugs anymore. In any case, those bugs don't interfere with using cgminer for testing other software, yet. |
|
|
|
Any individual cannot make a profit on CPU mining alone unless they are not paying for electricity. Problem with this logic is that you're assuming all mining is done for profit. I find CPU mining very handy for testing without messing with my FPGAs. For testing what? Bitcoin code changes. Pool software code changes. I'm sure other developers can think of more. |
|
|
|
Any individual cannot make a profit on CPU mining alone unless they are not paying for electricity. Problem with this logic is that you're assuming all mining is done for profit. I find CPU mining very handy for testing without messing with my FPGAs. |
|
|
|
Hi Luke-Jr,
something is wrong with the stats at Eligius. Since Apr 2 it's completely wired.
Also the "submitted shares" count looks wrong. Does Eligius loose shares, or it's just a problem with the stats?
Everything looks fine to me... Hi, once again. Still having problems with Eligius pool. If I jump in (with 5GH) stats are not going up. Not after 15min, 30min... The 15min stat remains 0 or at maximux 50MH with 10 or 20 shares submitted. Therefore I started mining with a new bitcoin address. I've submitted around 1000 shares. One day later the address is still unknow. The bitcoin address is correct. Just send 0.01 BTC to it from another PPS pool. So whats going on... for me nothing looks fine. Here's the link to Eligius with the new bitcoin address: http://eligius.st/~artefact2/7/1P7jUfXUEgk4oqXXxsQ2RAJsa9uBp1ChSAYou (or your miner) are sending it lowercase'd. Bitcoin addresses are case-sensitive, so the all-lowercase variant is invalid. |
|
|
|
Support for validating message signatures produced with compressed public keys. Is this referring to ECDSA signatures that have the public key encoded in them so that the public key is not necessary? Or just some compression scheme for ECDSA? I thought most implementations of ECDSA already employed public key compression. Bitcoin didn't use public key compression until 0.6; this just adds the minimum glue required to verify these 0.6-made signatures on text messages with the JSON-RPC "verifymessage" method. |
|
|
|
Bitcoin version 0.5.4 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.4/NOTE: 0.5.4rc3 is being renamed to 0.5.4 final with no changes. This is a bugfix-only release in the 0.5.x series, plus a few protocol updates. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesStable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.4#.tar.gzPROTOCOL UPDATES- BIP 16: Special-case "pay to script hash" logic to enable minimal validation of new transactions.
- Support for validating message signatures produced with compressed public keys.
BUG FIXES- Build with thread-safe MingW libraries for Windows, fixing a dangerous memory corruption scenario when exceptions are thrown.
- Fix broken testnet mining.
- Stop excess inventory relay during initial block download.
- When disconnecting a node, clear the received buffer so that we do not process any already received messages.
- Yet another attempt at implementing "minimize to tray" that works on all operating systems.
- Fix Bitcoin-Qt notifications under Growl 1.3.
- Increase required age of Bitcoin-Qt's "not up to date" status from 30 to 90 minutes.
- Implemented missing verifications that led to crash on entering some wrong passphrases for encrypted wallets.
- Fix default filename suffixes in GNOME save dialog.
- Make the "Send coins" tab use the configured unit type, even on the first attempt.
- Print detailed wallet loading errors to debug.log when it is corrupt.
- Allocate exactly the amount of space needed for signing transactions, instead of a fixed 10k buffer.
- Workaround for improbable memory access violation.
- Check wallet's minimum version before trying to load it.
- Remove wxBitcoin properly when installing Bitcoin-Qt over it. (Windows)
- Detail reorganization information better in debug log.
- Use a messagebox to display the error when -server is provided without configuring a RPC password.
- Testing suite build now honours provided CXXFLAGS.
- Removed an extraneous line-break in mature transaction tooltips.
- Fix some grammatical errors in translation process documentation.
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Pieter Wuille Wladimir J. van der Laan Gavin Andresen Matt Corallo Philip Kaufmann Alistair Buxton Joel Kaartinen Patrick Schneider Vegard Nossum |
|
|
|
In A.D. 2012 War was Beginning. Graet: What happen ? Tycho: Somebody set up us the bomb. PiUK: We get signal. Graet: What ! PiUK: Main stats turn on. (screen turns on displaying a shadowy masked figure)Graet: It's you !! Mystery Miner: How are you gentlemen !! Mystery Miner: All your blocks are belong to us. Graet: What you say !! Mystery Miner: You have no chance to mine make your time. Mystery Miner: Ha ha ha ha ... Graet: Tycho !! Tycho: Turn on every 'RIG'!! Tycho: You know what you doing. Tycho: Mine 'RIG'. Tycho: For great justice. Disclaimer: This is an entirely fictional record.Cast: - Graet, ozco.in
- Tycho, Deepbit
- PiUK, blockchain.info
- Mystery Miner, mystery
|
|
|
|
I'm surprised I'm the only one who wants to know, but what caused the charts to mess up yesterday? Due to a minor glitch in the code I use to do manual payouts (sendmany), some addresses were over-paid. The safeguards in place in the coinbaser code kicked in and complained that those addresses' balances were taken negative, and refused to run. To get the coinbaser running again, I had to make a temporary copy of the database, and run it without that safeguard in place, updating the cache beyond the point where they were taken negative. However, when doing so, the updates created the JSON block statistics in the copied directory. Since this was missing, Artefact2's web graphs were missing the "total ever paid" information, and put the estimates at the zero-level instead. I moved the relevant file, so it now is drawing current data correctly, but unfortunately there is no easy way to modify the historical record it keeps. After that ~hour falls off the left side of the history, it should return completely to normal. How much does the pool owe its miners then, and what do you call that? The payout queue can be viewed at http://eligius.st/~twmz/ |
|
|
|
Are we talking about the same thing? The SMPPS buffer? Which can be negative, and unless you're using a different definition of 'balance' is as likely to be negative as positive? Yes, and as the creator of SMPPS, I know that the buffer in fact cannot be negative by definition... Either there are funds in it, or not. There can't be anti-funds in the pool's wallet any more than there can be anti-funds in your own. |
|
|
|
Luke-jr, shouldn't the pool be in a negative buffer at the moment? Your stats page is showing a positive buffer. Come to think of it, it shows that you've never had a negative buffer. Bug?
There is no such thing as a negative buffer. How do you have a negative balance? |
|
|
|
|
Show Posts
