Hmm... this seems like it would be more worth while since getting paid per share is kinda... low.. also my slow GPU isn't really doing shares all that fast heh On average Proportional will give you 7% more than PPS. But it depends on pool's luck. At this moment the luck is lower than usual, so you'll get more with PPS. In both modes your reward depends partially or fully on the number of shares submitted. |
|
|
|
So with proportional, I find a 50BTC block, i get paid ~40 something less a fee? How did I get 0.01 over the span of 1 hour then?
with pay per share, its pretty cut and dry. I just don't understand how proportion is working
When pool finds a block, it's divided propotionally to all the participants. |
|
|
|
okay so I switched to a Cuda miner and it boosted to 60khash/s.... but I still don't understand how PPS versus proportional works... is there a wiki detailing this? I wanna find out which is better for BTC production!
It's on the main page. I'll add the description on the registration page too... anyone know what the whole "found hash!" thing that keeps poping in my CMD window is? I only started seeing it when I swithched to Cuda based RPC miner from poclbm It means that you found a share. poclbm says "accepted" in this case. |
|
|
|
27.04.2011 15:09:58 2h 01m 343371
27.04.2011 13:08:43 1h 14m 210267
27.04.2011 11:54:21 1h 51m 309034
27.04.2011 10:03:08 1h 15m
I'm going PPS :D Good :) But you should remember that each block's lenght doesn't depends on the previous ones :) |
|
|
|
2) Это не фальшивка. Покажите мне оригинал! :) Liberty Dollars priznali fal'shivkoi dazhe bez originala, tak chto eto ne pomeshaet :) |
|
|
|
My question is does having cards in the 8x and 4x slots decrease your mining throughput?
No. PCIe x1 is perfectly fine for mining |
|
|
|
I know the 5970's and 5870's are pretty much the 'sweet spot' right now. Hard to find new though. You don't need new. Used ones are MUCH more cost-effective. |
|
|
|
Tycho, can you write the average traffic that is generated to/from us, corresponding to Mhash/s ?
I counted about 44KB/s, which means around 5000MB per month for dedicated rig. Trying to reduce the packets, nothing more :)
44 Kbps is more than i expect. Should be around 600+ bytes per getwork. Will check it. |
|
|
|
Tycho, i have 9 workers so far and i need more!
i cannot use more? i don't see the button to create a worker >:(
thanks Fixed. |
|
|
|
What's interesting is RPCProtocol doesn't use any Python HTTP libraries, it's all done through Twisted;
so while it could be a problem in Twisted, I don't think the linked bug is the answer.
The lack of TCP_NODELAY is interesting. Doesn't that only disable Nagle's algorithm, which affects sends?
How would it delay received data?
Please, read this: http://code.google.com/p/httplib2/issues/detail?id=28http://code.google.com/p/httplib2/issues/detail?id=91During some tests I made, I measured some very long delays in replies to HTTP POST using httplib2.
It turns out the delays are caused by Nagle algorithm, and that performance can be greatly improved by setting TCPNODELAY, which disables Nagle's algorithm. Nagle vs delayed ack issues have been around for a while. The correct way to fix this is NOT to set TCPNODELAY but to fix httplib2 to issue the header and body as a combined write. This way small commands are issued in a single packet as the gods of TCP intended. Large commands are sent in multiple packets right away as Nagle doesn't apply in that case.
The TCPNODELAY fix is a workaround, but it results in inefficient bandwidth use. |
|
|
|
What's interesting is RPCProtocol doesn't use any Python HTTP libraries, it's all done through Twisted;
so while it could be a problem in Twisted, I don't think the linked bug is the answer.
The lack of TCP_NODELAY is interesting. Doesn't that only disable Nagle's algorithm, which affects sends?
How would it delay received data?
I didn't saw your source yet and can only see the results at my side, sorry. It means that the reason for that delay is different. Look for a log fragment in PM. |
|
|
|
Curious for the PSU suggestions for a dual 5970. Seems you could get by with a good 850 watt like an HX850? 850W is recommended, but good 750W one will work too (not recommended). Don't use cheap nameless PSUs, they are usually overrated. |
|
|
|
I cant wait for Tycho to implement notification for when a miner is down. I just check his site on my iPhone once an hour now but itll be nice to be able to chill by the pool without having to check.
Thanks for this reminder :) |
|
|
|
I just want to know if the mining program is still running, and hash speed if possible.
On the pool's site, in the case of deepbit.net, I would be looking at the "Shares" column?
Yes. Also you can set timeout threshold and worker name will turn red if no share is received within that time. |
|
|
|
A bit of a noob question here, but is there a particular directory in Windows 7 that Phoenix must be extracted to in order for it to function. I can't seem to get the program to open properly, it just flashes the command prompt and closes. I currently have it extracted to my desktop. There is no GUI, you should supply some command-line arguments for it to work. Start a command prompt (cmd) or some FAR-like file manager and try to run it from there. |
|
|
|
I am sure many have built several dedicated mining rigs without monitors attached.
How do you guys monitor the PCs to make sure the mining program is still running and not hanged?
I know I can use VNC to remotely login into the PC and check on it, but that requires me login into individual PCs.
I am in need of a way to monitor all mining clients all at once, whats the best way to do it? What parameters do you want to monitor ? Hashing speeds, temps or what else ? You can see how the mining program is running by looking at your personal page on the pool's site. |
|
|
|
Looks like you aren't receiving private messages from me, so i'm writing here. Your miner inherited an old poclbm bug (or just recreated it) - reading pool's answer takes very long time with your miner, about ~200 ms and up to 2 sec in some cases - i see this in my pool's log. When we discussed this with m0mchil, he managed to fix it and now this delay is close to 0 ms. Two possible causes of this: 1) Python bug - reading HTTP headers by one byte at a time ( http://bugs.python.org/issue1542407 ) 2) TCP_NODELAY not used (looks like the main cause). This may also help: http://code.google.com/p/httplib2/issues/detail?id=91http://code.google.com/p/httplib2/issues/detail?id=28I'm not sure which one was the fix, but something should help :) |
|
|
|
|
Что за желание испортить людям жизнь ?
Ну прямо как тот хакер Вася с солонкой и перечницей.
|
|
|
|
надо про кодировку в правила форума занести... Да я забываю что форум глючный и жму "ответить" прямо в обычном браузере. На btcex.com. Только продавайте не сразу а частями. Там предложение очень маленькое, практически нету вообще. |
|
|
|
Âîïðîñ ãäå âçÿòü. Êòî ïðîäàñò?
Смотря почём :) Можно договориться. |
|
|
|
|
Show Posts
