Bitcoin Forum
June 26, 2024, 06:29:20 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 [380] 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 ... 570 »
7581  Bitcoin / Hardware / Re: Avalon ASIC users thread on: August 17, 2013, 12:51:43 AM
Moved from bitparking to 50btc and now I'm constantly getting a lot of Rejected shares at Diff8  Huh
Does anybody have fixed issue like this?

Edit: FW both 20130703 and 20130723

Change your diff to 64 on 50btc under settings for miner is probs why you getting too many rejected shares.

Thanks. Did it already. Looks like it helps.
No, that's not actually making it better unless there is an actual problem with the pool - which would mean don't use the pool.
Going from 8diff to 64diff simply means your Reject share variance increases.
Coz on average you find 1/8 of the rejected shares ... but they are worth 8 times as much each.
That's right. It's not a solution.

If 50BTC is using a large coinbase, you might have been getting struck by the excessive CPU usage limitation in older firmware just like p2pool was. This might manifest as duplicate shares and only show up as rejects at your pool. Most of the recent updates were created to address precisely that problem. Try my latest firmware.

http://ck.kolivas.org/apps/cgminer/avalon/20130814/
7582  Bitcoin / Pools / Re: [~35,000Gh] Semi-private mining pool on: August 16, 2013, 10:12:54 AM
Does the pool keep nmc?sorry to ask I just felt it a valid questions as nmc mining is still not public yet

Not even on a different page...

Also, what is the ETA for NMC merged mining?

Unknown. Stability is most important, so until I've implemented it and it doesn't crash, no NMC.
7583  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 16, 2013, 02:39:01 AM
I don't think power is the issue, Like I said it works fine when plugged into the OTG cable alone. When I just plug just ONE BE into the Hub it spits out the errors till after a while a the BE's LED starts glowing green. I think it's a software (I'm running Linux on a tablet which is kinda iffy) or the hub acting weird. I'm gunna try running debug mode and figuring it out before tonight. I mostly want this setup so I can mine at night to save on power costs.
Could be overheating. Try a simple fan over them for a while as a straight forward test.
7584  Bitcoin / Pools / Re: [~34,000Gh] Semi-private mining pool on: August 16, 2013, 02:37:12 AM
Isn't it about time you changed your handle to terravps?
7585  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 16, 2013, 01:11:37 AM


AMU1: TIMEOUT GetResults took 1711ms but was 100ms



I am also seeing these kinds of messages too...
The occasional timeout like this is okay, it's a kind of USB communication error.
7586  Bitcoin / Hardware / Re: Avalon ASIC users thread on: August 15, 2013, 10:44:16 PM
How is MHSav calculated? Is it based off valid diff1 work?
Meaning HW errors is already accounted for in MHSav?

By my calculations based on clockspeed, looks like it does account for HW% error.

Also does --avalon-temp clock down regardless if --avalon-auto is used or not? Also, how does that relate to --avalon-freq if setting it to one value... will --avalon-temp still clock down?
MHSav is calculated from valid diff1work and does not count hw errors.
Avalon temp works regardless.
Avalon freq is the frequency range that avalon auto will use and ignores temperature unless it is over the optimal range - then it will clock down if the fans can't keep it down.
7587  Bitcoin / Hardware / Re: Avalon ASIC users thread on: August 15, 2013, 03:12:44 PM
Ive lost about 1GH on the latest firmware(20130814)... After 9h, my avg hashrate reports only 82000, previously it was about 83000.
Avy previously seemed to stay between 350-360, now it looks like it hardly gets above 350 =(

This is at nighttime too, when temps are 25, 36, 38C - Batch2

Do like the % changes to miner.php tho =)

Any reason for hashrate loss conman? Was there a change in autoclock algo?
No, I fixed a major latency issue, along with potential for duplicate shares (which would only show up as rejects). It's always hard to sell something that looks slower on the surface...
So, although slower, its working more effeciently? ... hence being better utilized .. hence a bit faster? =)
LOL, overall about the same. However less shares will be lost across block changes, which affects p2pool a lot more than regular pooled mining.

I've spent a lot of time fighting with myself about the right approach to finding the balance between latency and apparent hashrate (aka marketing).
7588  Bitcoin / Hardware / Re: Avalon ASIC users thread on: August 15, 2013, 02:50:19 PM
Ive lost about 1GH on the latest firmware(20130814)... After 9h, my avg hashrate reports only 82000, previously it was about 83000.
Avy previously seemed to stay between 350-360, now it looks like it hardly gets above 350 =(

This is at nighttime too, when temps are 25, 36, 38C - Batch2

Do like the % changes to miner.php tho =)

Any reason for hashrate loss conman? Was there a change in autoclock algo?
No, I fixed a major latency issue, along with potential for duplicate shares (which would only show up as rejects). It's always hard to sell something that looks slower on the surface...
7589  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 15, 2013, 02:30:37 PM
compiling the working libusb didn't help at all, but I think it's my USB Hub is what the issue is. My BE's work if I directly plug them into the OTG cable. The question is WHY is my USB Hub effecting the hashing? It works perfectly fine on my PC. It's a Digital Innovations 7 Port 2.0 Hub, maybe this has something to do with the Serial USB chips using USB 1.1?
Not enough power?
7590  Bitcoin / Hardware / Re: Avalon ASIC users thread on: August 15, 2013, 01:41:15 PM
I am running 0703 and kind of scared to update to 0813/0814.  One person got bricked, several others report decreased hash rates.  Anyone got positive results yet?
Me?

Just upgraded a Batch2 with stock firmware to 0814.  No problems so far! 

How long does the auto option take to increase the frequency?
It reassesses every minute but only goes up or down a small amount each time.
7591  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 15, 2013, 01:30:54 PM
Ah ok. Lastly little single?

Honestly I don't know if that firmware applies to Jalapeņos, and I've never tried, but if it does, then trying out the various speeds per device would be wortwhile.
I've only tried it on singles and the code looks like it's for that only, so again, I don't know.
7592  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 15, 2013, 01:09:51 PM
Honestly I don't know if that firmware applies to Jalapeņos, and I've never tried, but if it does, then trying out the various speeds per device would be wortwhile.
7593  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 15, 2013, 12:11:59 PM
For the brave (and very few) BFL SC single owners out there that wish to flash your devices to try and get the last bit of hashrate out of them, I have uploaded 3 different compiled firmwares here:

http://ck.kolivas.org/apps/cgminer/BitForce_SC/BitForce_SC_1.2.6ck.zip

They all try to enable extra engines than the default firmware does, but in addition I have made 3 different speed ones available, they're tagged 7,8 and 9.

I suggest you start with the 7 first, and if your HW error% rate is less than 2%, try the next one up. I have two singles and one worked best with the 7 version while the other with the 9, so each device will be different.

Remember to put the pins right when connecting your AVR dragon to flash it, and note the different device that Amtel Studio tells you the single is (compared to the Jalapeno) and change your settings accordingly.

If you don't know what the hell I'm talking about, then just ignore this message, since it assumes lots of prior knowledge about flashing the Jalapeno.
7594  Bitcoin / Pools / Re: Suggestion for how to choose a pool difficulty for miners. on: August 15, 2013, 08:39:46 AM


Currently getting 35-40 shares per hour on Diff 128 , to average 25 SPH what should I set the difficulty to ?.



A share return rate of 20 needs a diff of 1 per 1.432GH/s if setting a fixed difficulty.
A share return rate of 25 needs a diff of 1 per 1.79GH/s if setting a minimum difficulty.


I didn't think I could make the advice any simpler than that?
7595  Bitcoin / Mining software (miners) / Re: CGMINER ASIC FPGA GPU overc monit fanspd RPC linux/win/osx/mip/r-pi 3.3.4 on: August 15, 2013, 05:43:08 AM
I tried this with nogpu.exe, but not working.
You are using a VERY old version of cgminer ... get the current one.
Yes - 3.1.1 working with
cgminer-nogpu.exe -o eu-stratum.btcguild.com:3333 -u user -p pass --icarus-options 115200:1:1 --icarus-timing 3.0=100 -S \\.\COM3 -S \\.\COM4
With 3.3.4 not working.
All of those options do nothing for  the latest version, and worse, they stop it from working.
7596  Bitcoin / Pools / Re: Suggestion for how to choose a pool difficulty for miners. on: August 15, 2013, 05:15:26 AM
I posted a similar guideline in Slush's thread when somebody was asking.  My rule of thumb for miners has always been:

Minimum Diffulcty = Closest power of 2 (rounded down) to your GH/s.  1-2 = 1.  2-4 = 2.  4-8 = 4.  8-16 = 8, etc.

This keeps your SPM between 15 and 30 (based on how close you are to the next cutoff).  This happens to be right in line with what almost every pool currently uses for vardiff.
Yes I saw and since the question comes up at regular intervals I thought I'd post a comprehensive explanation as to why and avoid repeating the discussion over and over.
7597  Bitcoin / Mining support / Re: Somewhat new to mining, CGMiner question on: August 15, 2013, 02:11:26 AM
Upgrade cgminer to 3.3.4 The older version wouldn't resize the screen for the slower hotplugging devices.
7598  Bitcoin / Pools / Re: Suggestion for how to choose a pool difficulty for miners. on: August 15, 2013, 01:02:48 AM
So taking it from the other perspective, I believe the pools should by now be forcing a minimum difficulty to prevent an effective DoS from a high hashrate miner. I would suggest they choose the higher value in my range, i.e. 25 shares per minute. The higher value also allows some leeway for the fact that calculating miner hashrate from share return rate is inherently inaccurate. The cyclical problem also exists that the lower the target the pool sets, the less accurately it will predict the miner's hashrate.

TL/DR:
Pools should force a minimum difficulty of miner hashrate in GH / 1.8
7599  Bitcoin / Pools / Re: [12000 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested on: August 15, 2013, 12:59:06 AM
I see so many discussions about setting difficulty manually that I wrote a thread about it.

https://bitcointalk.org/index.php?topic=274023.msg2936086#msg2936086
7600  Bitcoin / Pools / Suggestion for how to choose a pool difficulty for miners. on: August 15, 2013, 12:54:37 AM
Most pools are moving to a variable difficulty or minimum variable difficulty setting to avoid the bandwidth flood that occurs with ASIC hardware, but a lot offer the option of setting a fixed target or the minimum yourself per worker. There is an endless stream of questions on almost every separate pool's thread on what difficulty they should set if setting it manually. Note that you CANNOT EARN MORE by tweaking the difficulty.

So to make it easier, I'm going to give you a mathematically suggested strategy - this is all my opinion based on the maths though since there is no one true answer.

Setting the difficulty low for your hardware risks causing floods of bandwidth problems for both the miner and the pool operators.
Setting the difficulty high for your hardware causes no potential for communication problems, but the higher the difficulty, the more variance your payouts will see (i.e. your pay will fluctuate more) but it will average out to the same pay over time.
No bitcoin mining hardware device currently in existence uses the diff internally - they all mine at diff 1 and the mining software filters out results below what your pool has set it to so it makes no difference what hardware you use as to what diff you mine at.

i.e. only hashrate matters.

So we definitely don't want the difficulty too low, but what should we use as the cut off for how high to set the diff?

Organofcorti did a wonderful analysis of this last year:
http://organofcorti.blogspot.com/2012/10/71-variable-pool-difficulty.html

There is no magic endpoint to choose since the graph of share return rate versus variance is a curve - however - above a certain share return rate, 1% variance is small enough that it is much less than the pool's own luck's variance, and unless you were mining PPS there's a good chance you wouldn't be able to distinguish the difference on any one day. You also need a much bigger jump in share return rate before you can get below that 1% variance.

So my suggestion is to aim for a share return rate no higher than the highest difficulty that keeps you at 1% variance if you are setting a "minimum difficulty" or perhaps the value that keeps you under 1.2% for a fixed difficulty. This can be worked out easily if you know your hashrate without even testing it.

So our target is a diff that returns 20-25 shares per minute.
Every 71.6MH/s returns one share per minute - therefore every GH/s returns about 14 shares per minute.

A share return rate of 20 needs a diff of 1 per 1.432GH/s if setting a fixed difficulty.
A share return rate of 25 needs a diff of 1 per 1.79GH/s if setting a minimum difficulty.

Most pools are allowing you to set a fixed diff, so let's keep this final recommendation as simple as possible, and aim for 20 shares per minute. That's a diff of 1 per 1.432GH/s. The accuracy of this maths is not that important since the final endpoint is arbitrary anyway so we can knock off a few significant digits off our final recommendation.

TL:DR
Set your diff to your worker's hashrate in GH / 1.4
Pages: « 1 ... 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 [380] 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 ... 570 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!