|
That was scary! I set a buy order for 41 GH/s @ 0.158 and immediately someone cleared the whole buy side. Day's range: 0.0100 - 0.1849. After that the price rebounded really quickly to 0.17 with large buy orders.
|
|
|
|
Is it possible to alter the difficulty target for the stratum proxy? I tried it with my BitFury ASIC, and it was getting flooded with diff 0 shares, and the miner's CPU became overloaded. I only got around 60GH/s hashrate when the real hashrate was 95GH/s. The proxy could be a nice alternative to get good backup pool support and the performance of chainminer, which still seems to be a bit faster than BFGMiner.
chainminer doesn't support stratum, so I don't think this will help.  I tried it with the slush stratum proxy, of course. Yes, two proxies there. As I said, it did produce valid shares at around 60GH/s, and was only limited by the CPU because BFGMiner's proxy didn't set a higher diff target. Another solution I've tried is BFGMiner's getwork proxy, but that won't work because it doesn't support RollNTime. These kludges would be useful only because BFGMiner still is around 1% slower than chainminer with BFSB miners. What does this mean exactly?: "Third hashrate displayed is now based on nonces found, adjusted for pool rejected/stale shares. It should still be approximately equivalent to your effective/earning hashrate, but with better accuracy." At first I thought it was purely based on difficulty accepted ((difficulty_accepted/seconds_elapsed*2^32) hashes per second), but the numbers don't match. |
|
|
|
|
Is it possible to alter the difficulty target for the stratum proxy? I tried it with my BitFury ASIC, and it was getting flooded with diff 0 shares, and the miner's CPU became overloaded. I only got around 60GH/s hashrate when the real hashrate was 95GH/s. The proxy could be a nice alternative to get good backup pool support and the performance of chainminer, which still seems to be a bit faster than BFGMiner.
|
|
|
|
How is the BTC/hr number calculated? It's a bit pointless for me, as I'm not mining BTC - I'm mining PPCoin.
Similarly, the network hashrate is calculated wrong unless the altcoin happens to have 10 minute blocks. If there was an option (for display purposes only) to set the network block rate, block reward and maybe even the name of the coin, these issues could be fixed. Also, the hashrate counter based on accepted difficulty isn't working with scrypt, here's an example: 0.84/ 0.84/441.6Mh/s. I'm obviously not averaging 441.6MH/s mining scrypt. |
|
|
|
|
Maybe adding an EU server would help spreading the blocks around the world with less latency?
|
|
|
|
Hey guys..... Ive been slaving away for the last 3 days at wrapping my head around, and tweaking BFL firmware. Ive done some major changes that basically, reliably seem to get most peoples singles(60GH) an additional 5-7GH/s pool measureable. My single stock was 58.4GH ... now its 64.8GH ... nearly all engines are enabled and happily hashing away. Here is the source and the elf is also prebuilt in the debug folder. http://www.fileswap.com/dl/oPZeK2NqSm/I just tried this, and it really does boost the hashrate. I'm not exactly sure how much yet, since I'm measuring by difficulty accepted, but my it seems to be settling in the 64-65 range, when it was previously doing a bit over 61. Here's a snippet of the ZCX reply: THEORETICAL MAX: 68880 MH/s ENGINES: 256 FREQUENCY: 291 MHz As you can see it enabled all my engines, stock firmware was only seeing 245 or so. It's now doing ~3.5% errors instead of the stock 0.4%, but with BFGMiner I can see which chips are doing lots of errors, and using the 16 value array in this modified firmware, I can set those chips to a lower frequency.  |
|
|
|
|
Please add a feature to download CSV history of transactions. Or at least add another view that doesn't include any canceled orders, only actual trades. It's quite hard to keep track of my performance now, I have to keep a manual log of my trades to stay on track.
|
|
|
|
This won't work because people use https, not http Actually, this could be done on a far simpler basis attacking individual users via a MITM attack. Here is your scenario:
1. Your ISP hires a dishonest worker. Let's call him "Mallory". (I say ISP, but this could happen upstream from the ISP, too, on the backbone).
2. Mallory prepares a hacked bitcoin client by downloading code anonymously from github, then adding his own special sauce and compiling.
3. Late at night, Mallory reroutes two cables in the server room, to put http requests through "Machine X" which is not on the ISP's logging system.
4. "Machine X" has URL rewriting code that watches for people trying to download the compiled bitcoin client, and redirects those requests
to a server where Mallory's fiddled version is served.
5. A hundred or so users (or a few thousand depending on how big the ISP is, or maybe half of all the downloaders for a few weeks if Mallory is at a backbone site) send an HTTP request for the client, and get Mallory's version instead.
6. These phony clients have most of a year to log your wallet-decryption passwords while acting as legit clients, then on June 14 they send three-quarters of your coin to Mallory's client. Meanwhile they continue to display the amount you had, so that you won't notice until you try to spend down to less than 75% of your previous balance, unless you go to blockchain.org and look up individual keys.
7. Mallory turns around the coin to buy untraceable goods, leaving it in the hands of honest merchants.
8. It will be at least two or three months before most of the victims notice.
This is what I'm offered to download when clicking through bitcoin.org. No HTTPS there. |
|
|
|
|
Another thing I've noticed with BFSB hardware and bfgminer is that the load average is always very high. Around 1.6 or so. This doesn't seem to be a problem, I'm just curious what could cause it, when CPU usage is less than 10%. I know that at least high I/O loads can cause high load averages even if the CPU is mostly idling. The load average is only 0.2-0.3 with chainminer, though, so this leads me to believe that bfgminer is doing something different. I'm also running the exact same binary on my other raspberry with 2 BFL Jalapenos, and its load average is always close to zero.
|
|
|
|
I've had suspended payments on this pool for the good part of a year now. I first emailed about them to Tycho as instructed in December, and he said the payments would be unlocked in a few days. I sent another email over a month ago, and it hasn't been responded to. It's not much, a bit over 0.4 BTC, but I'd sure like to get it.
Tycho, could you please dig into your email inbox and get this sorted out?
Still no answer. |
|
|
|
|
The price graph only shows up to 3 days of history. Monthly & weekly views would be much appreciated.
|
|
|
|
|
I noticed a per_proc setting in miner.php, perhaps it was included in a recent commit? Anyway, it mostly works and is a useful feature, but with a BFSB board it's not working correctly. The board is detected as up to 4 devices, mine currently has 3 doing 30-35 GH/s each. With per_proc=false, BSB0 shows a 100GH/s hashrate, BSB1 64GH/s and BSB2 32 GH/s. Looks like BSB0 is incorrectly also including all the chips from other BSB devices, and BSB1 similarly also includes chips from BSB2. Without per_proc=false, there's no error in the stats, all BSB devices are correctly shown as having 16 chips. BFGMiner TUI is also displaying the correct hashrate for each device.
|
|
|
|
My workers are all named
jupiter1
jupiter2
jupiter3
saturn1
etc
I just noticed all of my jupiters have had their difficulty set to 625 and my saturn to 250
I think this has had a negative impact on my hashing speed as the equation is supposed to be hashrate / 1.4
I used to have the jupiters @ 256-400 min difficulty and hashing of 550+ for the best jupiters. Now all units =<499
You'll just experience more variance with a higher difficulty, there can't be any other effect. Unless the miner software is buggy and doesn't handle dynamically changing difficulty well. To rule that out, it's best to select a sufficiently high minimum difficulty, so that it won't ever be increased dynamically. That's where the hashrate / 1.4 rule comes from. But it's not valid for this pool, because it assumes pools want miners to submit 20 shares per minute. This pool aims to just 12 shares per minute, so try hashrate / 0.84 (625 for a 550GH/s device is quite close to this). |
|
|
|
|
Is it possible to accidentally use the wrong driver for BitFury units? I'm specifically thinking of using the Metabank driver on a BFSB unit or vice versa. I heard it somewhere on IRC that using the wrong driver could brick a unit, and I'd like to get some actual information on this.
I'm currently running the main branch version with BFSB support, and it's working quite well. I threw in lots of --disables to configure, to get a binary that doesn't have any other BitFury drivers besides BFSB. Hopefully that was unnecessary.
|
|
|
|
|
I've been running the bitfury branch of BFGMiner for about a week now, with no major problems. Performance is identical to chainminer (30G + 30G + 35G accepted hashrate from 3 boards), but sometimes the hashrate (and power consumption) randomly drops 1%. This is fixed by restarting. I have no reason to use chainminer anymore, except to maybe fine-tune new boards as they come in.
|
|
|
|
I'd like to know what driver exactly should be used with this branch. Looks like the bitfury & bfsb compile options would be the way to go, but ./configure --help states the following: --disable-bfsb Compile support for BFSB (default disabled)
Note the 'default disabled'. I tried --enable-bfsb, but there was still no mention of BFSB support in the configure results. I'm just being extra careful, wouldn't want to fry my boards by running a wrong driver. On that note, is there any harm in having the littlefury/metabank drivers compiled in, too? |
|
|
|
Pool needs to update: https://bitcointalk.org/index.php?topic=300714.0EDIT: I'm not actually sure anymore which pool is on the wrong fork, sorry for the confusion if you've already updated. I just noticed that FCPool and Coinotron seem to be on a different chain than this pool. |
|
|
|
I'm having issue compiling for mipsel these days. In particular with libudev. I see that it has been around since 2.4 or so, and I've compiled up to 3.3.1 ok, but now libusb is now part of the compilation process and udev is required. Any idea how I get that up and running? Seems udev is a very low-level system specific lib. The compiler I use has the option to include it in the buildroot, but cgminer still complains it's missing. Also, how do I use my own version of libusb-1.0 and not the included one? checking libudev.h usability... yes
checking libudev.h presence... no
configure: WARNING: libudev.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: libudev.h: proceeding with the compiler's result
checking for libudev.h... yes
checking for udev_new in -ludev... no
configure: error: "udev support requested but libudev not installed"
configure: error: ./configure failed for compat/libusb-1.0
Are you cross compiling? If so, here's how I solved it: https://bitcointalk.org/index.php?topic=28402.msg3152376#msg3152376 |
|
|
|
|
Do the sysops and/or science club understand that this operation will surely be unprofitable, if power costs are factored in?
|
|
|
|
Is everybody compiling stuff on the pi, or has anybody had any success cross-compiling from a more powerful machine?
Why would anyone want to bother to build a cross-compilation environment? That would require a great deal of effort to duplicate something that is already trivial to perform on the RPI... To make repeated testing of new versions faster. Or to make the compile time on git-bisect bearable for finding bugs. I already have a cross-compiling environment for ARM, to compile cgminer for my other raspberry. Only reason I haven't added chainminer to it is because there's so far been only one update. |
|
|
|
|
Show Posts
