Anyone have an issue with 21384? I was hashing before, during and after the block with no downtime.
21384 2014-01-06 03:05:31 2:42:21 1435249005 none none 278862 25.18020923 88 confirmations left
EDIT: Several of you posted while I was typing the original msg. Thanks, I see it's been submitted.
Guess submitting a ticket gets less attention than I thought. I remember reading some hundreds of posts ago that once a round has gone confirmed, that it's very difficult to get an adjustment. 21384 2014-01-06 03:05:31 2:42:21 1435249005 none none 278862 25.18020923 confirmed |
|
|
|
|
Anyone have an issue with 21384? I was hashing before, during and after the block with no downtime.
21384 2014-01-06 03:05:31 2:42:21 1435249005 none none 278862 25.18020923 88 confirmations left
EDIT: Several of you posted while I was typing the original msg. Thanks, I see it's been submitted.
|
|
|
|
Another member - Sunriselad - beat you to it and created a utility to do most of this. It's called Mine Minder, and includes the block values, pool hash rate, and current difficulty. It also displays a current bitcoin value, but I do not
Thanks for the info Sir Alan, but the program you are referring to requires windows. Although I do work on a windows workstation daily, it's not on 24/7 but I do have several linux VPS's running 24/7, which is why I wanted to use php/mysql. Also, I'm not sure if the windows app just shows live info, or actually collects and stores the data for later use. My intention is to store the info in my own database so I can use it to do long term ROI calculations. Something that tells me over a longer period of time what my daily revenue is, minus hardware costs etc etc. Kinda like the online calculators you can find everywhere, but then specific to my hardware, slush's pool, and not as a a forecast, but looking back. Maybe a forecast would be a nice to have so that I can predict how much longer my hardware remains in the money, but I'll have to see how much time I'm willing to spend on this!  Well, if you don't mind writing ugly code <grin> then think this would be doable in a macro for calc (apache openoffice) to snap your html stats page every so often and extract data from new rounds since last query -- could also grab your account page to check on worker health. Another macro to run the ROI stuff, another macro for any statistical analysis you might want to do, and a macro to merge current data into your mysql db if you decide not to keep it in calc. This approach would also be more or less OS independent. |
|
|
|
So I just added 10gh/s to my total setup, everything is reporting full hash on Slush's site but my estimated reward doesn't look bumped up much at all. Does this mean everyone else plugged in 10gh/s at the same time as me? Or did we get more members so proportionately I'm nearly unchanged? Or does the estimated reward need more time to catch up? Perhaps I was expecting to see more of a bump, I mean it's a little bit higher but not much.
The pool hash rate is changing all the time, but say it was 400TH/s when you plugged in (it's 422TH/s as I write this), and where in the round you connected affects the reward as well, but in terms of hashing power 10GH/s divided by 420TH/s times 100% = a relative increase of 0.0025% for the pool, so yeah, the reward bump wouldn't be a lot. |
|
|
|
Question on payouts -- sometimes my payouts show up in the wallet as "Received with", sometimes they show up as "Mined" -- what's the difference, other than "Received" matures in 6 confirmations while "Mined" doesn't mature until 120 confirmations?
Essentially, "Recieved" transactions are bitcoins that came from another account. "Mined" transactions are bitcoins that were generated; as part of the block reward. They did not come from anybody; they "appeared" out of thin air. The Eligius mining pool usually distributes each miner in the pool it's reward as part of the "generation" transaction of each block. Other pools put the reward in an account they control, and send it to the miners when they request it. Many here believe Eligius system is superior (apart from the inconvenience of waiting for the 120 confirmation maturation time) because Eligius never actually controls any bitcoins: Therefore Eligius cannot be hacked and stolen some coins, neiter can the pool operator run away with the money. However, it occasionnaly happens that there is a problem, and the reward system cannot correctly put each miners reward in the generation transaction correctly. In those cases, the reward is indeed sent to an Eligius-controlled address, and sent to the miners ASAP, usually not more than a day after it was due. However, in those cases, you see the reward as a "recieved" transaction, and not a generated transaction. However those issues are occasionnal. EDIT: Fixed some typos Great explanation -- ty. |
|
|
|
I just had an idea I want to throw here, and you'll do whatever you want with it:
It would be great you could run a similar pool for Litecoin! It's one of the few trustable altcoin, and it's pretty much the last place we can spend CPU and GPU hashing power and not spend more in electricity.
Eloipool and wizstats are really well done software, and you guys seem really honest and devoted to your pool, so I believe it would be as awesome with Litecoin. It's because we're honest that we won't get involved with scams like Litecoin. lol, and yet bfgminer supports scrypt  |
|
|
|
How do i do merged mining on this pool... And what are the coins i can merge with?
Slush's pool doesn't do merged mining anymore. |
|
|
|
|
Question on payouts -- sometimes my payouts show up in the wallet as "Received with", sometimes they show up as "Mined" -- what's the difference, other than "Received" matures in 6 confirmations while "Mined" doesn't mature until 120 confirmations?
|
|
|
|
|
Any chance we'll see a new scan flag that says either "scan all except dev:port" or "scan range dev:port-port" ? Would be great for systems where non-mining devices like a keyboard that never moves needs to be protected from scan data while miners are frequently being added or moved around in the usb chains, which currently mean lots of config file changes to limit scan to the mining ports.
|
|
|
|
guys, it of a newb here, apologies but I cant find an answer to this anyway what do these two things mean  and this  thanks Steve Stats under Accepted and Stale -- the first number is total since the current instance of guiminer started on that miner, and the number in parentheses is the total in last hour. For the verification thing, here's a quote from an old post in another subforum that may pertain to your problem. I had the same problem today getting the "verification failed" message on 13.2 drivers and then having guiminer and every other miner crash on start up after switching to older drivers. What I did was uninstall all AMD software/drivers, reboot and install catalyst 13.1 drivers. Then I followed the steps listed here: http://forums.guru3d.com/showthread.php?t=359883 and now it's working fine. |
|
|
|
hello i need help i have a problème whit pay out !!! it does not work!  From the FAQ: Your confirmed balance will be send to you once it crosses over Send threshold (minimum 0.05 BTC). Pool is sending payouts automatically every 15 minutes. |
|
|
|
|
Final report: loaded bfgminer 3.6.0 -- running stable 21 hours now. Maybe bfgminer conserves resources better than cgminer on a RasPi so will keep it for now, but looking forward to trying cgminer 3.9 in the future.
|
|
|
|
did anyone got problem with shares and reward gone to 'NONE' and my last 3 or 2 gone to 'NONE' .
I've had some cgminer stability problems last few days and got lots of "none" blocks that never resolved to an amount -- thought was due to cgminer. Switched to bfgminer on 11/26, running solid since, but still getting the occasional "none" 20966 2013-11-27 15:00:33 0:29:21 Processing... 271779 25.09968134 97 confirmations left 20965 2013-11-27 14:31:12 3:28:41 Processing... 271776 25.09335376 94 confirmations left 20964 2013-11-27 11:02:31 0:52:05 157007156 42896 0.00409060 271761 25.03167140 79 confirmations left 20963 2013-11-27 10:10:26 1:06:26 416339194 102847 0.00324965 271753 25.05967676 71 confirmations left 20962 2013-11-27 09:04:00 2:07:31 616134876 none none 271745 25.04038353 63 confirmations left 20961 2013-11-27 06:56:29 5:38:43 1643271777 none none 271726 25.24489311 44 confirmations left 20960 2013-11-27 01:17:46 2:30:34 736466853 174247 0.00580112 271685 25.01920044 3 confirmations left 20959 2013-11-26 22:47:12 1:06:40 327605438 77621 0.00583897 271671 25.45945221 confirmed 20958 2013-11-26 21:40:32 5:47:49 1701230114 459959 0.00400610 271666 25.21426441 confirmed 20957 2013-11-26 15:52:43 0:02:35 12301112 6300 0.01227533 271627 25.10929891 confirmed 20956 2013-11-26 15:50:08 2:06:37 621115370 68172 0.01158849 271626 25.31762960 confirmed 20955 2013-11-26 13:43:31 4:16:28 1269260019 none none 271612 25.06672930 confirmed 20954 2013-11-26 09:27:03 6:10:40 1798179211 413442 0.00000000 271587 25.35120125 confirmed 20953 2013-11-26 03:16:23 2:33:55 734657898 265785 0.00921901 271550 25.04570732 confirmed 20952 2013-11-26 00:42:28 0:18:33 88716980 27388 0.01160630 271525 25.19391657 confirmed 20951 2013-11-26 00:23:55 0:06:57 32811214 none none 271523 25.01478660 confirmed 20950 2013-11-26 00:16:58 0:21:52 104018863 none none 271520 25.00301320 confirmed 20949 2013-11-25 23:55:06 2:39:44 762343487 none none 271516 25.13234146 confirmed 20948 2013-11-25 21:15:22 0:17:50 83955229 none none 271499 25.05621381 confirmed 20947 2013-11-25 20:57:32 11:09:06 2147483647 536259 0.00000000 271496 25.09004834 confirmed 20946 2013-11-25 09:48:26 0:33:53 159862999 none none 271416 25.20706472 confirmed 20945 2013-11-25 09:14:33 0:57:03 268354936 none none 271413 25.25596349 confirmed 20944 2013-11-25 08:17:30 1:36:32 454006445 216742 0.00474413 271406 25.25688233 confirmed 20943 2013-11-25 06:40:58 1:16:19 357469243 168759 0.01110069 271392 25.03015945 confirmed 20942 2013-11-25 05:24:39 4:54:27 1386589555 406404 0.00000000 271378 25.04423068 confirmed 20941 2013-11-25 00:30:12 1:33:46 442803138 81319 0.01159345 271348 25.17870377 confirmed 20940 2013-11-24 22:56:26 5:27:43 1557705970 980 0.00000000 271337 25.05226491 confirmed 20939 2013-11-24 17:28:43 2:05:27 591953516 259643 0.01121454 271292 25.11640732 confirmed 20938 2013-11-24 15:23:16 1:40:41 474424287 106782 0.01343919 271274 25.04499037 confirmed 20937 2013-11-24 13:42:35 0:37:25 174694085 none none 271267 25.08234628 confirmed EDIT: Following Processing/none blocks just resolved to an amount 20966 20965 20962 20961 |
|
|
|
|
Let me think, and please correct me if you spot an error: when a pool finds a block, payouts are based (with variations in the scoring formula, transaction fees, and pool fees) on 25 * work_i_did / work_pool_did. Say I'm a small miner in a medium-sized pool who sees ~0.01 BTC per round, meaning I'm doing about 0.04% of the pool work, and the pool finds an average of 36 blocks a day (that is, about one out of every four blocks) and I find a block once a year on average.
The proposed reward system is to give 18.75 BTC to the finder who then gets no credit for the work the finder contributed to the pool for that block. That leaves 6.25 BTC to split between me and the other miners. Now, work_i_did / (work_pool_did - work_finder_did) is still very close to 0.04%, which means I could expect a payout not much over 0.0025 BTC each round.
Disregarding changes in difficulty and network hash rate, under the current system, I make 1 BTC every 100 rounds (2.78 days) or a total of 131 BTC per year, under the proposed system it would take me about 400 rounds (11,1 days) to make 1 BTC, or 32.85 BTC per year plus the 18.75 I'd get for finding my one block = 51.60 BTC a year.
Nope, I think I'll stick with the current system.
|
|
|
|
|
Mebbe Slush gotta run front end in manual mode atm and he's afk. Happened before, but things eventually catch up.
|
|
|
|
At least linux emails esoteric error messages to your inbox instead of cluttering up the screen with 'em |
|
|
|
I speak of semaphore limits, not ram or cpu. Defaults on RPi are quite restrictive.
Thanks for the tip -- cat /proc/sys/kernel/sem showed: 250 32000 32 128 I've doubled it to 500 64000 32 256, so we'll see if that helps. Will let you know. Well, thinking that was the solution I took a long break -- got back to see cgminer only ran 9 minutes before throwing the same sem_post/callback error  On restart, it ran a bit over 5 hours then same error. Spose it could be hardware -- will load up bfgminer to see if I have the same prob. |
|
|
|
I speak of semaphore limits, not ram or cpu. Defaults on RPi are quite restrictive.
Thanks for the tip -- cat /proc/sys/kernel/sem showed: 250 32000 32 128 I've doubled it to 500 64000 32 256, so we'll see if that helps. Will let you know. |
|
|
|
Looks to me like you're running out of resources on your RPi device.
So, I've been watching top for awhile thru ssh and the snapshot below is about as busy as it gets (only showing 4 "busiest" tasks). Didn't see any change in free mem past 30 minutes. top - 21:06:23 up 1 day, 17 min, 2 users, load average: 0.38, 0.36, 0.40 Tasks: 70 total, 1 running, 69 sleeping, 0 stopped, 0 zombie %Cpu(s): 11.7 us, 14.9 sy, 0.7 ni, 71.5 id, 0.0 wa, 0.0 hi, 1.1 si, 0.0 st KiB Mem: 448736 total, 248020 used, 200716 free, 44180 buffers KiB Swap: 102396 total, 0 used, 102396 free, 157248 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10617 root 20 0 243m 4820 2704 S 22.1 1.1 14:40.26 cgminer 2213 root 20 0 24452 7464 2340 S 2.3 1.7 20:40.24 wicd 2249 root 20 0 14980 8048 3996 S 1.3 1.8 9:13.03 wicd-monitor 16550 pi 20 0 4808 1620 1032 R 1.3 0.4 0:03.76 top Edit: Couple hours watching top and cpu loading is the same, though I do see a slight decrease in free memory (about 700KB) -- a little exploration showed it matches increases in the various log files, but this tells me running out of memory is probably not the cause of the random sem_post problem. |
|
|
|
|
Running cgminer 3.8.2 on Raspbian with 8 BFL ASICs connected. App intermittently quits to command line with status dump (anywhere from ~2 hours up to ~11 hours between failures) with the following error reported:
"Failed to sem_post errno=38 cgsem=0x0xa8cfd7d8 in usbutils.c.transfer callback():2358"
If the app is using the standard error.h, this refers to trying to do a socket operation on something that's not a socket. Any ideas?
Other than this issue, seems to be a great app.
|
|
|
|
|
Show Posts
