Yep, your PSU documentation will tell you exactly how much juice you can take off each line. Some PSUs have multiple rails, some are single rails... it'll all be stated in the doc. Just don't overload individual wires. This is a fantastic resource for PC power connectors and their rating: http://www.playtool.com/pages/psuconnectors/connectors.html |
|
|
|
Fotos:
. . .
Second fan removed to show the third fan and VRM heatsinks
. . .
So they (BFL) put on that copper HS&F and extra heatsinks? |
|
|
|
|
Restarted bitcoin-qt 0.6.0-rc1, still stuck on 170059.
Gonna re-install 0.5.2.
|
|
|
|
So, every single one of my rc1 nodes is stuck on block 170,059 and refuse to move forward. While I'm compiling rc2, does anyone know if this is a known problem?
Ditto. Just shut it down, and restarting it. |
|
|
|
oops!  |
|
|
|
|
It's what I'm about to do (when the cables arrive). It's as straight forward as you may think.
1. Buy a load of connectors.
2. Wire them to the PSU.
More details:
The yellow wires on the PSU are 12V. Black is ground. Anywhere you see these wires, is anywhere you can attach your connectors.
To save cutting the wires on the PSU itself, I bought an 8-pin supplemental CPU power extender, and I'll be cutting that up and soldering the connectors to it. The 8-pin CPU power connector as 4 12V lines which can supply 8A each, which is nice and meaty for my purposes. You can also get the standard 4-pin molex peripheral connector too and use that, or use the PCI-E connector... all have the yellow 12V wires.
Only thing you need do after that, is short the green wire on the 20/24-pin Motherboard connector to any black one to turn the PSU on.
|
|
|
|
|
I think it should work with all of 5, and probably 4.
Probably some configuration issue fixed with the re-install.
|
|
|
|
|
Are sockets enabled in PHP?
|
|
|
|
|
Somebody's making pretty patterns on the exchange.
512, 512, 512, 256, 512, 512, 256, 256...
|
|
|
|
Holy crap! $17 for a connector with a whole 2 pins connected? People pay for that!? Yeah, think I'll make do with a paperclip and some electrical tape. Sheesh. |
|
|
|
need to enable the 'write' privileges to the webhost. See the cgminer documentation. --api-allow Allow API access (if enabled) only to the given list of [W:]IP[/Prefix] address[/subnets]
This overrides --api-network and you must specify 127.0.0.1 if it is required
W: in front of the IP address gives that address privileged access to all api commands
--api-description Description placed in the API status header (default: cgminer version)
--api-listen Listen for API requests (default: disabled)
By default any command that does not just display data returns access denied
See --api-allow to overcome this
--api-network Allow API (if enabled) to listen on/for any address (default: only 127.0.0.1)
--api-port Port number of miner API (default: 4028)
|
|
|
|
Yeah, this is more like a burglar getting the master keys to a mall (Linode) and making off with the money in all the stores... and one of those stores just happened to be a bank.
Wasn't just one, dude. |
|
|
|
|
Further thinking:
The system would operate asynchronously. Each device works independently, requesting work from, and submitting work to, the host. I don't think there'd be any advantage the host doing the polling, or using any kind of token scheme. This may lead to delays between polls where the device is not working. Not long delays, but delays nonetheless. An asynchronous system would cause collisions to occur (and more often with more devices on the line) but with proper delay times this could be minimised.
When requesting/sending work, a device would:
1. Listen for activity
2. If clear, send.
3. If not clear, wait a random time from 10-100ms, go to 1.
When responding to a message, all devices would respond immediately. The min 10ms delay above would prevent collisions on response messages. No delay would mean they would be the most likely hit.
Devices could be hot-plugable too. Every few seconds the host could broadcast the hello message. Already initialised devices wouldn't respond (since they were given the 'shut up' command), the new device(s) would send their hellos.
|
|
|
|
Tell you what, when my BFL's arrive I'll throw something your way. With my current 0.1 BTC/day, I'll take whatever I can get  (What with the extension not being too useful until they DO arrive!)  |
|
|
|
No need to reinvent the wheel serial (RS-232) already has hardware collision detection and RTS/CTS handshake implemented.
Requires extra lines. RS485 is just two lines. And I'm fairly sure RTS/CTS only works on point-to-point systems, not mutli-drop. |
|
|
|
|
Show Posts
