I assume you could use these cable mods to run your PCI'e cards from a different PSU to your system PSU?
If you're using a PSU not grounded to the motherboard, do not utilize a cable with modification. Make sure any secondary PSU to be used would be grounded through the motherboard. How would you go about grounding the PSU to the motherboard? Is is enough to mount them in the same (conductive) case? |
|
|
|
Thanks for the link, I ordered 3 right away :-) Still the ground differential bothers me quite a lot. Anyone ever tested this? Or how are 3-4x 5970 Rigs possible? |
|
|
|
I'm not much of a hardware guy, so there are quite a few things I don't get about this setup. I ordered a few new Cards and I think they will put me over the limit of my PSU (Corsair 650W) so I think I'll buy another PSU and attempt a dual PSU setup (shown here http://www.burningissues.net/how_to/power/psu.htm). So here are my questions: - Is there an online shop where I can buy prebuild splitters like that? I remember I once saw one on eBay
- There were a few people bringing up the problem of a power/ground differential should a card be powered from two PSUs. So am I on the safe side if I use modified PCIe risers with Molex and consistently power each Card from one PSU?
- Is there anything else to consider?
|
|
|
|
|
Rehashing would be one option to solve the sha-1 vs sha-256 mismatch. Or we could just keep the last 160 bits of the sha-256 hash trunkating the first 0s so the hash would still be recognizable :-)
Should I try and create a separate thread to this?
|
|
|
|
|
I'm sure I mentioned it elsewhere already but how about just choosing a random hash (genesis block for example) and then using that hash to find peers from a BitTorrent tracker.
I'm sure the tracker won't mind, and exchanging IPs is their main business :-)
|
|
|
|
1 percent cpu? what miner are you using? im using phoenix with two 6990s @ agression 10 and i get 100 percent
With dual video cards, you'll have at least one core of your processor maxed out. With single cards, you'll get 1-2% usage. That's probably because you didn't turn off crossfire :-) The CPU is only used to queue new work to the GPUs (not much of work) and check found difficulty 1 blocks (even less). Just make sure you disable crossfire on all cards and you should be fine :-) And yes: I use phoenix for the 5970 and DiabloMiner for the 5850 (because it tends to lock up when running with phoenix, and I prefer stable runtime over high but unstable hashrate). |
|
|
|
The PSU is ok, you can never have enough power there  I would consider a dual PSU setup maybe to get the price down. The RAM and CPU are completely out of range, you don't need that much, go with the cheapest thing you can find. My Rig with a 5970 and a 5850 uses 1% CPU and 100MB RAM... Also the HD can be replaced by a memory stick if you're trained with Linux ^^ |
|
|
|
You must be new here. Theymos tells how surprised he was that he was able to sell bitcoins that he generated on his computer for $0.003 (three tenths of a cent) each (in quantities of 10,000).
Ah, the good old days  I remember when I first sold my first 100 BTC, for a total of 0.61 |
|
|
|
|
Since I often buy cards from eBay and am tempted to buy one of those "defective" cards, is there a possibility of creating a small utility that stress tests the OpenCL capabilities of a card so that I can send it to the seller and let him check if the card is working before buying?
|
|
|
|
|
I'd be interested in the modified risers. I'm assuming those are the ones with the power lines connected to a molex adapter, right?
|
|
|
|
Being a stats junky I'm working on a simple page that dumps the data in the dashboard to JSON so that I can then write a munin plugin to monitor the status of my miners, I guess we could use that one with a cronjob to kick off custom scripts. It would make it much easier and more flexible since the web server user is usually quite constrained in what he can do ^^
There is support in the MVC framework for JSON output. The dashboard view page already implements IJsonView so try visiting /admin/?format=json. This works for me. Great, it works for me too, just had to change the URL in my scripts. I think using such an API to run cronjobs against is more useful than having it crammed into the web interface. BTW: htdocs/index.php@71 is throwing a lot of errors since in getwork requests the lpurl parameter is not set, and since we already check 2 lines below and then set $lpurl again it is redundant and should be removed ^^
You're right, I'm not sure why that's there. That being said, PHP is a whiny little bitch and it likes to complain about things that aren't problems.  Agreed I haven't looked at it in-depth yet. Let me know when you are done with it and have tested it and I'll review the pull request. I guess I can drop the stats branch then, since it already works out of the box from your dashboard. On the worker-hashing branch I made the average interval configurable because it strongly depends on the hashing speed (high hashing speeds can get a more accurate reading with shorter intervals, while slow miners will have the average jump wildly around for small values). I think it is ready to be pulled. Once again sorry for all the noise I created in here ^^ |
|
|
|
cdhowie started implementing a nice proxy that would switch pools should it become unreachable: http://bitcointalk.org/index.php?topic=5506.0;allWe are also working on exponential backoff, so that the pools wouldn't get hammered all the time, until miners start implementing these features themselves this might be an option for serious miners |
|
|
|
Just wanted to update this to let you know that Phoenix 1.2 (version I've run for the last couple weeks) seemed to exhibit the problem, while version 1.45 has not yet exhibited the problem during several hours of testing. I'm going to let this thing run for several more hours, then switch over a few more miners to the proxy and see how it goes.
Cool, keep me posted on that. 1) Can you add in code (maybe configured by config.inc.php) to adjust the timestamp according to a user-defined timezone? I've become accustomed to looking at UTC and knowing the offset, but still would be a nice thing to have.
Sure! I planned to do this at one point but forgot about it later. Thanks for reminding me. 2) The purpose of my push for your software, and what makes it valuable to me, is being able to know if a miner stops pulling and submitting shares (in addition to all of the wonderful features you've coded in so far). Is this a feature you plan to add in the future, i.e. with simply listing all of the miners in red/green status like deepbit does, and having the option to act on it somehow, like with a shell script?
Yeah, this is probably something that could be done. The red display is pretty easy to do; the shell script will require DB schema changes and a bit more work, but will still be possible. I assume this would be used to, for example, email you if one of the miners stops requesting work? I could define three new configuration options: one for the amount of time a miner must have not requested work for it to display differently, one for the amount of time a miner must have not requested work for the script to be run, and one for the script to run. Being a stats junky I'm working on a simple page that dumps the data in the dashboard to JSON so that I can then write a munin plugin to monitor the status of my miners, I guess we could use that one with a cronjob to kick off custom scripts. It would make it much easier and more flexible since the web server user is usually quite constrained in what he can do ^^ BTW: htdocs/index.php@71 is throwing a lot of errors since in getwork requests the lpurl parameter is not set, and since we already check 2 lines below and then set $lpurl again it is redundant and should be removed ^^ Edit: My first attempt on a JSON stats dump is here: https://github.com/cdecker/Bitcoin-mining-proxy/commit/82f8ad9e352352cdbe81d84a8939b817204cb59dEdit2: hope you didn't yet look at the stats and the worker-hashing branch because I was missing two GROUP BYs in the shares subquery which resulted in the hashing rate of all miners to be reported on a single miner instead of distinguishing. I fixed it in the branches ^^ |
|
|
|
Small problem. AFIACT re: HTTP RFC, you cannot send a message body with a GET, only with a POST. So, uh, why wouldn't I be using POST?
That's why we fixed it on our side. Just wanted to let you know... |
|
|
|
|
Guess what, it's my fault. The pool I was using was returning immediately if a long poll came with POST, instead of GET. Diablo was the only miner triggering this problem so far. We fixed it on the other side ^^
|
|
|
|
|
Works like a charm, and it fixed my 100% problem with Diablo too ^^
|
|
|
|
|
Just issued a pull request for the hashing speed and shares in the last hour on the dashboard for each worker. Hope you like it ^^
|
|
|
|
|
I'm not really familiar with the framework you're using, so I started by implementing the hash speed for the workers. As for the routing of the post request, I guess you'd be faster than me :-)
|
|
|
|
Will do ^^
I should have seen it immediately: Diablo uses POST request while well behaving clients (phoenix, poclbm, ...) use GET requests. Should be a simple matter of routing POST to the same handler In the meantime I'm working on a hashrate estimate for the workers, which I'd find quite usefull. Do you accept patches/pull requests? |
|
|
|
|
Show Posts
