Show Posts
|
Pages: [1] 2 »
|
This merged mining daemon looks very interesting. Are there any tutorials out there on how to get started? Would it be enough to simply compile the source from: https://github.com/vinced/namecoin/tree/namecoind-mergedmine and run that as the namecoin client, run an up to date bitcoin client and point my miners at the merged miner proxy (which in turn would point to the locally running namecoind and bitcoind)? Wouldn't it be possible to use to parent chain interface to a mining pool such as deepbit or btcguild? I'm looking forward in seeing how this evolves... Cheers:)
|
|
|
After the latest updates things have been looking great for me (with perhaps only recent high level or stales, but that most probably is Phoenix r112's fault). Anyways I was wondering when will you be implementing multi-machine support. I plan on deploying a couple new rigs in the near future and would ABSOLUTELY LOVE to be able to monitor and control everything from one place
|
|
|
I started using smartcoin (r451 ex) recently and ran into an interesting bug: instead of failing over to a backup profile, smartcoin terminates with the following message: 07/18/11 14:05:06 ERROR: It appears that one or more of your devices have locked up. This is most likely the result of extreme overclocking! 07/18/11 14:05:06 It is recommended that you reduce your overclocking until you regain stability of the system 07/18/11 14:05:06 Killing Miners.... The thing is that it app fails at the very beginning when trying to connect to BTCguild using phoenix r111 while BTCguild is unaccessible. Perhaps this is because the meter doesn't show up until a connection is established? I'm running r451 experimental. Overclocking is not an issue here as everything is pretty much stock, with just my fans cranked up to keep everything as cool as possible. Love your the work!
|
|
|
Sounds great, when will it be released?
|
|
|
I would absolutely love to test this
|
|
|
Any news regarding API worker hashrate figures for the EU server? I'm reading 0 for all my workers in the API, however I see the stats on the website itself...
|
|
|
One thing I've seen is LOTS of stales. When I used the latest hashkill with deepbit, I noticed I had 7% stales, that's plain crazy. I've tried tinkering with clock speeds, cooling other pools, nothing really helps to resolve this.
Hmpf, that should have been resolved already. You are sure you ran install.sh with root privs? * config file
That would be nice...but what exactly are we going to configure that is hard to configure via command-line? * some type of RPC (JSON-RPC anyone) interface for managing operation and querying status of miners (hash speed, temp, pause resume queue, etc)
Right now there is such mechanism, but it's like read-only...you can have a look at the ~/.hashkill/bitcoin.json. It exports hash speed and etc stuff in json format. It sucks though and definitely it would be good to control it remotely. * ability to adjust fan speeds automatically and provide ability to set min and max speeds per card
This is a very bad idea. Tried doing that in the past. The end result being something that works good on one system and goes crazy on another (well I guess that's what the whole GPU programming is about anyway). Overall I am not inclined * either prioritize workloads per GPU or per GPU temperature... it would be good for long term operations to have all the GPUs working at the same temperature
This is an interesting idea that never occured to me before. Worth trying. * an aggressiveness setting
I guess -D and -G work that way. -D -G4 is rather aggressive while just -G1 is the most responsive. I used sudo ./install.sh so there were no permissions problems. Quick note, when you release an updated version of hashkill, please change the filename with every revision, I'm sure it will help with ambiguity and the bloody web proxies I deal with. Config files keep things easy to manage when more and more features come into play. At present I have 2x6990s running, and due to current cooling constraints, the 6990 that is running up top (gpu0 & gpu1) is running 15% hotter than the bottom card. Due to this, I am using phoenix and set the aggressiveness to 5 on GPU0, 7 on GPU1 and 12 on GPU2 and 3. I tried playing around with D and G, however I wasn't able to keep the card from overheating. With regards to the temperature threshold in the current implementation, do you poll the SDK until the temperature drops 10C below threshold and begin processing, or do you have a predetermined time based time out. With regards to prioritizing workloads to keep constant temperatures on the GPUs, it would help to prolong reduce wear from the cards heating up and cooling down. BTW, have you tested hashkill with btcguild?
|
|
|
So I might as well give up? Because I'm not buying a new card for this.
Yes. Point. Invest or leave it. I just puchased 9 x 6990 for 3 mining servers. Decent investment. More to come. Damn, and I felt good about my 4 x 6990s. How will you be powering the 6990s? I had a Thermaltake 1500W and it wasn't enough for 3 x 6990s in one case.
|
|
|
how can one run hashkill without being logged on the desktop?
I want to move the system somewhere without a monitor attached, and I can't start hashkill in the ssh session when I'm not also logged in on the console...
You need to have X Windows started, and be logged in (in the case of say GDM). Then you can export your DISPLAY settings and start the app as that user. Hope that helps.
|
|
|
I tried the latest build of hashkill on my dual 6990 setup and I'm blown away with the performance. I think it's a great tool and look forward to see where things will be headed. I have been having trouble with connectivity to btcguild.com Phoenix 1.48 has been running rock stable (although with 10% lower speeds), so I think there must be some LP issues there. One thing I've seen is LOTS of stales. When I used the latest hashkill with deepbit, I noticed I had 7% stales, that's plain crazy. I've tried tinkering with clock speeds, cooling other pools, nothing really helps to resolve this. If that would be resolved the following would make hashkill slaughter the competition: - config file
- some type of RPC (JSON-RPC anyone) interface for managing operation and querying status of miners (hash speed, temp, pause resume queue, etc)
- ability to adjust fan speeds automatically and provide ability to set min and max speeds per card
- either prioritize workloads per GPU or per GPU temperature... it would be good for long term operations to have all the GPUs working at the same temperature
- an aggressiveness setting
If a solid RPC based management interface would be implemented with queue/workload management than I would be willing to put in some time to write the tedious interface bits in python
|
|
|
Better get a TJ11. The TJ07 has lots of heat problems, plus you won't be able to put in the 4th card without a dremel. I will use water cooling, so it's a non-issue, right now I underclocked the cards to keep them cool.
|
|
|
may I ask what kind of case u use ?
Silverstone TJ07.
|
|
|
With regards to total power there is no problem. Where I see a possible problem is in the overloading of the individual rails from the PSUs. Since I can only use 1 PSU's ATX rail to power the motherboard, I am only working with 20A from the ATX connector and possibly 20A from the CPU connector.
The 6990 uses 75W (from MB) + 2x 150W (8 pin PCI-E) while operating at 830MHz for a single card (375W total). My question is if the card is overclocked and uses more power, will the power usage grow proportionally from each source, or will the PCI-E connectors compensate the difference required, leaving the MB slot draw at 75W.
Thoughts?
|
|
|
While sometimes it is more economical to have multiple rigs running (for power and cooling reasons), I am limited by the number of systems I can operate in the house. Having said that I would like to know if there is any way to power 4 unlocked (880MHz or OC 900Mhz) 6990s out of two Thermaltake 1200W PSUs (model number W0133RU). I have a case which supports dual PSUs (TJ07), and the ATX adapter cable which turns on the second PSU when I switch on the power.
Here is the problem. While 2400W combined "should" be enough for practically anything, I would like to know if I would be overloading the 12v ATX rail (4 GPUs + Phenom II X6 1090T/890 chipset. There is no way to "glue" the power of two ATX rails. I know that the CPU rail is there to help out, but I don't know if it will be enough.
I will invest in external watercooling to keep things running smoothly, so heat will not be an issue, and the cooling won't burden the PSUs.
Any thoughts?
|
|
|
not as much as the portable A/C
|
|
|
Check the fuse box, it might be labeled there. While you're at it, you could check the amperage of the fuse on your circuit, so you know if you're pushing it or not. And get your own power meter ( http://www.amazon.com/P3-International-P4400-Electricity-Monitor/dp/B00009MDBU). All the kids in school will think you're cool if you have one. Not the mentioning the girls. You'll be chasing them away like flies. If you want to impress your dad, ask dad to whip out the home wiring diagram. If he asks why, tell him you want to fight communism.
|
|
|
What was the limiting factor for me was cooling. With a big external fan blowing on the cards (2x6990), I was able to do 905 MHz and 625MHz underclocked memory (using MSI Afterburner, couldn't get it down unfortunately to ~300MHz), and it was running somewhat stable.
On my other box (TJ07 case with 2x 6990s running 11.04) I had to drop my clock speeds to 830MHz with 294MHz underclocked ram due to case cooling issues. I'm looking at consolidating all my 6990s in one box and using some proper water cooling to keep things running cool. At that point 925+ should be easily attainable.
The thing is you don't want the card's temperature nannies to kick in. If they do, you suffer a bigger performance hit than running at a lower speed. I think it's safe to run the cores up to 96C.
|
|
|
Either keep mom's vacuum cleaner off your circuit and you should be good.
|
|
|
Make sure that the munin plugins gpu_* (/etc/munin/plugin-conf.d/munin-node) are run as the user logged into X. That should help
|
|
|
|