|
Just experienced a crash with cgminer 2.9.7 on Windows. Two miners crashed at the same time. I'm using stratum on BitMinter. Didn't have any crashing problems before with 2.9.x versions, and I saw this on the patch notes:
"Windows builds are built and shipped with a new libcurl (and libusb) dll that hopefully improves stability."
Could this be actually causing problems instead of improving stability? If it's possible, I'd be interested in trying out a build with the old dlls.
|
|
|
|
Are we gonna wait HPC software like BFL ASIC's ?
hpc work is GPU based... I believe Zubilica meant that the HPC software is getting delayed again and again, just like the ASICs. However, CoinLab is delivering on their loyalty points promise, so that comparison is a bit moot. People are already getting returns for their 'investment' on CoinLab. |
|
|
|
|
From earlier posts I gathered that dynamic difficulty is adjusted per worker connection, so I could have a fast miner doing high difficulty shares and a slower miner doing diff 1 shares on the same worker account. However, all my miners are doing diff 1 shares when vardiff is set to -1. The fastest is just 2GH/s, so it might not be enough to trigger a change. I tried manually adjusting vardiff to 4, but my miners are still doing difficulty 1 work after reconnecting. Do I have to disconnect all miners simultaneously before the change takes effect, or could there be some other issue?
|
|
|
|
|
Even though cgminer 2.9.7 indeed has very minimal rejects on BitMinter, should the vardiff code still be adjusted to avoid constantly changing difficulty? Have slightly different threshold levels for increasing/decreasing the difficulty, or use a longer time period for averaging shares per minute. I'm not sure if I correctly understood the information on cgminer's thread, but it seemed to indicate that changing difficulty has the potential for some lost work because of latency.
I see that my hashrate estimate has a lot more swings when mining on stratum. With higher difficulty shares, the averaging period should obviously be longer to get a meaningful estimate.
|
|
|
|
|
Rewards page isn't working correctly anymore, it seems to assume a 50 BTC block reward for the expected average.
|
|
|
|
Thanks for testing, guys! Just restarted with some tweaks to var diff and logging, and fixed the stats issue.
Testing continues. Let me know if you have any issues at all on the test port. So far things are running very well and I'm considering setting this up on the main port very soon.
I forgot to mention the new version also has some decent reduction in CPU usage. It will be interesting to see the effect all these changes will have on CPU usage and reject rates.
Running good here. One thing I'm seeing is the server can't seem to decide what difficulty to give. Largest miner is ~2.6GH/s. At startup, it's on difficulty 2. Then it switches to 1. Then it switches back to 2. Right now it's on one. I'm also confused why cgminer is submitting shares that are under difficulty. M It's changing between 2 and 4 for me. Reject rate is ~1.5% ~1.9%. |
|
|
|
|
That's not going to work unless your hardware supports PCI passthrough. Most likely it doesn't, unless you specifically shopped for that feature.
|
|
|
|
I am also running 2.9.5 testing GBT. Not many rejects: A:54005 R:46. And I haven't seen any rejects that didn't happen at a block change.
Seems like we need a bit more testing. Anyone else seeing something like that?
I stopped having those rejects after changing all my rigs to BitMinter GBT. Could be just bad luck, but is it possible that having difficulty change dynamically may cause that kind of rejects? I don't have a good understanding of how dynamic difficulty works. At first the difficulty hovered around 1-2, but after pointing all the rigs at BitMinter GBT it's been stable at 4. EDIT: Now my share difficulty went up to 8, and dropped back to 4 soon afterwards. If my hashrate is just about at the threshold between 4 and 8, at least I'm testing the dynamic difficulty thoroughly. Yup, it's been changing between 4 and 8 for some time now. |
|
|
|
|
I'm trying out BitMinter's GBT server for the first time, and got strange rejects on cgminer 2.9.5 almost immediately:
[2012-11-28 00:50:30] Rejected 33f2f1eb Diff 4/4 GPU 2 pool 0 (unknown-work)
[2012-11-28 00:50:38] Accepted 3b537d2f Diff 4/4 GPU 0 pool 0
[2012-11-28 00:50:47] Accepted 387a7e01 Diff 4/4 GPU 2 pool 0
[2012-11-28 00:50:57] Accepted 34475128 Diff 4/4 GPU 2 pool 0
[2012-11-28 00:51:03] Accepted 378ea469 Diff 4/4 GPU 0 pool 0
[2012-11-28 00:51:46] Accepted 1c1a6472 Diff 9/4 GPU 1 pool 0
[2012-11-28 00:51:47] GBT LONGPOLL from pool 0 requested work restart
[2012-11-28 00:51:49] GBT LONGPOLL from pool 0 requested work restart
[2012-11-28 00:51:57] GBT LONGPOLL from pool 0 detected new block
As you can see, it comes seemingly in the middle of a block. I can't get a clear understanding of what's wrong with those, since a similar problem was supposed to be fixed in 2.9.4.
|
|
|
|
Got the payment, if the normal pool is switching to 95% too, than i am going to pool who has instant payouts for now. When the client will be ready and it will be possible to redeem loyality points, than i will return  According to CoinLab's latest post, it's already possible to redeem loyalty points. It's just not profitable to do so now, until the block reward is halved. I'm also going to move to another pool temporarily when the normal pool is switched to 95% PPS. With 98%, I would've stayed with CoinLab. |
|
|
|
|
Anybody getting a correct hashrate reading on the normal pool? For me it peaks at about 85% of my real hashrate. I know there still is a display issue with hasrate on the protected pool, where it shows you the effective hashrate, which is 95% of your actual hashrate. By the same logic, the normal pool should be showing 98%, while for now it's 85%. The graph is showing my true hashrate, so this is just a problem with the "Estimated hash rate (based on a 30 minute trailing average)" reading.
EDIT: Works now, it just took a few hours, not 30 minutes.
|
|
|
|
So how do I switch to the "normal" pool? I really don't feel like staying on the "protected" 95% pool if I am no longer pulling in loyalty points. I might as well just pull my rigs off and go somewhere that doesn't have a 5% fee.
The signup link is in the first post. It would've been nice to change the protected pool to 98% also, during this phase when loyalty points can't be redeemed or earned. |
|
|
|
|
Just noticed a weird bug with the hashrate graphs: when I'm logged into both normal and protected pool, the normal pool shows me the hashrate graph for my protected pool account. If I log out of the protected pool, I don't see any graph for my normal pool account, just the "mh/s vs time, all workers" text. I have the same username on both pools.
EDIT: The issue cleared out by itself, I suspect it happened because I had just started mining on the normal pool.
|
|
|
|
|
So the users on protected pool are just paying extra because they haven't changed to the 98% pool yet? Seems that I can't use my protected pool credentials to mine on the normal pool.
|
|
|
|
The share rejection problem I have on EMC (described a few posts ago) isn't connected to stratum. I'm using http://us2.eclipsemc.com:8337 as the URL and miner.php says it's not using stratum. I'm not sure if it's using GBT, though. How do I check that? |
|
|
|
|
Noticed a share rejection problem with 2.9.5. I removed failover-only from my config because share leakage is lower, only ~0.01% of all accepted shares are sent to backup pools now. My setup on all rigs is the same, CoinLab as the main pool, BitMinter as first backup and Eclipse as last resort. All the accepted leaked shares go to BitMinter, and that's no problem anymore because they are so rare. However, my miners only gather rejects on Eclipse, about 10 rejects for every share leaked to BitMinter. No shares have been accepted on Eclipse so far, and one rig has already marked it as Rejecting.
If I also account for rejected leaked shares, the total amount is still only ~0.1%, so it doesn't matter much. But this definitely isn't behaving correctly now. I can help testing this if it's not obvious what the problem could be.
|
|
|
|
What is "Harmful miner version detect" - using 2.6.1 on bitminter?
If you run a cgminer or bfgminer version below 2.7: You are causing yourself and all other miners to lose transaction fee income on the blocks you make. You were causing slow server response and a high reject ratio, before these changes. You are getting work slower than others on the pool. You are probably getting more stales too. I know this isn't something you intended to do and you may not have been aware of it before. But you are running a very old miner version with some serious bugs in it. Upgrade today! |
|
|
|
jjimm_64 this has nothing to do w/ your own profitability past the reward halving (at least when it comes to power consumption) It clearly is said 2.50$/gh/day .. PERIOD.
Another point is, what if BTC price doubles .. and actually stays above the 2.50$/gh/day when the reward halving comes... highly doubt that would be the case, but lets just say...
That would give us potentially a few more weeks till asic changes that.
So, if the above were to happen... that gives another month of my GPU's making loyalty points.
So, therein again, coinlab would be going back on their word they very clearly stated at the start of this thread =(
It really sucks..cuz that would mean another month of income into the ASIC era. Lets say CL takes longer than expected landing these HPC jobs...and we end up running out of loyalty points till they deliver on HPC..well thats a huge problem for people that were depending on them to deliver. Rather than going back on their word.
Actually thats a sign this was all a hoax to begin with.. =(
Nothing forces you to use loyalty points until you choose to do so. Their lifetime was even extended to 2 years. Let's assume that after reward halving 1GH/s day produces $1.75, and after ASICs have arrived, that goes further down to $0.25 per day. In that case it might be a good idea to mine at some other pool when 1GH/s day still produces $1.75, and wait until profitability really tanks before you start using loyalty points at CoinLab. BTW, another quote that states the price floor rule very clearly: Current payout is 95% PPS. When earnings drop below $2.50 per 1GH/s for 24 hours, we pay $2.50. The number of shares you can submit at the price floor is the number of shares you submitted before it dropped. There's only about 8 days left for miners to earn them, unless something drastic happens to BTC. Are you really going to abruptly stop issuing those points before reward halving? Perhaps it might be wiser to not back on your word and issue the points until reward halving, as was promised? |
|
|
|
|
I don't understand why you have assumed that loyalty points continue accumulating even after price goes below the $2.5 / GH/s day floor. Maybe if you completely ignore the whole price floor rule, and just look at the more vague statements with terms like "couple of months". The first rule (quoted on this page already) clearly says that you'll only get loyalty points until profitability falls below the limit. Loyalty points should be accumulating exactly until the reward halving, unless some wild price change makes the outcome different.
|
|
|
|
Um....ur gonna stop issuing loyalty points?!?! Thats real shady of you to do that. You clearly stated loyalty points will be made right up till a share drops below 2.50$/gh/day .. now ur saying ur gonna just stop regardless?! So, in effect, going back on your word.
It should be maintained till it actually drops below 2.50$/gh/day. Like was originally stated in this thread.
+100 I will have to stick up for coinlab on this one. they did it for 2.5 months. which according to the OP is .5 more months then they said they would do it. For the next couple months, you can earn credits with the miner of your choice. Once we release it, we will only accept credits submitted by our custom mining client (co-developed with Con Kolivas, the creator of cgminer), as it will allow us to perform other, more valuable compute jobs when available.
Dude, really? Look at the bullet point above the one you quoted: For every difficulty 1 share (from here, called a credit) you submit above break even (equal to our price floor factoring in our cut - $2.50 / 1GH/s day / 0.95 = ~$2.63 / GH day), you earn 95% PPS for that credit and one Loyalty Point which lets you sell one credit at the price floor ($2.5 / 1GH/s day = $0.00012427 PPS). It clearly states what Im saying. Them going against it is them turning on their word. Plain and simple. That is the rules on how to earn a credit, then on the next line it says they will give them out for a couple of months.. pretty straight forward. You guys are 'hearing what you want to hear' instead of taking things at face value. You interpret that next line in a very weird fashion. It's quite clearly a rule about what software you can use to earn those loyalty points, implying that they would release their custom client after those 'couple of months'. Now it suddenly overrides the way more precisely defined rule about the price floor? I would understand this if they actually had that custom client, for both Linux and Windows. |
|
|
|
|
Show Posts
