several builds... but mostly using
2x sapphire hd 5850
MSI 870-G45
Sempron 145
etc...
Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 126. (Read 379078 times)
June 03, 2011, 12:04:27 AM
June 03, 2011, 12:01:31 AM
Well for some reason, I'm still getting connection errors every 15-45 seconds are so... Anything I should check out on my router? Don't get this problem for deepbit though.
Are you working on an extremely fast single worker? I have 10 cards running at ~400 MH each, and my last idle was 9 minutes ago (and lasted ~3 seconds), and it was due to submitting two shares of work (so no work left in queue) within a 2 second window.
Try pinging the server, see what kind of results you get. If you're using phoenix, the problem will normally go away completely by adding -q 3 to your command arguments.
The connection errors seem to have died down. Looks good for now.
I'm using poclbm with 6 workers @ ~350MH/s and 1 worker @ ~400MH/s
Thanks for keeping up to date with your pool and the thread.
-edit-
connection error which lasted about 5-8 seconds... HMMM..
what kind of build do you have?
June 02, 2011, 11:58:46 PM
Well for some reason, I'm still getting connection errors every 15-45 seconds are so... Anything I should check out on my router? Don't get this problem for deepbit though.
Are you working on an extremely fast single worker? I have 10 cards running at ~400 MH each, and my last idle was 9 minutes ago (and lasted ~3 seconds), and it was due to submitting two shares of work (so no work left in queue) within a 2 second window.
Try pinging the server, see what kind of results you get. If you're using phoenix, the problem will normally go away completely by adding -q 3 to your command arguments.
The connection errors seem to have died down. Looks good for now.
I'm using poclbm with 6 workers @ ~350MH/s and 1 worker @ ~400MH/s
Thanks for keeping up to date with your pool and the thread.
-edit-
connection error which lasted about 5-8 seconds... HMMM..
-edit
Ping statistics for 69.42.217.226:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 38ms, Average = 33ms
June 02, 2011, 11:58:29 PM
I am having the same issue. I have 7 cards around each 400 with poclbm and the average ping was 27 ms.
June 02, 2011, 11:54:32 PM
Well for some reason, I'm still getting connection errors every 15-45 seconds are so... Anything I should check out on my router? Don't get this problem for deepbit though.
Are you working on an extremely fast single worker? I have 10 cards running at ~400 MH each, and my last idle was 9 minutes ago (and lasted ~3 seconds), and it was due to submitting two shares of work (so no work left in queue) within a 2 second window.
Try pinging the server, see what kind of results you get. If you're using phoenix, the problem will normally go away completely by adding -q 3 to your command arguments.
June 02, 2011, 11:51:48 PM
Well for some reason, I'm still getting connection errors every 15-45 seconds are so... Anything I should check out on my router? Don't get this problem for deepbit though.
June 02, 2011, 11:48:48 PM
The idle worker issue still hasn't gone away. My pre-maintenance connection had less idle worker connection issues.
June 02, 2011, 11:44:00 PM
I believe the problem with the idles has been corrected, some of the TCP settings changes that were made earlier today did not carry over after power cycling the server for maintenance.
Does that mean the connection errors are expected? I thought I would get excellent connection since I'm located in cali
It means you shouldn't be getting any unusual number of connection problems in the last 10 minutes or so. There are a HUGE number of connections that get opened with the server when working in 500+ GH/sec ranges, and the server configuration was not optimally. It was rejecting connections due to it having characteristics of a denial of service attack.
June 02, 2011, 11:33:57 PM
I believe the problem with the idles has been corrected, some of the TCP settings changes that were made earlier today did not carry over after power cycling the server for maintenance.
Does that mean the connection errors are expected? I thought I would get excellent connection since I'm located in cali
June 02, 2011, 11:32:58 PM
Awesome Eleuthria. I took advantage of the downtime to tweak my overclocks on my cards using solo mining. I've been back on BTCG for the last 20 or 30 minutes, and its running great.
June 02, 2011, 11:29:46 PM
I believe the problem with the idles has been corrected, some of the TCP settings changes that were made earlier today did not carry over after power cycling the server for maintenance.
June 02, 2011, 10:55:41 PM
I'm getting connection errors too. Don't know why.
Did a quick switch over to deepbit. No more connection errors. Is there something up with the pool?
Did a quick switch over to deepbit. No more connection errors. Is there something up with the pool?
June 02, 2011, 10:43:02 PM
I am also getting lots of "miner is idle" and some "unexpected errors" showing up.
June 02, 2011, 10:07:29 PM
I'm getting a lot of connection errors again...any issues still going on?
June 02, 2011, 10:04:15 PM
Please don't change it so that if your worker disconnects frequently or is disconnected at the time the block is solved you get less/none - I don't want to lose out on the shares that I processed before being disconnected!
There are plenty of Share-And-Enjoy pools that forgive flakey workers for leaving before a block is found.
But I'd like to see at least one instance of puddinpop's Winners-Take-All share scheme, because competition is a good thing.
If you subsidize unreliability, and possible pool-hopping, you get more of both. Economics 101.
June 02, 2011, 10:00:27 PM
I know it's been broken a while, but now it's back and working perfectly! Resetting your worker stats will now properly show your worker's statistics since resetting, even if the actual share history has been purged due to age.
I had to Hide the inactive workers at the bottom of my list, to get total hashrate to report correctly. (Even after a reset.)
Thought it was a cache issue for a while, but figured out the problem by comparing mine with a working stat sig.
June 02, 2011, 09:49:05 PM
Thanks for updating the software and keeping such a great place running!
Please don't take people's advice and change it so that if your worker disconnects frequently or is disconnected at the time the block is solved you get less/none - I have a wife, kid, and a shitty internet connection at my place, and any one of those three factors combined with system lockup could cause one or all of my workers to be disconnected for minutes to hours (if I'm sleeping or at work), and I don't want to lose out on the shares that I processed before being disconnected!
Please don't take people's advice and change it so that if your worker disconnects frequently or is disconnected at the time the block is solved you get less/none - I have a wife, kid, and a shitty internet connection at my place, and any one of those three factors combined with system lockup could cause one or all of my workers to be disconnected for minutes to hours (if I'm sleeping or at work), and I don't want to lose out on the shares that I processed before being disconnected!
June 02, 2011, 09:38:33 PM
Anyone know this mysterious person who's ranked number 1 on BTCGuild? This person is generating almost 10% of the bitcoin in each block recently at 580-600 GHash. thats like 58-60 GHash!
June 02, 2011, 09:26:29 PM
I know it's been broken a while, but now it's back and working perfectly! Resetting your worker stats will now properly show your worker's statistics since resetting, even if the actual share history has been purged due to age.
June 02, 2011, 08:27:52 PM
All the display bugs should be fixed now, but post them if something looks very off. We found a block just minutes after coming back online, and it has now been calculated properly.
Reset shares/stales is showing 0 for everybody right now, and this is a known issue. The new pushpool update will allow me to keep track of your reset stats without keeping track of all the previous shares. It should be working properly in the next half hour.
Reset shares/stales is showing 0 for everybody right now, and this is a known issue. The new pushpool update will allow me to keep track of your reset stats without keeping track of all the previous shares. It should be working properly in the next half hour.
Jump to: