@FD,
Sorry to see the pool stats as they are - cross my fingers that a good luck streak is hit.
Is there a donation address for the pool?
Topic: [500 GH/s]HHTT -Selected Diff/Stratum/PPLNS/Paid Stales/High Availability/Tor - page 26. (Read 56478 times)
October 06, 2012, 06:01:09 PM
October 05, 2012, 07:26:33 PM
Are you really 60 BTC in the hole? This has me worried. How can you keep going with those kind of losses?
Code:
Income Paid Net
400.00000000 460.36536787 -60.36536787
I am absolutely that far in the hole.
I have some sort of organic poptart that tastes like sadness. I nibble it as I ponder what I have done to get myself where I am. I have regrets but not that many.
As doublec said. I think it's why DeepBit started with such a large fee.
The following is from Meni Rosenfeld's paper "Analysis of Bitcoin Pooled Mining Reward Systems" (any transcription errors are mine) :
Quote
......
Conversely, to maintain a bankruptcy probability of at most , the pool should keep a reserve
of at least:
R = B ln(1/delta)/2f
For example, if B = 50 BTC; delta = 1/1000 and f = 0:05 (5% fee), the reserve should be
R = 50 BTC * ln(1000) / (2 * 0.05) = 3454 BTC
If the operator tries to make do with f = 0:01 but only has a reserve of 500 BTC, then
delta = exp ( -2 * 0.01 * 500 BTC / 50 BTC) ~ 0.819
so he has 81.9% chance of eventual bankruptcy.
The Neighbourhood Pool Watch post on the risks of SMPPS discusses a related problem.
October 05, 2012, 06:29:10 PM
Are you really 60 BTC in the hole? This has me worried. How can you keep going with those kind of losses?
Variance with pools is enormous. The pool can expect to be 10x up or down that at least. 
October 05, 2012, 02:46:05 PM
Are you really 60 BTC in the hole? This has me worried. How can you keep going with those kind of losses?
Code:
Income Paid Net
400.00000000 460.36536787 -60.36536787
I am absolutely that far in the hole.
I have some sort of organic poptart that tastes like sadness. I nibble it as I ponder what I have done to get myself where I am. I have regrets but not that many.
October 05, 2012, 02:29:32 PM
Are you really 60 BTC in the hole? This has me worried. How can you keep going with those kind of losses?
Code:
Income Paid Net
400.00000000 460.36536787 -60.36536787
September 27, 2012, 01:03:40 PM
i always use IP address when mining, well, ever since eclipsemc name servers messed up... uh.. 7 or 8 months ago? don't remember.
September 27, 2012, 11:58:17 AM
Wow. Try putting rpc.hhtp.1209k in your hosts file (50.112.109.226) so DNS is removed from the equation. Does anyone know if cgminer caches DNS info?
On linux add to /etc/hosts:
50.112.109.226 rpc.hhtt.1209k.com
On linux add to /etc/hosts:
50.112.109.226 rpc.hhtt.1209k.com
bitcoindaddy,
your suggestion was right, this is the same test after I put pool name inside hosts
Code:
$ time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"7e44ba94c313603ed64a65ff6368f9da0e8c3dfada97a819f867ecf2efc9c68b","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"00000002d2ebd8553d06b382352b7f39ead71feae3a2cbee30d28e0a0000019300000000460bb67f0c0b9d72e8766ff88f8068addf9ba4cd1ee99632623a63197b134e17506476dc1a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m0.479s
user 0m0.020s
sys 0m0.016s
~$ time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"217855e033bf90b70d2524874cd2ef8ee0327af8fa7b95de884d57680b46435e","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"00000002d2ebd8553d06b382352b7f39ead71feae3a2cbee30d28e0a0000019300000000de1c00bbaaa499116e99e186b8de01a8d086cb9705f49a6e089a12c7ea6a4106506476df1a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m0.481s
user 0m0.024s
sys 0m0.016s
~$ time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"eb5c53141e9582c28a54cd28e61e9800e845d4a949596d31ddcc3ce6a4783f24","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"00000002d2ebd8553d06b382352b7f39ead71feae3a2cbee30d28e0a000001930000000004d3deee22fdbabc43f89169b201df1d693f0be54a04f8bba9a21edd6e27fd05506476e21a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m0.516s
user 0m0.016s
sys 0m0.024s
So it is name resolution... but nslookup is fast, though.
Thanks for your help!
spiccioli
September 27, 2012, 11:51:02 AM
fireduck,
I've just made three tests
summary: 20sec,10sec,20sec
spiccioli
I've just made three tests
summary: 20sec,10sec,20sec
spiccioli
Ok, wow. That is certainly a problem. Those should be taking less than a second. I haven't seen any take nearly that long. Can you test some other things around the net to see where that latency is coming from and do some pings and traceroutes around?
fireduck,
Code:
$ ping -U rpc.hhtt.1209k.com
PING rpc.hhtt.1209k.com (50.112.109.226) 56(84) bytes of data.
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=1 ttl=39 time=210 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=2 ttl=39 time=207 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=3 ttl=39 time=208 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=4 ttl=39 time=281 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=5 ttl=39 time=268 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=6 ttl=39 time=257 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=7 ttl=39 time=217 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=8 ttl=39 time=235 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=9 ttl=39 time=208 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=10 ttl=39 time=214 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=11 ttl=39 time=210 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=12 ttl=39 time=208 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=13 ttl=39 time=207 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=14 ttl=39 time=207 ms
64 bytes from rpc.hhtt.1209k.com (50.112.109.226): icmp_req=15 ttl=39 time=208 ms
^C
--- rpc.hhtt.1209k.com ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 14017ms
rtt min/avg/max/mdev = 207.457/223.489/281.187/24.204 ms
traceroute shows nothing...
Code:
$ sudo traceroute rpc.hhtt.1209k.com
traceroute to rpc.hhtt.1209k.com (50.112.109.226), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
it takes a few seconds before first hop is shown, though
with -T
Code:
$ sudo traceroute -T rpc.hhtt.1209k.com
traceroute to rpc.hhtt.1209k.com (50.112.109.226), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 rpc.hhtt.1209k.com (50.112.109.226) 215.003 ms 218.025 ms 214.996 ms
they seem to me as "normal" values... what do you think?
spiccioli
September 27, 2012, 11:32:47 AM
20 seconds is an eternity. What country are you in?
Italy.
spiccioli
September 27, 2012, 10:38:13 AM
What does it look like for time when you just do the getwork from the command line?
fireduck,
I've just made three tests
summary: 20sec,10sec,20sec
spiccioli
Ok, wow. That is certainly a problem. Those should be taking less than a second. I haven't seen any take nearly that long. Can you test some other things around the net to see where that latency is coming from and do some pings and traceroutes around?
September 27, 2012, 10:01:00 AM
Wow. Try putting rpc.hhtp.1209k in your hosts file (50.112.109.226) so DNS is removed from the equation. Does anyone know if cgminer caches DNS info?
On linux add to /etc/hosts:
50.112.109.226 rpc.hhtt.1209k.com
On linux add to /etc/hosts:
50.112.109.226 rpc.hhtt.1209k.com
bitcoindaddy,
DNS seems fast enough...
Code:
$ time nslookup rpc.hhtt.1209k.com
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
Name: rpc.hhtt.1209k.com
Address: 50.112.109.226
real 0m0.033s
user 0m0.008s
sys 0m0.016s
spiccioli
20 seconds is an eternity. What country are you in?
September 27, 2012, 09:17:18 AM
Wow. Try putting rpc.hhtp.1209k in your hosts file (50.112.109.226) so DNS is removed from the equation. Does anyone know if cgminer caches DNS info?
On linux add to /etc/hosts:
50.112.109.226 rpc.hhtt.1209k.com
On linux add to /etc/hosts:
50.112.109.226 rpc.hhtt.1209k.com
bitcoindaddy,
DNS seems fast enough...
Code:
$ time nslookup rpc.hhtt.1209k.com
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
Name: rpc.hhtt.1209k.com
Address: 50.112.109.226
real 0m0.033s
user 0m0.008s
sys 0m0.016s
spiccioli
September 27, 2012, 09:02:25 AM
September 27, 2012, 02:14:38 AM
What does it look like for time when you just do the getwork from the command line?
fireduck,
I've just made three tests
Code:
$ time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"b93b9ac85da42577453db4df5e3743ada4feeb20601db33d9a20efb34e79128a","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"000000020a65d61cf63f18462397845d4c167ec5c0c07fddae5e814e0000056c000000001d9e2f6010bab1416aa90c6b33f49a6e359ab8b13f8115dd7ff8351cb526889a5063ee241a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m20.495s
user 0m0.016s
sys 0m0.020s
$ time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"8845cf930b149e17d77b3c63b3c3539a60496654b1493b48bad364ca09458775","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"000000020a65d61cf63f18462397845d4c167ec5c0c07fddae5e814e0000056c0000000090401d646b6125d235380d0bb8f6d18568c623eac643dec293bc5c9efaae93225063ee341a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m10.554s
user 0m0.016s
sys 0m0.020s
$ time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"06f5fc3e76d3bf01e2250316ecaa6a96b0e79a1a371efab3799d8ce3296460b2","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"000000020a65d61cf63f18462397845d4c167ec5c0c07fddae5e814e0000056c00000000033d51fe3a9a0142e5576c694639e08d46d854221579742ada1de20609ea235d5063ee4b1a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m20.498s
user 0m0.020s
sys 0m0.020s
spiccioli
September 26, 2012, 04:42:48 PM
What does it look like for time when you just do the getwork from the command line?
Code:
: time curl -u 1FDkoGo8o9tmXD4cYpAqBZeWACJiYjMm3x_1:foo --data '{"method":"getwork","params":[],"id":1}' http://rpc.hhtt.1209k.com:8337/
{"id":1,"error":null,"result":{"midstate":"c64f8ea2f7221136c976492613fe1822122847ce5e92793c13dfcb1b1b8598a6","target":"0000000000000000000000000000000000000000000000000000008000000000","data":"000000023e0344e6e5855b24ffdbee62e4c57bcfb52adc64a5a7779b000004fd00000000098c59bc923d77e04002fd2374f6bf6a2c63d19fe179f1d4512cbe0db38ba923506368101a05db8b00000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000","hash1":"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000"}}
real 0m0.057s
user 0m0.001s
sys 0m0.008s
September 26, 2012, 04:14:43 PM
I'm using difficulty 32.
I'll try to use 256 for a while, but it seems to me that the problem is in requesting more work, not in submitting less.
Cheers,
spiccioli
It could also be the clock on your system. If you clock is off your mining software might think it is unable to change the time on the work unit to scan for more good nonces. If it can't do that, it will end up having to request a lot of work from the server since it will only be able to do 2^32 hashes on each work unit.
Hi,
time should be ok, I have ntpd running
Code:
~$ ntpq
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
+2-229-10-127.ip 193.204.114.232 2 u 407 1024 373 19.548 0.912 15.804
-93.62.188.182 193.204.114.233 2 u 370 1024 377 23.031 -2.972 2.715
*2.228.72.62 193.204.114.233 2 u 625 1024 377 30.171 -0.362 1.984
+flo.m4oc.it 193.204.114.232 2 u 747 1024 377 43.694 -0.527 0.608
-europium.canoni 193.79.237.14 2 u 867 1024 377 44.668 6.510 0.836
ntpq> ass
ind assid status conf reach auth condition last_event cnt
===========================================================
1 37325 941a yes yes none candidate sys_peer 1
2 37326 931a yes yes none outlyer sys_peer 1
3 37327 961a yes yes none sys.peer sys_peer 1
4 37328 941a yes yes none candidate sys_peer 1
5 37329 932a yes yes none outlyer sys_peer 2
ntpq>
spiccioli
September 26, 2012, 01:24:13 PM
I'm using difficulty 32.
I'll try to use 256 for a while, but it seems to me that the problem is in requesting more work, not in submitting less.
Cheers,
spiccioli
It could also be the clock on your system. If you clock is off your mining software might think it is unable to change the time on the work unit to scan for more good nonces. If it can't do that, it will end up having to request a lot of work from the server since it will only be able to do 2^32 hashes on each work unit.
September 26, 2012, 11:23:22 AM
hi fireduck,
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
What difficulty are you using? If you are seeing that, my guess is that you need to increase that number. At 7GH/s 128 or 256 would probably be good.
I'm using difficulty 32.
I'll try to use 256 for a while, but it seems to me that the problem is in requesting more work, not in submitting less.
Cheers,
spiccioli
September 26, 2012, 10:53:00 AM
hi fireduck,
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
What difficulty are you using? If you are seeing that, my guess is that you need to increase that number. At 7GH/s 128 or 256 would probably be good.
September 26, 2012, 06:49:20 AM
hi fireduck,
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
I'm getting more and more of:
Pool 0 not providing work fast enough
when mining here, is there something you can do to improve this?
thanks.
spiccioli
ps. I have a little more than 7 GH/s
Jump to: