 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
|
Wow is it just me or does this long dry spell of not solving a block seems damn long. This wait has caused my bounty to almost clear out.
|
|
|
|
I am running 2 x 6990 with the Haf x. I noticed that the lower gpu has way higher temperature compared to the top card. This is due to the hdd bays restricting the hot air venting into the case. We know that the design of 6990 pushes hot air out through both ends of the card, so all I can say is that 1 core of both your 2nd and 3rd card will experience high temperature. I would suggest removing the hdd cage to allow more room for the hot air to circulate but it requires drilling through the reverts holding the hdd drive bay. Anyway as a gauge the hottest core in my system is about 10 degrees hotter than the coolest core. In this case the core nearest to the hdd case vs the core nearest to the 5.25 inch drive bays. Overall Haf x is sufficient but I would suggest looking at Aerocool case http://www.aerocool.com.tw/index.php/products/chassis/28-pgsb/111-xpredator-black- if your budget permits and location sells them. The 4 x 120 mm fans on the side panel allows you to change fans depending on ur preference instead of the low rpm 200mm sidepanel fan of the Haf x. |
|
|
|
|
Yeah its down cuz I think it takes some time for the server to compute the hash rates after the bitcoind went down. As seen in the miner top page.
|
|
|
|
I hope not  Long disconnection - it's bitcoin daemon crash. Now all restored an work as usual. SSL added, and users may use it for login/profile pages. Internal site urls/redirects do not use https at the moment, I will fix this soon. SSL is great when login to the website from work =) Anyway I also noticed that when the bitcoind went down the email notification wasn't sent till some time later. Only after the bitcoind started and I already redirected my clients to solo. Would it be possible to add a notification via email when the bitcoind goes down? Thanks I am loving the email notifications currently being offered, it comes in handy. |
|
|
|
|
Hi dbitcoin,
I noticed a sudden and temporal disconnection of the server and when its back up now runs on https!! Great Job!
Anyway will there be another disruption of service soon?
Cheers!
|
|
|
|
|
Seems like its working when solo mining, however I am not to sure what extent it is working well with the new 0.3.21 version of the bitcoin client. I haven't been successful in solving a block yet. Has any one solo mined and solve using this yet?
|
|
|
|
BTW, if you go to your account and hit the advanced settings button, down under the BBCode textbox is a line that says how many blocks you have found historically. Just a little tip.
Hey thanks for the tip! I dint notice that! |
|
|
|
UPDATE:- Pool interface is partially translated to russian language, you can enable this option in your advanced settings.
Hi Tycho just to check does a total shares (bold) under statistics mean anything? Yes, it's block found by you it means you have found a block! well done Thanks for help Wow thanks. I was having super bad luck for a week + on my solo mine and I just started full mining on the pool and I strike a block. Thanks! Though I am feeling abit =~ |
|
|
|
|
Hi Tycho just to check does a total shares (bold) under statistics mean anything?
|
|
|
|
No, that's not correct. The work you receive is always unique.
You can mine directly against bitcoind, or put a proxy in front of bitcoind (pool server) for better stats and management.
Hi does the proxy in this case a pool mining server provide better allocation of work to the gpus compared to bitcoind interms of probability of solving a block. For an example, the work is divided into shares before sending to the GPU miners to hash, rather than the distributing the same entire workload to the number of GPUs available thereby creating a redundancy? (correct me if I am wrong as that is the perception I have now) |
|
|
|
|
Hi I am curious, does running a local pool server distributing out 'shares' more efficient compared to using the standard bitcoind? I noticed the increase shares generation per gpu worker in a mining pool compared to solo mining using bitcoind. I was wondering if this idea of breaking the work into smaller shares like what mining pools are doing could be applied to solo mining if let say I have 6 gpu and more running. Would using normal bitcoind in solo mining cause the same work to be processed redundantly? For example, I recalled slush mentioned the need to register each gpu into individual workers on the website.
Could using remote mining server tool like that developed by puddinpop be the way to go?
|
|
|
|
It's also considerably more efficient than JSON-RPC: Requesting more work from the server requires 6 bytes from the client and 170 from the server. (Compare this with 47/605 for JSON-RPC... and that's not counting HTTP headers)
Hi im curious as to how this is compared to pool mining. After using pool mining for awhile, I was thinking of using the same approach (smaller work difficulty to individual miners) for the local mining rigs set up. So far using bitcoind and mmp it seems like it is not the same compared to pool mining approach. As the more gpu is added to my local network, I guess running it like a mini pool would be more efficient compared to all connected using the normal method? Btw running the multiminer, the cmd does not reflect anything after I keyed the command strings in. Is that normal ? |
|
|
|
|
Oh solved it...I think the teamviewer is using port 80. Btw thanks for your help. Is mmp more efficient compared to the usual rpc?
|
|
|
|
|
Traceback (most recent call last):
File "multiminer.py", line 114, in <module>
File "multiminer.py", line 109, in main
File "ClusterServer.pyc", line 102, in start
File "WebServer.pyc", line 39, in start
File "twisted\internet\posixbase.pyc", line 419, in listenTCP
File "twisted\internet\tcp.pyc", line 857, in startListening
twisted.internet.error.CannotListenError: Couldn't listen on any:80: [Errno 1004
8] Only one usage of each socket address (protocol/network address/port) is norm
ally permitted.
Hi this is what I got from the error message after editting the script to the one you mentioned
|
|
|
|
Glad to hear you're interested!
The --url argument works exactly the same way as -u in Phoenix. In fact, it uses the exact same code, so anything usable with Phoenix works with that.
The admin-user and admin-pass arguments specify the administrator account on Multiminer, which can be used to log workers into the server and, since it is an administrator, hit Multiminer with JSON-RPC queries.
In short, you would use something like this:
multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://BitcoinUsername:BitcionPassword@localhost:8332/
EDIT: You can also specify a parameter like -b 30 and it will send 1/4 the work to each miner, which is a bit more efficient. You'd have to play with it a little though.
EDIT: As with Phoenix 1.4, the default askrate is 10, but you can change it with ;askrate=X, as in Phoenix.
And then you would connect Phoenix to Multiminer via MMP, with this URL: mmp://admin:admin101@localhost?name=SomeName
Of course, you are free to change the username and password for the admin account.
It's also worth noting that Multiminer is a complete webserver (the web-port=80 makes it run on the default HTTP port) that serves pages from the "www" directory, which means you can put a stats page in there to quickly see how your miners are doing, which is what jedi95 and I did.
You can also hit it with JSON-RPC requests. It's compatible with RPC miners (although it doesn't offer long-polling yet)
Hi thanks for the prompt and comprehensive guide. Please advice on my current bat file, I have the client reporting that failed to connect retrying. Server start /DD:\multiminer-1.4 multiminer.exe --admin-user=btc --admin-pass=asdqwe --web-port=80 -b 30 --url=btc:asdqwe:8332/ Client start /DZ:\Dropbox\BTC\phoenix phoenix.exe -u mmp://btc:asdqwe@192.168.1.8?5850/ DEVICE=0 VECTORS AGGRESSION=7 FASTLOOP -v BFI_INT -k poclbm Also with regards to webserver, is it the ip address of the bitcoind server? Meaning if its 192.168.1.8 its just 192.168.1.8/8883 when entering into the web browser? Also After executing the multiminer does it show a cmd window ? Cuz when i did run it closes immediately. |
|
|
|
You might be interested in my other project, Multiminer, which we use for our (jedi95 and I) cluster's status page. I have a Windows download here (or you can get the source off GitHub) and it's pretty easy to run: multiminer --admin-user=admin --admin-pass=admin101 --web-port=80 --url=http://PoolUsername:PoolPassword@PoolHost:8332/Then change your Phoenix URLs to mmp://admin:admin101@localhost?name=NameForThisWorker (Phoenix already supports the protocol) And finally you can throw JSON-RPC requests at http://admin:admin101@localhost - try listconnections() to see your worker status. You can also put an index.html in "www" and have it do some JQuery magic to view your workers. The only drawback is Multiminer doesn't have its own logs (yet), but you will know it's working when your miners pick up work and start mining through it. Hi CFSworks, I am intrigue by how to get this to run locally on my bitcoind server. I was testing out with different askrates and found this post which seems like a efficient way to distribute work to the miners. My question is if I have a pc running bitcoind server, should I run the multiminer on that server? Also what are the --admin-user and --admin-pass indicating? Are they the bitcoin.config file password? Also I dont plan to display this information on a webpage as I do not have a webserver running, so does that mean that I dont have to run web port 80? Thanks! |
|
|
|
|
Hi m0mchil thanks for keeping your miner up to speed with the bit_int support. Out of curiosity does your latest version activate the bit_int support automatically? Is there a flag I have to add to activate it.
Also I noticed similar performance to that of phoenix. I guess essentially both miners are the same as it is running the same kernel, however is the hash checking the same for both?
|
|
|
|
|
So taken together can it be summarize that askrate=10 is sufficient and the same as askrate=5?
|
|
|
|
|
Hi I have a question, you mentioned that it is good to set an askrate=10 when mining solo due to the possible change in block. I recalled that the default for poclbm or diablo was 5. Does the askrate for phoenix use the same scale system as the other 2? Additionally, does the askrate=5 potentially cause the miner to work incompletely. For example, if the miner has not completely hash the current work and the new work arrives dumping the current work mid way, and this cycle continues. Would it affect the probability of finding a solution?
|
|
|
|
I like the idea; how about if we added an option to log to a file directly from Phoenix? (And logging to - disables console output and logs directly to stdout instead.)
Something like: phoenix.py -l mining.log
Not sure what the best way to specify the rate is, though.
Hi I think logging to file is a great Idea. Monitoring it from the web would be a breeze!! |
|
|
|
|
