Bitcoin Forum
November 10, 2024, 08:56:13 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 [110] 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 379068 times)
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
July 15, 2011, 03:41:51 AM
 #2181

My seven miners were connected to central.  They all stopped at the same time and I couldn't reconnect.  They are all connected to east now.  It happened at the end of the 3 hour block and I missed three fast blocks before I came home and changed servers.

Why?

Sam

The provider of our server uses Softlayer.  Softlayer was under attack by a very large DDoS and a LARGE number of servers that use Softlayer in that area were effectively offline (significant packet loss causing slow/unreliable connections).  As for your miners not reconnecting, that's something you'll have to ask the miner authors about.  The pool doesn't do any funny things with connections, its very standard pushpool in terms of authorization/getwork routing.

RIP BTC Guild, April 2011 - June 2015
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
July 15, 2011, 03:58:47 AM
 #2182

Received an email that finally gave me figures that show a significant level of pool hoppers in the pool could in fact be detrimental to the rewards of regular users.  Unless its a very large portion of users hopping the effect is very small (enough to be called luck noise), but it is there.  However, as mining is evolving, it may only be a matter of time before a client comes along with this capability built in.  If that were to happen, then it could create a noticeable impact.

I'm evaluating the two options I see that would "solve" the issue.  1 hour delay on stats, or SMPPS.  I was very anti-SMPPS at first, but the email I received included a comparison of how the payouts would have looked over a 72 hour period where pool hoppers were involved, using proportional vs SMPPS.  I'll be giving it some thought this weekend after I get miner idle emails back up and running.

RIP BTC Guild, April 2011 - June 2015
sgravina
Sr. Member
****
Offline Offline

Activity: 451
Merit: 250



View Profile
July 15, 2011, 04:02:21 AM
 #2183

My seven miners were connected to central.  They all stopped at the same time and I couldn't reconnect.  They are all connected to east now.  It happened at the end of the 3 hour block and I missed three fast blocks before I came home and changed servers.

Why?

Sam

The provider of our server uses Softlayer.  Softlayer was under attack by a very large DDoS and a LARGE number of servers that use Softlayer in that area were effectively offline (significant packet loss causing slow/unreliable connections).  As for your miners not reconnecting, that's something you'll have to ask the miner authors about.  The pool doesn't do any funny things with connections, its very standard pushpool in terms of authorization/getwork routing.

I could not reconnect to central.  But switching to east worked fine.  It seems my whole house was rejected by central, all 7 system system stopped at once and none could reconnect.  Could I have been placed on a 'black list' by mistake?  Nothing wrong with the miner software because I can connect to east with no problem.

Sam
fcmatt
Legendary
*
Offline Offline

Activity: 2072
Merit: 1001


View Profile
July 15, 2011, 04:02:39 AM
 #2184

what are the chances you can private message me the info you received or share it here on the btcguild thread if that is a better route
to go? thanks.

also... it seems delaying stats for just a little while is the easiest to implement. why an hour though? nice round number?
sgravina
Sr. Member
****
Offline Offline

Activity: 451
Merit: 250



View Profile
July 15, 2011, 04:08:55 AM
 #2185

Quote

I could not reconnect to central.  But switching to east worked fine.  It seems my whole house was rejected by central, all 7 system system stopped at once and none could reconnect.  Could I have been placed on a 'black list' by mistake?  Nothing wrong with the miner software because I can connect to east with no problem.

Sam

I just check and I can now connect to central.

I am going to write a health script that will restart the miners if there load drops.  If I can be black listed by a server it would be good to know so that I can switch to another.

Sam
PcChip
Sr. Member
****
Offline Offline

Activity: 418
Merit: 250


View Profile
July 15, 2011, 04:20:20 AM
 #2186

+1 for sharing as much of the email as you can without revealing anything sensitive


Also, +1 for delayed stats instead of changing up your payment system.  1 hour delay would be great, even better would be a random 55-75 minute delay.



Keep up the good excellent work!

Legacy signature from 2011: 
All rates with Phoenix 1.50 / PhatK
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
jjiimm_64
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


View Profile
July 15, 2011, 04:33:09 AM
 #2187

question:

If we get a 1 hour (or whatever) delay in the stats.  does that include the individual worker stats?  I use the worker stats to monitor my workers.  It would be..........well I would not like to loose the interface that you provide..  

Jim

edit:  all my connections just went down.....

edit 5 minutes later...  connections still down. I connect to uscentral

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
fcmatt
Legendary
*
Offline Offline

Activity: 2072
Merit: 1001


View Profile
July 15, 2011, 04:35:46 AM
 #2188

question:

If we get a 1 hour (or whatever) delay in the stat.  does that include the indvidual worker stats?  I use the worker stats to monitor my workers.  It would be..........well I would not like to loose the interface that your provide..  

Jim



i am almost 100% positive that the worker stats would only change a bit to no longer reflect when a new round
happens. in other words they would tell you the approx speed, shares, stales, last submitted share, etc.. but the
whole this/new round stat thing would have to change a bit so it does not tip off pool hoppers. After all they could
screen scrape that to detect when the pool found a block because the stats reset to 0 or a low value...
jjiimm_64
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


View Profile
July 15, 2011, 04:37:44 AM
 #2189

question:

If we get a 1 hour (or whatever) delay in the stat.  does that include the indvidual worker stats?  I use the worker stats to monitor my workers.  It would be..........well I would not like to loose the interface that your provide..  

Jim



i am almost 100% positive that the worker stats would only change a bit to no longer reflect when a new round
happens. in other words they would tell you the approx speed, shares, stales, last submitted share, etc.. but the
whole new round stat thing would have to change a bit so it does not tip off pool hoppers.

hmmm..  but one where to watch the number of shares, and you see the number of shares go down, doesn't that mean a round started.?

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
PcChip
Sr. Member
****
Offline Offline

Activity: 418
Merit: 250


View Profile
July 15, 2011, 04:44:51 AM
 #2190

question:

If we get a 1 hour (or whatever) delay in the stats.  does that include the individual worker stats?  I use the worker stats to monitor my workers.  It would be..........well I would not like to loose the interface that you provide..  

Jim

We are only asking him to delay the "BLOCK FOUND!" announcement that's like a dinner bell ringing for the hoppers

edit: it appears the stats page for workers is somewhat frozen in time... I started a new worker going ~200 MH/s and it's still not showing up as being active (20 mins+ later)

Legacy signature from 2011: 
All rates with Phoenix 1.50 / PhatK
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
jjiimm_64
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


View Profile
July 15, 2011, 04:49:47 AM
 #2191

question:

If we get a 1 hour (or whatever) delay in the stats.  does that include the individual worker stats?  I use the worker stats to monitor my workers.  It would be..........well I would not like to loose the interface that you provide..  

Jim

We are only asking him to delay the "BLOCK FOUND!" announcement that's like a dinner bell ringing for the hoppers

I realize that,  but I believe you can infer a block found when you 'shares this round' reset.  (are lower then last you checked).
That being said, the most important stat I use the the 'Last Share'  which tells me conclusively and very quickly that the miner is still accepting shares.

side question:  How do you get your 5850 to 400H.  is it flashed to a 5870?

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
fcmatt
Legendary
*
Offline Offline

Activity: 2072
Merit: 1001


View Profile
July 15, 2011, 04:52:39 AM
 #2192

getting a 5850 to 400 mh/s is quite the achievement and not a common thing for people to do.
a more realistic value would be 360-370 or so mh/s. it all depends on the type of 5850 and just how good
the silicon is.. meaning every chip is slightly different in a 5850.
PcChip
Sr. Member
****
Offline Offline

Activity: 418
Merit: 250


View Profile
July 15, 2011, 04:53:16 AM
 #2193


I realize that,  but I believe you can infer a block found when you 'shares this round' reset.  (are lower then last you checked).
That being said, the most important stat I use the the 'Last Share'  which tells me conclusively and very quickly that the miner is still accepting shares.

side question:  How do you get your 5850 to 400H.  is it flashed to a 5870?


part1: Yes he should delay those as well since you're right about being able to detect a new block that way.  As for your workers, normally the worker stats page is realtime (it seems frozen at this time though) so you should be able to hit F5 to refresh it and see if any of your worker threads are at 0 MH/s, also that will let you know exactly which GPU has crashed (if you name the workers sanely)


part2: I clocked it to ~980 MHz core, 300 MHz RAM, and have the latest PhatK Kernel improvements

Legacy signature from 2011: 
All rates with Phoenix 1.50 / PhatK
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
hugolp
Legendary
*
Offline Offline

Activity: 1148
Merit: 1001


Radix-The Decentralized Finance Protocol


View Profile
July 15, 2011, 05:03:04 AM
 #2194

question:

If we get a 1 hour (or whatever) delay in the stats.  does that include the individual worker stats?  I use the worker stats to monitor my workers.  It would be..........well I would not like to loose the interface that you provide..  

Jim

There is no need to delay the last share received or the speed worker stats, but the shares this rounds would need to be delayed because it reveals when a round starts.


               ▄████████▄
               ██▀▀▀▀▀▀▀▀
              ██▀
             ███
▄▄▄▄▄       ███
██████     ███
    ▀██▄  ▄██
     ▀██▄▄██▀
       ████▀
        ▀█▀
The Radix DeFi Protocol is
R A D I X

███████████████████████████████████

The Decentralized

Finance Protocol
Scalable
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
██▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀██
██                   ██
██                   ██
████████████████     ██
██            ██     ██
██            ██     ██
██▄▄▄▄▄▄      ██     ██
██▀▀▀▀██      ██     ██
██    ██      ██     
██    ██      ██
███████████████████████

███
Secure
      ▄▄▄▄▄
    █████████
   ██▀     ▀██
  ███       ███

▄▄███▄▄▄▄▄▄▄███▄▄
██▀▀▀▀▀▀▀▀▀▀▀▀▀██
██             ██
██             ██
██             ██
██             ██
██             ██
██    ███████████

███
Community Driven
      ▄█   ▄▄
      ██ ██████▄▄
      ▀▀▄█▀   ▀▀██▄
     ▄▄ ██       ▀███▄▄██
    ██ ██▀          ▀▀██▀
    ██ ██▄            ██
   ██ ██████▄▄       ██▀
  ▄██       ▀██▄     ██
  ██▀         ▀███▄▄██▀
 ▄██             ▀▀▀▀
 ██▀
▄██
▄▄
██
███▄
▀███▄
 ▀███▄
  ▀████
    ████
     ████▄
      ▀███▄
       ▀███▄
        ▀████
          ███
           ██
           ▀▀

███
Radix is using our significant technology
innovations to be the first layer 1 protocol
specifically built to serve the rapidly growing DeFi.
Radix is the future of DeFi
█████████████████████████████████████

   ▄▄█████
  ▄████▀▀▀
  █████
█████████▀
▀▀█████▀▀
  ████
  ████
  ████

Facebook

███

             ▄▄
       ▄▄▄█████
  ▄▄▄███▀▀▄███
▀▀███▀ ▄██████
    █ ███████
     ██▀▀▀███
           ▀▀

Telegram

███

▄      ▄███▄▄
██▄▄▄ ██████▀
████████████
 ██████████▀
   ███████▀
 ▄█████▀▀

Twitter

██████

...Get Tokens...
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
July 15, 2011, 05:07:37 AM
 #2195

I will likely implement the stat delay, since the response to possibly changing payout scheme from proportional is quite mixed.  Essentially "This Round" would be removed from worker stats.  You'd have:

Est. Speed, Total Shares (Since Reset), Total Shares (All time), and Last Share Received

Reset shares and last share received are being fixed tonight/tomorrow.  I will hold off on implementing a stat delay until those are back in place to allow reasonable worker monitoring.

RIP BTC Guild, April 2011 - June 2015
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
July 15, 2011, 05:08:51 AM
 #2196

The worker stats froze because the sync script was failing to connect to US Central.  The connection issues on Central are outside of my control, they're a network wide issue, not a server specific issue.  Once I get the reset shares/last shares restored I'll split the sync script for worker stats so an individual server won't stop the rest of the workers from updating.

RIP BTC Guild, April 2011 - June 2015
jjiimm_64
Legendary
*
Offline Offline

Activity: 1876
Merit: 1000


View Profile
July 15, 2011, 06:05:31 AM
 #2197

eleu:

 I am seeing an amount on my Unconfirmed Rewards.  I have not seen this above 0 since I started donating 2.5%/  currently donating 5% and have not change it.  is the central issue possibly to blame?  I am connected to that and did see the connection issues for a while.

edit:   looking around for that luck switch...  these 5 hour blocks will kill a good man.

1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
Coolhwip
Member
**
Offline Offline

Activity: 119
Merit: 10


View Profile
July 15, 2011, 06:16:21 AM
Last edit: July 17, 2011, 12:44:09 PM by Coolhwip
 #2198

Same, I'm seeing unconfirmed rewards and I'm donating 2.5%

Thanks for your reply.
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
July 15, 2011, 06:26:56 AM
 #2199

Fixed the bug.  Optimized the database to significantly reduce size and speedup SELECT queries.  Ended up changing block_number (not block ID) to an unsigned value momentarily, then set it back to unsigned after remembering block_number is set to -1 on invalids.

RIP BTC Guild, April 2011 - June 2015
pdawg
Sr. Member
****
Offline Offline

Activity: 252
Merit: 250


View Profile
July 15, 2011, 06:27:31 AM
 #2200

eleu:

 I am seeing an amount on my Unconfirmed Rewards.  I have not seen this above 0 since I started donating 2.5%/  currently donating 5% and have not change it.  is the central issue possibly to blame?  I am connected to that and did see the connection issues for a while.

edit:   looking around for that luck switch...  these 5 hour blocks will kill a good man.

Yea the last 48 hrs have yielded lower than usual btc, the 24hr prior to that was smoking hot.  One question I have is when does the miner idle warning setting buttons return?

Pages: « 1 ... 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 [110] 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!