Nope. Power supplies are rated on output. At best efficiency would be 90% at high end of the curve. So 900W/0.9 = 810W.
No the best efficiency is near the middle load. Get a bigger power supply than you need. It will save money on energy, run cooler and quieter, and probably last longer. Also if you can run on 240, that gives another few percent usually. |
|
|
|
|
I'm sticking with R13 for now and taking a shot with one unit of R15 (order 620). Hope this works out...
|
|
|
|
Is there an ETA for the Jupiters?
Thank you.
KNC says Mid Nov. To start Shipping Where are you in the queue? |
|
|
|
2. I have a preliminary report of R13. Unfortunately, due to broken boards from the R9-12 Bullet Run (sometimes you can't make an omelet without breaking eggs), we will not be able to get to full hashrate on R13 until about Thursday/Friday next week. The BA replacements for the broken boards are shipping Monday.
This is pretty unclear. Is there a reduced hash rate until Th/Fri or no hashing at all? |
|
|
|
Heh... what if the government is dumping unlimited amounts of funds to keep the bubble inflated... ?  There is no such thing as unlimited funds in a finite world. They just haven't reached the limit yet. |
|
|
|
|
In for 2 order 540. Open to go bigger on later rounds once I get some experience with the group.
|
|
|
|
In the coming months, anyone with 65nm BFL ASICs will start making less and less return for the same energy consumption, but avalons will hit that point first. Will be a similar case for anyone with the less efficient 28nm ASICs. KNC miners are pretty inefficient as far as 28nm process bitcoin ASICs are concerned, and they will be phased out long before BFL Monarch. This will give OGNasty more time to contemplate the 3rd / 4th generation bitcoin ASICs
Yup. Difficulty jumps are going to slow down because: 1) older ASICs are going to get shut down, 2) the transition to ASICs is largely over, 3) perpetual exponential growth is impossible, and 4) there is nothing "after ASICs," just better ASICs. From here on out it is going to be closer to Moore's Law, which is (very roughly) 100% per year not 100% per month. Most of the ROI calculators assume a fixed percentage difficulty growth per month. That's wrong. Keep an eye out because I think there are going to be some good deals on the secondary market when people do not understand this and are dumping their miners or their pre-orders. I'm very optimistic about the future of mining, but it is a competitive market where success comes from being smart about it, not getting ripped off, buying the right products and operating efficiently. |
|
|
|
|
Traded for nasty seats. Didn't really want to get out of mining altogether, just don't want the thing running next to my desk, so win-win for me.
Thanks for the offers. No longer available.
|
|
|
|
|
WTS 16 chip credits. Best offer.
|
|
|
|
|
I made the change myself as well and it is pretty (i.e. very) trivial.
While I agree it is a good idea, and I don't really see any harm in posting it, I also kind of think that given the target audience being one where people are reading and understanding the code it shouldn't be necessary to post this.
There are a lot of ways to blow up your money with any trading bot if you don't really understand how it works. Don't do that.
Hint: add the offline amounts to fiat_have and btc_have
|
|
|
|
Fantastic work prof7bit.
It runs OK on a raspberry pi raspbian / wheezy (wanted an always-on low power bot server) at a load average of ~0.99 and most of the memory. Hopefully there is no memory leak.
I'm not running X and in the console the xterm title (price/bid/ask) seems to cause some trouble appearing at wherever the cursor was last.
With screen over ssh in an xterm it looks fine though.
I'm very surprised by a load of ~1 for this on a rpi. A (possible) memory leak surprises me less. I'll test this myself soon, but I think something is likely going wrong in your configuration. |
|
|
|
It looks to me like the bot doesn't consider the trading fee when calculating the new two distance orders points and the two new order volumes.
This is true. The fees are low enough to be not significant for the calculation of the new acount balance, so I just ignore them and if you choose the distance >> 1.2% there is also enough room for profit for every consecutive buy-sell-sequence. I think it does adjust to your current balances, so the effect of fees (as well as any slippage due to lag, downtime, etc.) will be factored into a future trade. Regarding the issue of trends (some other posts on the thread), if you expect a sufficiently strong uptrend, the better strategy is to go long. Likewise if you expect a strong downtrend, you should just go long USD (hold 0 BTC). Both of these are ignoring the possibility of shorting or leverage. There is a narrow range of expectations where balancing is the best approach. |
|
|
|
I guess my worrie is in spikey fast tradeing with bad conections sometimes computer programs behace in unexpected manners.
There are definitely issues with lag, dropped gox connections, etc. Some of those are discussed on the main thread, as they aren't really specific to this strategy. Another rebalancing strategy discussed on the same wiki page might also be interesting to play with: http://en.wikipedia.org/wiki/Constant_proportion_portfolio_insurance |
|
|
|
I run it just like this. ./goxtool.py --protocol=socketio --use-http Thanks, that does seem to work a lot better. |
|
|
|
Been running it for a week, it is surprisingly robust considering the problems with mtgox, and me suspending my laptop a couple of times per day.
What API configuration are you using? Do you trade or just use it to watch the market? |
|
|
|
|
Is this actually usable? socketio seems to drop constantly and lag horribly, especially on orders. websocket just sits there and doesn't update.
|
|
|
|
|
rsJgf2vcDg3K9LXmrBCewbWaYQCrsgvKb4
|
|
|
|
I just thought: because you wrote about this flaw, you could also suggest how to correct it.
You know, I did suggest the stackexchange post, which has what I think is the correct algorithm. I have implemented new random algorithm that solves bias flaw. Please ensure that it is correct.
With the caveat that I'm not a PHP programmer at all, it looks right to me. |
|
|
|
|
Show Posts
