Any chance the chips might be open source too?  |
|
|
|
Well for sha256 mining bfgminer v3.10.2 likes me more  Please bisect any problems you have, as 3.10 won't be maintained forever... I am going to be getting two 5chip Gridseed Dualminer Scrypt + SHA256 soon &
I hope BFGMiner v4.1.0 works well with it. I really don't want to use the cgminer fork, blah. SHA2 is not supported for these, only scrypt. |
|
|
|
yo Luke-Jr
I just moved over to BFGMiner v4.1.0 & it keeps telling me btcguild.com is dead when I know its not
I have restarted it over & over & sometime it will work but for only like 1min & then it comes back with pool dead.
It does work on trc.royalminingco.com & I have been on there all day.
I don't know whats going on but bfgminer-3.10.0 did not do this. & I may have to move back to it or try 4.0.0 or 3.10.2 or 3.10.1 Try adding #notls to the BTCGuild URI. Unfortunately, they just leave the connection open and silent when BFGMiner attempts to negotiate TLS (if they errored or disconnected, it'd immediately retry). Without #notls to disable TLS, it should still timeout after a minute (but this needs to happen again after the reconnect...) I added it "url" : "stratum+tcp://stratum.btcguild.com:3333#notls", not sure if that's where I'm to put it but it did work & I was getting work from the pool but then I started getting this "Rejected untracked stratum share from pool 0" the pool Diff was stuck at 1 & btcguild does not use 1. this is just not working for btcguild. I will just have to roll back  but thanks for your time & help Luke-Jr. Hrm, strange. Can you try bisecting it? https://bitcointalk.org/index.php?topic=626361.msg6964942#msg6964942ok I did it, I'm not sure what bisecting is... Am I to download the "Builds"?? if yes there for windows I use Gentoo Linux. In that case, please see http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search |
|
|
|
yo Luke-Jr
I just moved over to BFGMiner v4.1.0 & it keeps telling me btcguild.com is dead when I know its not
I have restarted it over & over & sometime it will work but for only like 1min & then it comes back with pool dead.
It does work on trc.royalminingco.com & I have been on there all day.
I don't know whats going on but bfgminer-3.10.0 did not do this. & I may have to move back to it or try 4.0.0 or 3.10.2 or 3.10.1 Try adding #notls to the BTCGuild URI. Unfortunately, they just leave the connection open and silent when BFGMiner attempts to negotiate TLS (if they errored or disconnected, it'd immediately retry). Without #notls to disable TLS, it should still timeout after a minute (but this needs to happen again after the reconnect...) I added it "url" : "stratum+tcp://stratum.btcguild.com:3333#notls", not sure if that's where I'm to put it but it did work & I was getting work from the pool but then I started getting this "Rejected untracked stratum share from pool 0" the pool Diff was stuck at 1 & btcguild does not use 1. this is just not working for btcguild. I will just have to roll back but thanks for your time & help Luke-Jr. Hrm, strange. Can you try bisecting it? https://bitcointalk.org/index.php?topic=626361.msg6964942#msg6964942 |
|
|
|
I'm on course to have some preliminary support in BFGMiner early next week. bfgminer version 4.1.0 - Started: [2014-06-07 06:16:54] - [ 0 days 00:04:10]
[M]anage devices [P]ool management [S]ettings [D]isplay options [H]elp [Q]uit
Pool 0: ...ning.eligius.st Diff:512 +Strtm LU:[06:20:52]
Block: ...8bf2d56e #304607 Diff:11.8G (84.16P) Started: [06:20:50]
ST:9 F:0 NB:3 AS:0 BW:[312/ 97 B/s] E:724.18 I: 1.11mBTC/hr BS:94.3k
0 | 0.00/ 0.00/595.8Gh/s | A:150 R:0+0(none) HW:166/.49%
--------------------------------------------------------------------------------
JTN 0: | 0.00/ 0.00/118.2Gh/s | A: 29 R:0+0(none) HW: 49/.70%
JTN 1: | 0.00/ 0.00/124.1Gh/s | A: 22 R:0+0(none) HW: 3/.04%
JTN 2: | 0.00/ 0.00/123.7Gh/s | A: 40 R:0+0(none) HW: 16/.23%
JTN 3: | 0.00/ 0.00/122.6Gh/s | A: 30 R:0+0(none) HW: 10/.14%
JTN 4: | 0.00/ 0.00/124.7Gh/s | A: 31 R:0+0(none) HW: 93/1.3% The relatively low hashrate is due to the code incompleteness (including changing clocks), it should go at least 2x faster I think. |
|
|
|
yo Luke-Jr
I just moved over to BFGMiner v4.1.0 & it keeps telling me btcguild.com is dead when I know its not
I have restarted it over & over & sometime it will work but for only like 1min & then it comes back with pool dead.
It does work on trc.royalminingco.com & I have been on there all day.
I don't know whats going on but bfgminer-3.10.0 did not do this. & I may have to move back to it or try 4.0.0 or 3.10.2 or 3.10.1 Try adding #notls to the BTCGuild URI. Unfortunately, they just leave the connection open and silent when BFGMiner attempts to negotiate TLS (if they errored or disconnected, it'd immediately retry). Without #notls to disable TLS, it should still timeout after a minute (but this needs to happen again after the reconnect...) |
|
|
|
NEW VERSION 4.1.0, JUNE 6 2014Human readable changelog:- Stratum: Fix recovery of dead pools.
- gridseed: 80-chip G-Blade support.
- Stratum: Support for authenticated TLS with the CA model, using #tlsca URI parameter.
Full changelog:- Bugfix: Ensure variables are declared even without ADL support
- RPC: Include a list of config files loaded in "config" reply
- Bugfix: Save a linked list of config files loaded so output makes sense (previously only the most recent config file was named, and errors were reported inconsistently)
- README.RPC: Document Coinbase-Sig in config reply
- Bugfix: Safely handle pool status line when no pools are alive
- bitforce: Refactor bitforce_vcom_gets slightly to be more sane
- Bugfix: initiate_stratum: Ensure extranonce2 size is not negative (which could lead to exploits later as too little memory gets allocated)
- Stratum: extract_sockaddr: Truncate overlong addresses rather than stack overflow
- Stratum: tlsca parameter to require CA validation of TLS certificate
- Bugfix: Avoid setting tv_idle before testing pool (it will be set if the test fails)
- restart_stratum: Make use of return_via
- return_via helper function family to assign a variable and goto
- Bugfix: restart_stratum: Release pool_test_lock on failure
- bfsb: Disable all banks before enabling the one we want, to avoid having two enabled at the same time (eg, when switching from bank 3 to bank 2)
- Interpret present "tls" parameter to require TLS
- uri_get_param_bool2 returning a tristate
- Tests for uri_find_param
- Split uri_find_param out of uri_get_param_bool
- gridseed: Allow specifying an arbitrary number of chips with --set gsd:chips=X
- gridseed: added support for the 80-chip (two blades of 40 chips) G-Blade Scrypt-only miner
- Bugfix: gridseed: use a signed integer so that returning -1 has defined behavior
- RPC: Return integer difficulties without decimal places
- Bugfix: Zero pool "Works"
- Bugfix: Set any listening sockets to close-on-exec/non-inheritable to avoid issues rebinding them on restart
- RPC: Explicitly shutdown communication on client sockets to avoid them being held open by forked processes
- RPC: Clean up mcast socket with tidyup_socket
- RPC: Move socket tidyup code to its own function
- Bugfix: RPC: Use pthread_exit rather than returning from the RPC thread, to ensure tidyup gets called
- Bugfix: bitforce: During initialisation, clear each XLink slave exactly once only
|
|
|
|
Due to the limitations of the speed of light, all pools regardless of reward system have some overhead.
I think it tends toward 2% in the long run, recently.
With CPPSRB, this manifests in shelved shares unpaid forever; but the same losses occur no matter what reward system is in use.
I'm curious what those losses would be under PPLNS. If I understand correctly the advantage of CPPSRB is less variance but under PPLNS if the pool were to hit a lucky streak, the miners get a proportional rise in payouts (putting you above what you would get even in a straight PPS system.) In CPPSRB if the pool hits a lucky streak the best the miners will get is 100% of their shares paid. Under PPLNS, once your shares fall out of the LastN window, you will never be paid for them regardless. CPPSRB merely has a dropping probability, instead of a flat cutoff. Yea but PPLNS also pays your shares out twice if the pool solves a block quickly. It seems PPLNS is just more "luck" based whereas CPPSRB gives you more steady payouts and less variance. If ~2% of my shares don't get paid, that's not a bad trade off. My point was that your long-term earnings are the same. |
|
|
|
Due to the limitations of the speed of light, all pools regardless of reward system have some overhead.
I think it tends toward 2% in the long run, recently.
With CPPSRB, this manifests in shelved shares unpaid forever; but the same losses occur no matter what reward system is in use.
I'm curious what those losses would be under PPLNS. If I understand correctly the advantage of CPPSRB is less variance but under PPLNS if the pool were to hit a lucky streak, the miners get a proportional rise in payouts (putting you above what you would get even in a straight PPS system.) In CPPSRB if the pool hits a lucky streak the best the miners will get is 100% of their shares paid. Under PPLNS, once your shares fall out of the LastN window, you will never be paid for them regardless. CPPSRB merely has a dropping probability, instead of a flat cutoff. |
|
|
|
Hey I just switched over to mining at Eligius and I just wanted some clarification on the CPPSRB payout system. So if I understand it right I'm getting just a flat PPS rate as long as the blocks have >=100% luck. If it's less than 100%, some of my shares will be unpaid (and "shelved") until the pool solves a lucky block and has excess BTC to backpay me. Am I right so far? Until and IF. But yes. One thing I was wondering though is what happens if the pool gets exceptionally lucky, pays off everyone's shelved shares, and still has excess BTC. Does the pool keep the extra or is it returned to the miners? It goes toward future blocks. But it won't happen. On Eligius, note underneath the shelved shares are the old SMPPS system's shares, which get paid proportionally before the pool is completely paid off (this alone is so unlikely that IIRC wizkid057 has never actually implemented the code to handle it). Also, over the long term what percent of my shares will go unpaid? I read the analysis of rewards systems on the sticky and, although it didn't mention CPPRSB specifically, it said many of the MPPS variants will over the long term approach a point where the backlog of shelved shares gets so great that many will remain unpaid indefinitely. Due to the limitations of the speed of light, all pools regardless of reward system have some overhead. I think it tends toward 2% in the long run, recently. With CPPSRB, this manifests in shelved shares unpaid forever; but the same losses occur no matter what reward system is in use. |
|
|
|
Any interest in porting to BFGMiner? |
|
|
|
It's not a KNC hardware, but self made bitfury string miner using my own fork, based on Legkodymov's code ... I know it's old, but is the only one that works with my hardware Unfortunately, providing support for old cgminer forks is not something I can spare time for I'd recommend upgrading your code to the latest (or stable) version of BFGMiner. If you want to try to debug this issue, the different lies in the size of the generation transaction: the "KnC port" (and almost every other pool out there, including BTCGuild) used tiny (<200 byte) generation transactions, whereas Eligius needs multi-kB generation transactions. Using the "KnC port" hurt the payout queue, since it only paid the cold wallet instead of miners. |
|
|
|
OK, I just went ahead and set the default/minimum work difficulty to 128.
This only really changes anything for miners < ~64Gh... and it just increases variance a little for them, doesn't decrease/increase payouts. For anyone over 64Gh, no real difference except easier miner starts.
-wk
I have made some test and the results are weird ... The miner is ~650GHs load balanced between Slush and Eligius: When port 12234 is used the full hashrate is reached in ~1min and is properly balanced 50/50 When port 3334 is used, it reaches ~220GHs again 50/50 Even if i start with just Slush and reach 600+ there, then enable Eligius 3334 it drops to ~220GHs The weird thing is that on both 3334 and 12234 the start diff is 128, so there should be some other difference between them and the problem is not with the start diff, which for Slush is 3, but still reaches the max miner speed in ~1 min Are you using the latest KnC firmware with BFGMiner? |
|
|
|
Port 12234 is not working and on 3334 still can't reach good hashrate
There is no port 12234. Sounds like you need to upgrade your miner. |
|
|
|
Looks like it's back up...
It's not. You shouldn't even be able to connect, since I killed all the public-facing servers until wizkid057 can fix them. |
|
|
|
|
Looks like PostgreSQL has failed.
I don't seem to have access to fix it, so it will have to wait for wizkid057 to get up...
(no answer on his cellphone)
|
|
|
|
Have you looked at OpenWrt and/or OpenEmbedded?
Not saying they're perfect or will cover your needs, but they might be worth considering if you haven't already.
Thanks for the suggestions, and yes I have. Add buildroot to the mix and they are my three finalists. All three work but all three have their pluses and minuses, I have been able to get my code, your code and cgminer working on all three. Picking as clear winner is a bit of an issue though, I am kind of hoping that I will come across an 'unfixable issue' so I can choose . Do you have any preference? As a miner developer I would certainly give you opinion a lot of weight. I've only used OpenWrt and OpenEmbedded, so between those two, I think I prefer OE since it is based on Gentoo's Portage and uses a BASH script format (unless things have changed since I last used it about.. 8 years ago?). On the other hand, it may be helpful to you that I maintain OpenWrt repositories for BFGMiner. I found it a bit cumbersome to make it work with their Makefile system. But, OpenWrt has a nice menuconfig too... |
|
|
|
At present I am doing some very complicated stuff at the OS level for the 0.3.0 release (out of necessity). Using Arch Linux (or any other 'stranded distro' for that manor) leads to a lot of uncertainty with the package maintenance system that can catch the poor end user out in unfortunate ways. To that end I am working on building an entire embedded linux OS that will improve;- 1. Maintainability 2. Stability 3. Performance 4. Portability The idea is that one "make" will turn out images for a PC, a Virtual Machine, the BBB and the Pi. If any manufacturers want, they can grab my code (when released) and create their own build target OR they can get me to do it for them (begging for work to supplement my reduced income  ). Have you looked at OpenWrt and/or OpenEmbedded? Not saying they're perfect or will cover your needs, but they might be worth considering if you haven't already. |
|
|
|
Nope, was on 3.10(thought that was the latest, so does google), now it sees the BFX, mining at 4.2GH/s! which is fine for me, calls my ICA's BES though for whatever reason. Wow, a real world Icarus is still mining?  Block Erupter Sapphires are more common, so BFGMiner 4 assumes them by default. You can tell it that it's an Icarus with -S icarus:all |
|
|
|
ok so i put in "bfgminer.exe -o stratum+tcp://mint.bitminter.com:3333 -u < my user> -p <my PWD> -S bfx:all --set bfx:osc6_bits=54"
and got "bfgminer.exe: --set: unrecognized option"
Note: I'm a serious noob to most of this. I'm used to bitminter's GUI based mining program and have mostly overclocked antminers through it up til now. I've exhausted their help and just reading through here before posting this. Other than that I've gotten a Red Fury to work at base speeds by finding its driver but that's it.
Are you using 4.0? |
|
|
|
|
Show Posts
