Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 25. (Read 379084 times)
August 01, 2011, 12:33:03 PM
connection problems
August 01, 2011, 12:00:41 PM
10%+ increase. Not the worst, not the best.
But yea, luck has been pretty good.
But yea, luck has been pretty good.
August 01, 2011, 11:13:20 AM
The 24H luck is slightly skewed right now due to the difficulty change. We are definitely still positive, but not quite 70%. We are certainly off to a nice start this difficulty though.
August 01, 2011, 10:48:03 AM
24 Hour Luck +72.5%
holy shit.
and my miners have been lucky on top of that (they are reporting about 20% higher hashrate than they actually get) so all in all I've made about double normal earnings in the last 24 hours.
holy shit.
and my miners have been lucky on top of that (they are reporting about 20% higher hashrate than they actually get) so all in all I've made about double normal earnings in the last 24 hours.
August 01, 2011, 08:31:23 AM
I know this may be a bit early to ask, but do you have any plans to add NameCoin mining support when the merge mining starts sometimes in September?(est.)
I'm looking into it, but I'm not rushing for the chance. I personally feel that namecoins are a waste of space. Their adoption will be limited to a subset of users even smaller than TOR. At least TOR serves a purpose.
That said, I'm waiting to see if anybody modifies pushpool to work with merged mining. Merged mining with pools is going to be very tricky to implement, especially when a pool is already up and running.
July 31, 2011, 10:35:29 PM
I know this may be a bit early to ask, but do you have any plans to add NameCoin mining support when the merge mining starts sometimes in September?(est.)
July 31, 2011, 07:15:08 PM
Just noticed the note on the block statistics page,
"On very short rounds (< 1 minute), it is possible that one server is not sync'd up with the current round # before a block is found, meaning miners on that server won't have had any shares recorded for that round"
Does that mean if we got a few shares in on the short round, they'll be carried over to the next round instead of being applied to the short one, or they'll just be lost? (because neither scenario is favorable)
"On very short rounds (< 1 minute), it is possible that one server is not sync'd up with the current round # before a block is found, meaning miners on that server won't have had any shares recorded for that round"
Does that mean if we got a few shares in on the short round, they'll be carried over to the next round instead of being applied to the short one, or they'll just be lost? (because neither scenario is favorable)
If a server sync fails, it means the old server is still recording shares on the prior round. The sequence of events would be like this:
Server A and B are working on Round #1500.
Server A finds the block, updates to Round #1501, and tries to update Server B but fails.
Server A is now recording Round #1501 shares, while Server B is still working on Round #1500.
Server A finds a block before the fallback sync script executes, and updates to Round #1502, and updates Server B to the new round, skipping 1501 on Server B.
The rewards for #1500 would not be recorded until after server B had moved past that round, so Server B users didn't lose any shares, but they were applied to the Round #1500 instead of #1501.
This was only a "problem" when we were running with 7+ servers, where connection issues could easily occur between round synchronization. It only happened a few times, normally between euro and US servers.
Since consolidating to two servers, this has not happened. The sync script is much more aggressive at retrying. However, there is always a chance of it happening if something prevents the two servers from communicating a new block with each other, so I've left the warning there.
July 31, 2011, 07:01:48 PM
Just noticed the note on the block statistics page,
"On very short rounds (< 1 minute), it is possible that one server is not sync'd up with the current round # before a block is found, meaning miners on that server won't have had any shares recorded for that round"
Does that mean if we got a few shares in on the short round, they'll be carried over to the next round instead of being applied to the short one, or they'll just be lost? (because neither scenario is favorable)
"On very short rounds (< 1 minute), it is possible that one server is not sync'd up with the current round # before a block is found, meaning miners on that server won't have had any shares recorded for that round"
Does that mean if we got a few shares in on the short round, they'll be carried over to the next round instead of being applied to the short one, or they'll just be lost? (because neither scenario is favorable)
July 31, 2011, 02:35:52 PM
I guess they just couldn't let us have our record breaker 
.
.correct me if im wrong here... but wont this record keep going up as a function of the difficulty?
edit: I still have not found a block at btcguild. I have 2.98Million shares accepted here...
Yes, it will. The current difficulty is the expected average number of shares needed to find a block. But a round taking 10 times the expected shares is very unusual.
July 31, 2011, 01:41:00 PM
I guess they just couldn't let us have our record breaker .
.correct me if im wrong here... but wont this record keep going up as a function of the difficulty?
edit: I still have not found a block at btcguild. I have 2.98Million shares accepted here...
In theory no. Because difficulty goes up based on current network hash as people join. It should be believed that the same proportional number will join btc. So the time for found should remain the same. 6 mins/block to the whole network. And if btc hash remains the proportional as total network, it's at 50(something)mins/block here currently. I don't know what the exact time is.
In reality it won't happen that way tho. If more people join the network and less proportional joins btc (or none of the new miners) then btc will end up taking longer and longer. That's why it's so hard for new pools to start off. Getting people to join so it can hit critical mass and be large enough for people to stay.
July 31, 2011, 12:19:28 PM
I guess they just couldn't let us have our record breaker .
.correct me if im wrong here... but wont this record keep going up as a function of the difficulty?
edit: I still have not found a block at btcguild. I have 2.98Million shares accepted here...
July 31, 2011, 12:03:22 PM
I guess they just couldn't let us have our record breaker .
. July 30, 2011, 07:22:03 PM
12 million shares for this block and counting! When does it end!!! 
It ended with a record breaker (for BTC Guild, I would bet someone out there has a higher one though). Happy Block #2000 all. Now lets not get stuck on one like that again.
deepbit's new record!!
3h 37m 0 16180592
ow
July 30, 2011, 11:38:49 AM
I've been having the same problem, I hope it's because he implemented difficulty2 shares.
I had the same issue but I managed to fix it on my end by creating a backup miner which was pointed at the second server and had a higher -f setting(aka lower priority).
The reason I had to do this was because I run through TOR which causes you connection to lag slightly and for you to be put on Eleuthria botnet suspect list.
P.S. To Eleuthria, could you possibly fix that glitch? I've previously proved I'm not a botnet in a PM.
Because of this you have not convinced me that it is on my end. And I do not believe that none of your other users are not having this same issue.
I had the same issue but I managed to fix it on my end by creating a backup miner which was pointed at the second server and had a higher -f setting(aka lower priority).
The reason I had to do this was because I run through TOR which causes you connection to lag slightly and for you to be put on Eleuthria botnet suspect list.
P.S. To Eleuthria, could you possibly fix that glitch? I've previously proved I'm not a botnet in a PM.
July 30, 2011, 02:08:55 AM
If anyone knows what I can do to modify the Phatk kernel so I do not get the idles on BTC Guild please let me know.
Im using the modified phatk kernel, the last version adequate for poclbm, connected to uswest. Have no idles, last glitch was 15 hours ago and previously I went without any glitch for more 2-3 days.
Eleuthria: Have you changed the level of difficulty of the work you send to the miners? The miners speed (Mh/s) is fine and always around the real speed, but I am seeing more and more the last share over one minute, when previously it did almost never happened.
July 29, 2011, 10:03:20 PM
12 million shares for this block and counting! When does it end!!!
It ended with a record breaker (for BTC Guild, I would bet someone out there has a higher one though). Happy Block #2000 all. Now lets not get stuck on one like that again.
July 29, 2011, 09:32:45 PM
I built a rudimentary Google App that pulls JSON API data from BTC Guild and dumps it into a spreadsheet. It presents the same data as the BTC Guild My Account page as well as some additional calculated fields (and with the data in the spreadsheet, additional calculations, charts, etc can be easily added). It also provides alerts for idle workers and if the user defined stale share percentage threshold is exceeded. It can be run on demand and/or automatically at scheduled intervals. The format is optimized to be viewed on your smartphone, but it can be viewed on larger screens as well.
The existing app code could also be used as the basis to build other apps that utilize the API data. As I alluded to above, the code isn't optimized or elegant (I'm not a programmer) but it seems to be functional and I plan to enhance it further.
So I am looking for one or two people that would like to test this before I publicly post it. I'll provide you with a URL to generate your own copy under your Google Apps account (it's free). You'll enter your API key on your private copy, set your stale threshold and update interval and off you go. I just ask that you provide feedback to me on your experience.
Thanks
The existing app code could also be used as the basis to build other apps that utilize the API data. As I alluded to above, the code isn't optimized or elegant (I'm not a programmer) but it seems to be functional and I plan to enhance it further.
So I am looking for one or two people that would like to test this before I publicly post it. I'll provide you with a URL to generate your own copy under your Google Apps account (it's free). You'll enter your API key on your private copy, set your stale threshold and update interval and off you go. I just ask that you provide feedback to me on your experience.
Thanks
July 29, 2011, 09:28:50 PM
12 million shares for this block and counting! When does it end!!!
July 29, 2011, 09:09:45 PM
deepbit just had a 10+ million share block too... so we just beat that easily.
2h 18m 10339261
we can only hope that after this is solved.. we get several sub 1 hour blocks solved to make up for it.
oh. btw.. when a long block like this is attempting to be overcome.. when it is solved do we still have a delay
in stats? Like we may have already solved it but now we are just waiting for it to show up?
2h 18m 10339261
we can only hope that after this is solved.. we get several sub 1 hour blocks solved to make up for it.
oh. btw.. when a long block like this is attempting to be overcome.. when it is solved do we still have a delay
in stats? Like we may have already solved it but now we are just waiting for it to show up?
July 29, 2011, 08:28:32 PM
The bitcoin gods really don't want us to get our 2000th block .
. Jump to: