Nice additions Flound.
what is multiport.in:7777 vs adding pool1.us.multiport:7777? in the -o in cgminer. thanks
multiport.in goes to pool1.us. |
|
|
|
On the new account page, how do we set or change the worker's password?
You don't need to, none of the pools check passwords. |
|
|
|
The new account details page is now live.
Features:
- Per-worker user-selectable share difficulty! (Currently in BETA, only works on pool2.us.multipool.in which is also in BETA. If you want to test this, please set pool1.us as a backup and please report any issues)
- More concise display!
- More ads!
- Worker deletion should now be reliable and not delete the wrong worker.
- Active worker display with 1 minute and 10 minute hashrate for all workers that have submitted shares in the last 10 minutes.
That's awesome! I tried the beta pool (stratum+tcp://pool2.us.multipool.in:7777) but got "Failed to resolve..." Oops, try again now. |
|
|
|
Hi Flound,
I was thinking it would be nice to know current BTC value of items in your payments area under the account detail. Kind of like the profit snapshot but instead using what is already been paid out and is sitting there not cashed out yet under payments area. I don't know how difficult it would be to implement. I don't cash out everything everyday and sometimes I wondering what all these non cashed out alt coins are worth currently. If I only have one alt coin its easy to go check against the current price, but with lots of different alt coins it is not as easy.
Thanks
Good idea! I've implemented this. |
|
|
|
|
The new account details page is now live.
Features:
- Per-worker user-selectable share difficulty! (Currently in BETA, only works on pool2.us.multipool.in which is also in BETA. If you want to test this, please set pool1.us as a backup and please report any issues)
- More concise display!
- More ads!
- Worker deletion should now be reliable and not delete the wrong worker.
- Active worker display with 1 minute and 10 minute hashrate for all workers that have submitted shares in the last 10 minutes.
- Current BTC value is displayed alongside account balance.
|
|
|
|
MEC transfer finally confirmed, you should be able to withdraw now.
Hi Flound Does your todo list include looking into enhancements of the cash out process, e.g.: - an intermediary step after clicking to cash out, i.e. "You selected to cash out XYZ, are you sure? (yes/no)" - for cases where the hot wallet is low / empty - perhaps a pop-up message along the lines of "Apologies for the inconvenience, but the hot wallet is still awaiting confirmations for coin XYZ. Your cash out cannot be processed at this time. Higher powers have been informed and will get back to you.." and if there is an approximate estimation of time you can give for the confirmations, that always helps.. and if you can also add an option like "Would you like your cash out to be added to the queue for processing as soon as there is sufficient availability in the hot wallet [although it is advisable that you use the Auto Threshold option]? (Yes/No)" Yes I do want to revamp the entire cash out/payment process, just haven't had time recently. |
|
|
|
2Gh/s and 2.5 W? If you can ship in september, max 5 BTC from me
You can make it auction-based sell for ready to ship products
I'd be interested at $50/GH definitely |
|
|
|
I have finally gotten some mining going after a lot of fooling around with drivers. I'm running xp 32 bit, Radeon 6670s, sdk 2.5 and catalyst 11.7. I have two machines that I believe are almost identical. However one I have running fine at 94 khash/sec.
The big problem is the other machine that seems to be getting a lot of hardware errors (hw). Anyone hav any ideas what can cause this? I'm just running it standard with I 15 and have tried fooling around with the core
Clock and memory. Thanks for help I just don't understand hat can cause hw errors.
Btw this is scrypt mining, coincidentally at flounds pool multipool.in. An yes this stratum issue is really annoying, hits both my miners to cause often disconnects which I can only assume are slowing my hashing. I've never gotten good results with I > 13 on any of my miners. |
|
|
|
I've been using your pool for a little bit now, and it's a great idea. I've been concerned since I can't keep on top of it enough and lose profitability probably, so I give up (plus not having wallets for every coin bugs me), but what do people do to minimize that? Use APIs to auto-trade or something? Anything out there like that or should I just chill and let my meager hashing slowly raise up the random coins and cash out when they get profitable again and I hit one coin?  While prices rise and fall, and there is always a risk a coin's price can crash, most of the profitability fluctuation is due to mining difficulty and not prices. |
|
|
|
Pretty newb question here - is it possible to connect to pool using minerd?
As far as I understand I need to connect using stratum so would a combo of stratum proxy+minerd work?
Or do I need to set up cgminer to work on cpu?
The multiport has a getwork port on 17777, you can't mine anything directly with getwork though. The latest version of cpuminer supports stratum protocol though. |
|
|
|
block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...
In this scenario, miner A would have 4 difficulty-64 shares submitted before the first block boundary, and one aborted. The miner using 512 difficulty shares has not finished one share yet and so he loses the equivalent of ~4.5 difficulty 64 shares when he restarts work. Miner A is expected to have 4 shares, but may get less or more, in some kind of distribution around that. Miner B is expected to get 0.5 shares on average. They work out to the same thing. The work isn't in discrete blocks like that. It's a probability. So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying. I think something else to take into consideration... I am not 100% sure if this is how it works so someone please set me straight, but let's say you have 4 cards at 500KH/s. GPU0, GPU1, GPU2, GPU3 would each be carrying their own workloads, therefore while you could have 50000 million hash rate due to tons of GPU's, each GPU is still a separate animal working on things independently. This could be wrong, but it's what I infer from CGMiner's reports, especially being that it separates the work load of each GPU in its outputs. I think that's right, if you have 4 gpu's you have 4x the chance to solve a share in time X. |
|
|
|
Why does this happen? https://i.imgur.com/BPqpMjU.pngIn cgminer I have queue="1", why is cgminer continuing to submit difficulty 16 shares after the pool diff changes to 32? This is in 3.3.1. Irrelevant of the value of queue, it is not ideal for cgminer to throw away work it is doing (or just done) when diff changes. Tell the pool to fix their code. ... an issue with stratum that was swept under the carpet with a hack. I am the pool, and this code isn't live yet. I'm trying to patch stratum to do it the correct way. What do you suggest? |
|
|
|
Anyone have any clue why multiple people have noticed weird hashrate increases a few nights ago while using LTC in cgminer? See the posts here: https://bitcointalk.org/index.php?topic=260642.msg2789664#msg2789664Apparently over the night a few nights ago, while tinkering with my 7970 (which was not performing as well as it should be, but it never has), it just decided to work while I was sleeping. Upped the hashrate from 522KH/s to >700KH/s (which it should be getting) for no reason. I checked it's status the next morning, and it instantly decided to go back to it's slow 522KH/s. Havn't been able to get it back up to the faster speeds since. This wasn't just CGMiner mis-reporting the hashrate, either. The WU: rate was much higher than it had been. And other people have noticed similar issues. I'm not sure if their issue was the same night as mine, as I think our dates were 1 night off. Any help would be appreciated. Thanks!  |
|
|
|
Why does this happen?  In cgminer I have queue="1", why is cgminer continuing to submit difficulty 16 shares after the pool diff changes to 32? This is in 3.3.1. |
|
|
|
Something wrong with web site, i see "mining FTC" for a long time, it seems like site going down 3 hours ago.
Damn janitor must tripped over a wire again.. <whistles nonchalantly> |
|
|
|
Is anyone else having trouble withdrawing MEC ?
When you click the cash out all I get is a page refresh, coins stay put.
Plz check it out
T.
Wow, I noticed the wallet was getting a little low earlier, so I sent over 2000 coins. Looks like those have been withdrawn already so I sent over another 4000. You should be able to withdraw soon. Thanks, that has resolved it! BTW love your pool, and the work that you have put into it. Have been with you for few months and I appreciate all the improvements you've made in terms of coin support and improved connectivity. Used to pool jump all day long, but its crazy how many scamming pools are out there... Nowdays I use your pool pretty much exclusively apart for few drop outs you experience once in a while. Keep up the good work and I'm going to up the donation % Thx again T. Thank you! |
|
|
|
So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying.
Yeah. I don't believe it affects profits. But lots of people are saying it is. So I'm still thinking about it to see if I'm wrong. With https://github.com/CryptoManiac/stratum-mining, I'm getting: File "/home/pushpool/stratum-mining-novacoin-testnet-cryptomaniac2/mining/DBInterface.py", line 33, in connectDB
if settings.DATABASE_DRIVER == "sqlite":
exceptions.AttributeError: 'module' object has no attribute 'DATABASE_DRIVER'I must have some module installed wrong. Did you get that? Thank you so much for the suggestion on which branch to use. I was spinning my wheels trying to get a few others to work. I don't actually use that, but you can pull template_registry.py out of it for the changes you need. Edit: and bitcoin_rpc.py |
|
|
|
block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...
In this scenario, miner A would have 4 difficulty-64 shares submitted before the first block boundary, and one aborted. The miner using 512 difficulty shares has not finished one share yet and so he loses the equivalent of ~4.5 difficulty 64 shares when he restarts work. Miner A is expected to have 4 shares, but may get less or more, in some kind of distribution around that. Miner B is expected to get 0.5 shares on average. They work out to the same thing. The work isn't in discrete blocks like that. It's a probability. So the payout amounts will just be more volatile/random for the lower hashrate miners is what you're saying. |
|
|
|
FWIW, here's why I think share difficulty matters. When a new block is found on the network, every miner drops the share it's working on and starts working on a new share from the new block. Sometimes, the miner doesn't get the notification fast enough and submits the share anyway (which then becomes a stale/reject). On average, each miner should be about halfway through a share on a block boundray. In this situation, a miner sumbitting e.g. difficulty 64 vs one submitting difficulty 512 shares (at roughly the same hashrate) would look like this: block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64][64][64][64][64][64]||[ ...
(B) [---------------512||[---------------512-------------][ ...
In this scenario, miner A would have 4 difficulty-64 shares submitted before the first block boundary, and one aborted. The miner using 512 difficulty shares has not finished one share yet and so he loses the equivalent of ~4.5 difficulty 64 shares when he restarts work. Now, you could say that over time, this would even out (I am doubtful of that.. But..) Consider when the miner is not very fast. Now you have the following situation: block boundary (||)
(A) [64][64][64][64][64||][64][64][64][64||][64][64][64|][64][64||[64][64] ...
(B) [---------------512||[------512------||[---------512--------||[------- ...
Miner B in this scenario loses many shares because blocks are being found faster than he can find a share. It looks like your pool is already up to around 300 MH, which means that on fast coins you are probably finding multiple blocks per minute. At 512 share difficulty, I doubt a 300KH miner can even find a share in a under a minute on average. It takes a 650KH miner about 6 seconds on average to find a diff 64 share. So a diff 512 share would average around 48 seconds. I think people with large rigs that do 2000KH or more are going to receive a disproportionate amount of the rewards on your pool due to the high share difficulty. |
|
|
|
|
Show Posts
