Over 21,000 bets already today. Everything seems to be flowing fine now except for about 600 unknowns which I am working on clearing up now. They should be gone in the next 4 hours or so.
Would be useful to have some sort of "average bet delay in seconds" near the top of the main page... |
|
|
|
|
bets ground to a halt again.. right around 10-11am EST...
|
|
|
|
Sorry, that was a database change I made. I make it use transactions in a more conservative way which ended up being a good bit slower so it was having trouble keeping up with people's bets. It should be much better now. I really need to track some metrics of bet to result time so that this sort of issue is more obvious to us.
Yes. Please. |
|
|
|
|
Slow doesn't begin to describe it. I've seen bets today sit (6) hours before returning......
Perhaps someone wasn't ready for this kind of popularity?
|
|
|
|
Well, unless you're trying to pull off a double-spend...
Or you're trying to merge/mix/'clean' coins... |
|
|
|
Our fee policy is published (you didn't read it), we are trying to protect the blockchain from flooding (and optimizing our blocks).
Did read it, but I'll include it here for those who didn't. Deepbit's transaction fee policy
(This is not related to the pool's payments to our users)
We think that free transactions are very important for the Bitcoin system so we are including as much free transactions as possible into our blocks, possibly more than anyone else. But sometimes a fee may be useful, so here is our fee policy:
A transaction is considered to be 'free' if the offered fee is less than 0.01 BTC. Free transactions are only accepted if they are less than 2000 bytes in size and have no more than 5 outputs. Outputs less than 0.01 BTC are not allowed in free transactions. The minimum fee for non-free transaction is 0.01 BTC for each started 1000 bytes.
As I read that policy, anything less than 0.01BTC transaction fee (200x greater than what the bitcoin client considers the minimum) is considered "free" (unless it's payments to your users) falling into a bin of indeterminate behavior on Deepbit's part. Today you process a percentage of "free", choosing to not process some percentage of "free". You're correct. That's your right. It's your hardware, it's your bandwidth, it's your money spend to offer the pool as a service to your users. I'm just saying, given the current distribution of transaction fees, this choice is causing some transactions to take a lot longer than others, because somewhere between 30%-40% of the networks hashing rate (depending on the day) may choose not to process your transaction, because it doesn't pay them well enough. Not saying evil, just saying.. It is what it is. And people should be aware |
|
|
|
Thanks, Graet. Comments posted.
(Nothing really wrong happened, BTW)
That depends on your perspective I guess. The largest pool is choosing to not process transactions that don't meet their required minimum fee included with each transaction, thereby creating an artificial transaction backlog for the entire network. |
|
|
|
I've found that even with the recommended fee of 0.0005 BTC for a transaction with few inputs, Deepbit still doesn't accept the transaction (I have to wait for other blocks.) If I do a fee of like 0.005 then it accepts it.
.....SatoshiDice generates a large # of tx and most (all?) have a tx fee so the % of free tx may have declined significantly....
Together, if true, this may be the problem we're presently seeing. If SatoshiDice is generating scores of 0.0005 tx fee transactions (or less/free), and Deepbit isn't accepting anything below 0.005 (10 times higher) then we have a problem. |
|
|
|
Why? 95%+ of tx include no fee. Not that I doubt you, but can you cite a source / graph / stats? |
|
|
|
It does seem odd, as far as the network is presently behind, (3,111 unconfirmed transactions at the time of this message, 2322 low priority) that a block goes through with little to no transactions in it. http://bitcoincharts.com/bitcoin/txlist/ |
|
|
|
 {edit: updated to include next block} |
|
|
|
Odd error, not sure what to make of it. Fedora14 box, mixed 5830/5850/6950. Aside from being about 200mhz slow vs cgminer, I'm seeing this: [794.88 Mhash/s] [4 Accepted] [0 Rejected] [RPC (+LP)]Traceback (most recent call last):
File "./phoenix.py", line 6, in <module>
main()
File "/RAM/phoenix2/phoenix2/__init__.py", line 53, in main
reactor.run()
File "/usr/lib/python2.7/site-packages/twisted/internet/base.py", line 1165, in run
self.mainLoop()
File "/usr/lib/python2.7/site-packages/twisted/internet/base.py", line 1174, in mainLoop
self.runUntilCurrent()
--- <exception caught here> ---
File "/usr/lib/python2.7/site-packages/twisted/internet/base.py", line 769, in runUntilCurrent
f(*a, **kw)
File "/RAM/phoenix2/phoenix2/plugins/opencl/__init__.py", line 462, in postprocess
if not self.interface.foundNonce(nr.unit, int(output)):
File "/RAM/phoenix2/phoenix2/core/KernelInterface.py", line 200, in foundNonce
hash = self.calculateHash(wu, nonce, timestamp)
File "/RAM/phoenix2/phoenix2/core/KernelInterface.py", line 187, in calculateHash
hashInput = pack('>76sI', staticData, nonce)
struct.error: integer out of range for 'I' format code
[20:33:44] Disconnected from server ^C
Ideas? |
|
|
|
the shit you go through for this software, man, i don't know how you do it.
have a couple more btc for your troubles.
^^^ What he said.... |
|
|
|
downloaded v0.5, still not working.
Same problem here... Anubis is working, --api-allow enable too... cgminerweb shows miners offline...  Same here. Fedora 14 LAMP, all miners reachable, Anubis works from same machine (different directory), cgminerweb shows all hosts offline, whether IP address or hostname are provided. Seeing lots of complains in the apache error_log: [Mon Apr 30 08:30:46 2012] [error] [client XX.XX.XX.XX] PHP Warning: socket_create(): Unable to create socket [1]: Operation not permitted in /var/www/html/cgweb/includes/apiSocket.php on line 125, referer: http://192.168.1.101/cgweb/miners.php[Mon Apr 30 08:30:46 2012] [error] [client XX.XX.XX.XX] PHP Warning: socket_set_option() expects parameter 1 to be resource, boolean given in /var/www/html/cgweb/includes/apiSocket.php on line 126, referer: http://192.168.1.101/cgweb/miners.phpand FWIW, PHP believes sockets are enabled sockets
Sockets Support enabled
|
|
|
|
|
just wanted to say.. well done...
downloaded, followed the directions, and it just -- worked --
Thanks, for this, and the other scripts of yours I'm running. /clap
|
|
|
|
wrt cgminer, your sample miner5 devices 0, 1 and 3 temperature graph has a lot more variability than I would expect to see if you are using the auto features. I see that device 2 of miner5 graphs for the same time frame show more temperature stability. Is this by chance a card with reduced airflow compared with devices 0, 1 and 3 or are you using different settings for these cards?
Identical settings, miner5 has 4 58xx cards with zero space between them, lots of airflow, but the middle cards stay hotter. |
|
|
|
PXE/NFS diskless We need to talk.  Once I get some of my hardware setup I would like to talk about your PXE setup. Happy to help.. it's quite painful to get working right initially, but once it is, it's ... delightful to maintain.. and bringing up new hardware is so quick it makes it all worthwhile. |
|
|
|
not a lot to see, but average temps across miners1-9.. using CGminer with a target temp of 80C, hence the flat lines around there. example:  See the rest at: http://imgur.com/a/Hxssv/allThanks again JinTu for your work and help! |
|
|
|
Figured I'd share pictures of one of the mining racks.. 8 machines, all rack mounted, corsair Power supplies, 890FXA-GD70, Athlon x2's 2G ram, 27 ATI/AMD cards mix of 58xx,69xx, PXE/NFS diskless, runs mid 9 GH most days. cgminer set to auto-fan 20%-100%, target temp 80C. http://imgur.com/a/JYoz5 --  |
|
|
|
|
Show Posts
