greetings friends,
When I learned about this concept I thought it was one of the coolest things I've come acrossed in awhile. My first attempt at mining was with a iCore-3 cpu and that was crawling along at 1.5Mhash/s, so I found a great deal on a Saphire Vapor-X Radeon HD 5870 (craigslist $175) and have been rockin that with the guiminer and getting 300MHash/s+ ... my question is do you think its better for someone in my position with a fairly decent gpu to just use the bitcoin client on my own or to participate in a pool (which I am currently doing)
What is the standard accepted as a Ghash rate that is capable of mining on its own? Is there any recommendations here , where is the cut off point?
Thanks!
-iMMUNE
Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 1065. (Read 4382653 times)
May 01, 2011, 07:05:21 AM
May 01, 2011, 05:31:38 AM
Why is there no round reward information in the stats anymore?? D:
edit: it was just cause i didn't have any reward in the rounds displayed (just came back from vacation 8-))
my bad
edit: it was just cause i didn't have any reward in the rounds displayed (just came back from vacation 8-))
my bad
April 30, 2011, 04:48:55 PM
Is there a trick to changing your password? I can't find a link anywhere...
Also it'd be really neat to be able to bulk create worker accounts. Either multiple on the site, or an API to do it would be best.
Also it'd be really neat to be able to bulk create worker accounts. Either multiple on the site, or an API to do it would be best.
April 30, 2011, 04:06:39 PM
Maybe this has been addressed, but I couldn't find it...
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
You might try upping your ask rate? My argument line looks like this:
C:/Phoenix/phoenix.exe -u http://[email protected]:8332/;askrate=10 -k poclbm VECTORS BFI_INT FASTLOOP AGGRESSION=7 DEVICE=1
This might help keep you out of trouble.
So it seems like askrate is how long the mining client will wait (in ms) before it requests more work from the server IF the server has not already sent it work? Great, thanks for the help, I'll try it out.
I'm not sure about the interval, but yes, that's the gist.
April 29, 2011, 03:03:45 PM
Maybe this has been addressed, but I couldn't find it...
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
You might try upping your ask rate? My argument line looks like this:
C:/Phoenix/phoenix.exe -u http://[email protected]:8332/;askrate=10 -k poclbm VECTORS BFI_INT FASTLOOP AGGRESSION=7 DEVICE=1
This might help keep you out of trouble.
So it seems like askrate is how long the mining client will wait (in ms) before it requests more work from the server IF the server has not already sent it work? Great, thanks for the help, I'll try it out.
April 29, 2011, 02:37:28 PM
Maybe this has been addressed, but I couldn't find it...
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
You might try upping your ask rate? My argument line looks like this:
C:/Phoenix/phoenix.exe -u http://[email protected]:8332/;askrate=10 -k poclbm VECTORS BFI_INT FASTLOOP AGGRESSION=7 DEVICE=1
This might help keep you out of trouble.
April 29, 2011, 10:43:25 AM
Maybe this has been addressed, but I couldn't find it...
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
Twice now, when I have left phoenix running connected to slush's pool, I have woken up to find phoenix waiting on workorders from the server. It only drops to 0Mhas/s for maybe a second or less before it gets a new work order then goes back to normal until it finished that work. Restarting phoenix fixes the problem.
Would this be something wrong with the pool's server? Or phoenix? And what can I do to stop it? Obviously I could make sure to restart phoenix before leaving it running for a while but that is more of a bandaid.
April 29, 2011, 08:55:10 AM
Traceroute can do a "TCP traceroute", just add -P TCP -p 80.
For more info use "man traceroute".
For more info use "man traceroute".
actually he needs to do it for port 8332, i.e. miner port
linux command
$sudo traceroute mining.bitcoin.cz -P TCP -p 8332
ok, the problem is back ;(
chrome sez: Connection to 178.79.147.99 failed.
ping works:
Code:
nick@zero ~ $ ping -c 2 mining.bitcoin.cz
PING mining.bitcoin.cz (178.79.147.99) 56(84) bytes of data.
64 bytes from mining.bitcoin.cz (178.79.147.99): icmp_seq=1 ttl=54 time=53.0 ms
64 bytes from mining.bitcoin.cz (178.79.147.99): icmp_seq=2 ttl=54 time=52.6 ms
--- mining.bitcoin.cz ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 52.677/52.877/53.078/0.305 ms
a tcp traceroute however seems to reveal some problem (with 212.111.33.234?):
Code:
nick@zero ~ $ sudo traceroute -P TCP -p 80 mining.bitcoin.cz
Password:
traceroute to mining.bitcoin.cz (178.79.147.99), 30 hops max, 60 byte packets
1 nf.dyndns.org (192.168.33.128) 0.171 ms 0.099 ms 0.076 ms
2 lo1.br04.asham.de.hansenet.net (213.191.84.203) 31.278 ms 30.827 ms 31.039 ms
3 62.109.72.62 (62.109.72.62) 31.161 ms 30.761 ms 30.538 ms
4 62.109.72.1 (62.109.72.1) 56.806 ms 31.056 ms 30.574 ms
5 ae1-0.pr02.weham.de.hansenet.net (213.191.66.181) 30.649 ms 31.369 ms 31.393 ms
6 rmwc-hmbg-de02-chan-0-0.nw.mediaways.net (195.71.250.237) 38.506 ms 33.679 ms 31.178 ms
7 xmwc-amsd-nl02-chan-1-0.nw.mediaways.net (195.71.212.242) 45.165 ms 45.045 ms 44.479 ms
8 peer1.ams2.telecityredbus.net (195.69.144.113) 46.364 ms 62.049 ms *
9 * * 85.90.238.45 (85.90.238.45) 57.651 ms
10 te4-1-dist65-01.lon10.telecity.net (217.20.44.218) 52.911 ms 53.387 ms 52.346 ms
11 212.111.33.234 (212.111.33.234) 53.121 ms 52.966 ms 52.586 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
mining also works without problem, so it seems to me some transparent proxy fucks stuff up?
Any ideas? 2nds?
April 29, 2011, 12:48:23 AM
can anyone help me? i keep on getting an error "problems communicating to bitcoin rpc" ive tried several different miners to no effect.
April 28, 2011, 06:49:48 PM
OK, I wrote simple watchdog which will restart bitcoind once it crash again, because I'll be out for following two days. This surely helps and I'll definitely compile patched bitcoind on monday.
You rule, Slush. Site's back up and looking great.
April 28, 2011, 06:40:03 PM
OK, I wrote simple watchdog which will restart bitcoind once it crash again, because I'll be out for following two days. This surely helps and I'll definitely compile patched bitcoind on monday.
April 28, 2011, 06:06:25 PM
Confirmed down as here well...502. 
April 28, 2011, 05:37:48 PM
Are miners still getting paid out by slush-pool while this webpage outage is occurring?
Seems okay on the back-end of the mining.
No, if bitcoind is down [which it is since slush said that is what causes the site to do down], then nobody can get paid. You will get paid when it comes back up though.
April 28, 2011, 05:35:22 PM
Are miners still getting paid out by slush-pool while this webpage outage is occurring?
Seems okay on the back-end of the mining.
April 28, 2011, 05:34:33 PM
Bad gateway for me. I was having some weird time out connections with phoenix 1.3, switched to the new build of poclbm (same performance as phoenix) we'll see if connection time out issues return.
April 28, 2011, 05:15:03 PM
502 error yet again today.
I too have experienced this at least a couple of times today. ...including right now.
i have that problem too, but if i close phoenix and stop mining the site works again... there is some kind of conflicts with the ip?
I stopped mining a little while ago and the site is still not accessible to me. You probably got a cached version if I had to guess.
April 28, 2011, 05:09:16 PM
502 error yet again today.
I too have experienced this at least a couple of times today. ...including right now.
i have that problem too, but if i close phoenix and stop mining the site works again... there is some kind of conflicts with the ip?
April 28, 2011, 04:30:50 PM
502 error yet again today.
I too have experienced this at least a couple of times today. ...including right now.
April 28, 2011, 04:24:00 PM
502 error yet again today.
April 28, 2011, 01:12:39 PM
Traceroute can do a "TCP traceroute", just add -P TCP -p 80.
For more info use "man traceroute".
For more info use "man traceroute".
actually he needs to do it for port 8332, i.e. miner port
linux command
$sudo traceroute mining.bitcoin.cz -P TCP -p 8332
actually no, I need port 80. the webpage didn't work (problem resolved itself somehow), I could, however, mine fine.
Jump to: