How they are redirecting is the cause of their problems. It really makes no sense at all to even allow a redirect to a different pool. The logic behind blocking it is quite sound. If a 'pool' wishes to distribute hashes around the net, then they need to do one of 2 things: 1) run proxies and thus they will control the distribution as required 2) use the API access to handle pool management Hacks to redirect to another pool on startup using a fake pool, or redirecting using the stratum network hack are just that: hacks. They need to develop their pool properly, not by quick hacks that require removing security fixes in cgminer. They replied a couple posts up stating that there's just one redirect. https://bitcointalk.org/index.php?topic=28402.msg6541935#msg6541935 |
|
|
|
|
What do you mean when you say, "supports all non-temporary currencies supported by CEX". I'm only seeing BTC and NMC in the settings currently.
|
|
|
|
You do realise that only the pool you are mining to can send a client.reconnect right? (unless it's a network hack that allows them to steal your hashes) So in the case of that 'service' they can only use reconnect once anyway. This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users. It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several. Let me rephrase that  What is sending several client.reconnects? You see, as I said above, it's not possible with stratum. Only the pool (or a network hack) can send a client.reconnect The cgminer change simply stops a hack intercept from redirecting mining away from the pool's domain - which will not affect any pool since no pool would want to send mining to a domain different to their own unless they had multiple domains, but they can resolve that by simply creating a DNS record with the same domain and use that in the client.reconnect request. Now the reason why I've posted again, is that this makes http://www.miningrigrentals.com/ VERY suspect in this recent issue. I'd actually suggest people to avoid them until someone clears up your statement with proof that they are NOT using a network hack to redirect your miner ... since: It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.
isn't normally possible with stratum. To quote their support team: Some of the newest miners have a "Do not allow reconnect" "fix." It's not really a fix it's just built without reconnect enabled. That will not work on our system since we have to send reconnect requests to get your rig to bounce to the chosen pool. How it works is that you set up a worker in their service. This worker redirects to up to 5 backup pools (for failover). The service then redirects your hashing to either those pools, or, if your miner is rented, to your renter (who also can have 5 pools specified). I've been testing them for a few weeks now with no issues. |
|
|
|
You do realise that only the pool you are mining to can send a client.reconnect right? (unless it's a network hack that allows them to steal your hashes) So in the case of that 'service' they can only use reconnect once anyway. This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users. It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several. |
|
|
|
Having the same issue with ghash.io, not sure about other pools. Antminer's interface is showing regular hashrate, but not the pool ((( The problem appeared recently -- week or so. Anyone having this sort of issue with other pools? Anyone encountered an odd issue where all units stop hashing after several days (this happened to me before but now it occurred after 6 days of nonstop hashing)? I use 3 pool with ghash.io as the primary and it seems like the units switch over to the secondary and tertiary backup but never go back to the primary. Even if there was a brief issue with the primary pool they should all eventually retry the primary.
This would not be such a big deal but what is happening is that after some time they units stop hashing even on the backup pools - ie I see no increased share count on any of the pools. The hashrate counter looks like it maintains the same average. It's as if it's hashing into thin air.
The fix is to reboot the units, then they go back to hashing as normal.
All my units are running the Dec 26 firmware except one which is running the Fed 04 one, but it is doing the same thing.
I think this is a firmware bug, but I just wanted to hear if anyone else out there is experiencing the same thing.
I'm running Feb 2014 Firmware with cgminer 4.2.2a on ghash.io. No issues. Might try updating your cgminer. |
|
|
|
I bought it on ebay,it lights up red, do I have to replace drivers with zadig cause I wasn't able to do that....
If you're using CGminer, yes. You don't have to in BFGminer. |
|
|
|
One of the recent batch (ordered at the first recent sales day) S1 works for 5 min, then disconnects, then in a few seconds beeps, then reconnects.
This cycle repeats all day long. What could be the cause?
i tried to reboot multiple times, switched off power supply, then back on-no cure. I have a feeling that I have a rare faulty unit. Thanks for any suggestion.
70% likely its your power supply. after 3min or so the antminer is at full speed and after a minute or two of this your PSU is finally overloaded and switches off. a lot of power supplies will attempt to restart themselves when this happens Interesting...I am running this S1 on corsair CX500M, not overclocked, so it should be able to handle it. A faulty power supply unit? I will swith powersupply and see what happens. Big thanks! Could also try powering only a single blade to check. |
|
|
|
It's certainly an inadequate power supply. Seen this issue a couple of times. New power supply time, make sure it can deliver the needed amperage too. Alternatively, if you've got them lying around, use one power supply for each blade as an interim measure.
Any certain choice for the power supply that will work 100% sure ? Any single-rail 600+ watt PSU that's 80 Plus certified should work for a single miner. I personally use the EVGA 1000W P2. If done right, this one can power 2-3. |
|
|
|
It's mostly working, but I keep getting errors like this: [Wed Apr 30 01:18:05 CDT 2014] Reinvestor: Order error: Error: Insufficient funds. Required amount:97963NMC, balance:97768NMC. Every 10 or so, it will get it right. Seems like there's just something slightly off about the calculations. |
|
|
|
Thanks! Seems to be working fine. |
|
|
|
Any alternatives would need to have a REST API (I don't see one for WhatMine offhand) and would preferably be free if it is going to replace the free option of CoinChoose. The API info just says, "coming soon", so we'll see, I guess. |
|
|
|
Sal,
I've been a longer time user of CoinChoose ... thank you for your work.
I believe some coin profitability is calculating incorrectly... I have been comparing between Coinwarz and looking at block chain explorers for the coins themselves.
For instance .. as we speak Coinchoose is reporting a Unobtanium to be 210% more profitable than mining BTC, while Coinwarz is reporting 46% ... this is a HUGE difference. I believe this is because Coinchoose has incorrect parameters for the current block reward. Coinchoose is saying the block rewards is 0.5 UNB , but on the block chain explorer miners are rewarded 0.125 UNB.
Is there anyway we could help you keep this parameters up to date. Are you reading the parameters for coin block chains?
This is exactly why I can't use CoinChoose any longer. They've gotten very inaccurate on reporting all of the coins recently. I actually did a test on Unobtanium last night and found it to be right on 40-50%. There isn't really any reason to ever use them now. |
|
|
|
Anyone know of a command line argument for setting miner difficulty?? Still kinda a newb when dealing with ASIC equipment but I would imagine there would be a simple argument to enter in the miner settings for SHA...
Thanks a bunch!
This is typically done by your pool - either automatically, or by setting a difficulty for the worker. |
|
|
|
|
It's probably already been posted before, but there's 600 pages, and I haven't been following this.
cudaminer-2013-12-18 is hands-down the fastest for me. With all of the later versions I only get about 100khash, but on this version I get 160+. I use an nVidia 650 TI.
|
|
|
|
what version of the program your using
I've tried 1.0, 1.0.2, 1.0.3, 1.0.4, and 1.0.5. None of them have worked for me. |
|
|
|
Just got a USB dualminer to play around with and I'm having some issues here. Firstly, there is no dualminer switch on the USB stick. I suspect I have an early revision. When I plug it in to the same computer running all of my U2s, most of them fall off on the driver list, and my USB hubs no longer have an indicator light on them. I got it to work on the same BFGminer that I'm running with MuM using: bfgminer -S dualminer:all --scrypt --set-device gridseed:clock=850 But I get this output:  I tried setting it to one com port or the other, but if I only set it to one (regardless which one), BFGminer doesn't detect the DMU, only the OCL. I'm assuming DMU is the SCRYPT and OCL is the SHA256. MultiMiner will not detect the dualminer, at all. I tried it on two computers using this config:  |
|
|
|
Hi, after CGMINER update LST data is correct in Miner status interface?
W_M
No, it's a known bug. Kano posted on this a few pages back. |
|
|
|
|
Show Posts
