..the big players have to come back! 
Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 195. (Read 837101 times)
June 20, 2013, 07:23:25 AM
Duration: 15:53 ..the big players have to come back!
..the big players have to come back! June 20, 2013, 02:50:33 AM
Great job at staying on top of the issues here, Doc. Truly impressed at how swiftly and efficiently they're being resolved.
The pool has lost half of its hashrate and has several thousand workers less than a week ago. June 20, 2013, 12:24:22 AM
Great job at staying on top of the issues here, Doc. Truly impressed at how swiftly and efficiently they're being resolved.
June 19, 2013, 10:10:56 PM
Heya, instead of explaining what's going on on my end i'll attach a screeny- my miners are showing that I'm mining but the stats are all screwed up. maybe just me or is the pool and/or site down? since my miners seem to be working i'd assume that the pool is fine and the site is just being weird
EDIT: turns out it was just firefox being bitchy that caused the pic below to not show stats where it should- so for future reference it could be a browser thing if this is happening for others- just shut down the browser and reopen
EDIT: turns out it was just firefox being bitchy that caused the pic below to not show stats where it should- so for future reference it could be a browser thing if this is happening for others- just shut down the browser and reopen
June 19, 2013, 06:08:28 PM
One other question about some odd behavior. I don't know if this is tied to the DDoS attacks but I'll ask anyway. In my worker list page previously it would show all my workers, with a rough hash rate. These days some workers seem to "go offline" on the worker page for several minutes at a time (sometimes 10+ minutes) reporting 0 work, even though I'm looking at the machine hashing away in front of me the whole time reporting shares. I know the hash rate on the site is just an approximation and the numbers reported locally in the bitminter client or cgminer is the accurate figure, but before all my machines would at least show on the site reporting something. These days I get a lot of false positives that a worker has gone offline (checking it over several minutes on the site, it still reports zero) but when I walk over to the machine it's sitting there happily crunching away. Any ideas what's causing this? I can assume the shares are still being accepted/counted by bit minter. I guess this is something that would be mitigated by implementing the long awaited "idle worker" notification.
June 19, 2013, 05:34:08 PM
note that antivirus and firewall packages sometimes cause the download to stall towards the end. Notorious for this are AVG and McAfee.
I haven't tried putting files manually into the java cache, but you can give it a try.
However, being able to download with wget but not with java is indicative of the antivirus/firewall issue I mention above.
There's a few troubleshooting pointers here: http://www.reddit.com/r/bitminter/comments/1c8oiq/troubleshooting_bitminter_client_startup_problems/
June 19, 2013, 05:32:00 PM
Any way to set the default worker display back to 10? Trying to sort which machine is/isn't running is a pain now clicking around pages... All my machines are up and down throughout the day and tracking down which one is toast is a pain with multiple pages. I can't imaging too many users are over 10 workers. It wasn't taking up too much space before. Just a request.... 8-)
June 19, 2013, 05:07:46 PM
Ah, I see. Any way to change the number of workers displayed to a user pref? I have 10 machines total and like to be able to see them all at once... Besides that everything seem to be working fine.
Maybe in the future. All the various tables will be reworked with options for filtering etc.
at a slow Internet connection it is not possible to download and/or start bitminter client 
I am now somewhere with a laptop and 15 kB/s and (re-)tried till now ~20 times and it always stopped @~90%
is there another site (e.g. ftp) to download?
I am now somewhere with a laptop and 15 kB/s and (re-)tried till now ~20 times and it always stopped @~90%
is there another site (e.g. ftp) to download?
Unfortunately not. In the future there will be an alternative distribution method, but it's low priority right now.
Note that antivirus and firewall packages sometimes cause the download to stall towards the end. Notorious for this are AVG and McAfee.
ok now I have got http://bitminter.com/client/scala-library.jar
with wget
but where to put it in?
in /home/xxx/.java/deployment/cache/6.0/15?
TIA
with wget
but where to put it in?
in /home/xxx/.java/deployment/cache/6.0/15?
TIA
I haven't tried putting files manually into the java cache, but you can give it a try.
However, being able to download with wget but not with java is indicative of the antivirus/firewall issue I mention above.
There's a few troubleshooting pointers here: http://www.reddit.com/r/bitminter/comments/1c8oiq/troubleshooting_bitminter_client_startup_problems/
June 19, 2013, 05:02:46 PM
What can you tell us about the DDoS and what changes you have made to mitigate the effects? Don't give away any secrets here, but I'm interested.
Many attacks daily that come and go are very disruptive. Probably worse for miners than being completely down, as workers set up with backup pools would jump back and forth. If I had let this go on BitMinter would be completely destroyed. I considered shutting down the pool for a while, but decided against it as BitMinter client still doesn't have backup pool support, some use other miners without backup pool support, and some use a mining client with backup pool support but simply have not set up backups. It would have left many users out in the cold.
The nature of the attack is to send an enormous amount of traffic to the server. As its network connection gets overloaded it becomes unable to communicate. I received many suggestions to install a firewall. Unfortunately one of the difficult things with such attacks is that by the time the traffic reaches your server it is already too late. It must be handled upstream.
I have decided to go with Black Lotus for anti DDoS protection. These guys are expensive, but they are good at what they do. Hopefully this can help ensure a stable service. I also have other ideas to make the service more DDoS resistant, but they will take some time to implement.
There were some hickups while moving servers today. Also the BitMinter software was not prepared for the changes in infrastructure that are happening. I make adjustments as we go. I don't know if we are out of the woods yet, but things are certainly looking a lot better than they did earlier today.
Thanks for all the messages in support of BitMinter, suggestions on how to combat this issue, etc. Much appreciated.
June 19, 2013, 04:58:45 PM
ok now I have got http://bitminter.com/client/scala-library.jar
with wget
but where to put it in?
in /home/xxx/.java/deployment/cache/6.0/15?
TIA
with wget
but where to put it in?
in /home/xxx/.java/deployment/cache/6.0/15?
TIA
June 19, 2013, 04:20:40 PM
Ok, that clears up some of the mystery here. What about the workers that are no longer listed on my workers page? Do I need to re-enter this information? Also for the one machine that I use with cgminer do I need to change any settings? (It's currently on a backup pool but I would like to return to bitminter with it as it's my most powerful box)
The rest of the mystery: There's been a few small changes on the website. On the worker page there are now pagination buttons at the bottom. You'll need to use those to see the rest of your workers.
Also there's a new iOS (iPhone, iPad, etc.) app for BitMinter called BTC Miner, you'll find that in the "tools" -> "third party apps" menu.
Ah, I see. Any way to change the number of workers displayed to a user pref? I have 10 machines total and like to be able to see them all at once... Besides that everything seem to be working fine.
What can you tell us about the DDoS and what changes you have made to mitigate the effects? Don't give away any secrets here, but I'm interested.
June 19, 2013, 04:18:58 PM
at a slow Internet connection it is not possible to download and/or start bitminter client
I am now somewhere with a laptop and 15 kB/s and (re-)tried till now ~20 times and it always stopped @~90%
is there another site (e.g. ftp) to download?
edit:
I am now somewhere with a laptop and 15 kB/s and (re-)tried till now ~20 times and it always stopped @~90%
is there another site (e.g. ftp) to download?
edit:
Code:
com.sun.deploy.net.FailedDownloadException: Ressource konnte nicht geladen werden: http://bitminter.com/client/scala-library.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Code:
java.io.EOFException
at java.util.zip.ZipInputStream.readFully(ZipInputStream.java:426)
at java.util.zip.ZipInputStream.readLOC(ZipInputStream.java:295)
at java.util.zip.ZipInputStream.getNextEntry(ZipInputStream.java:121)
at com.sun.deploy.net.HttpDownloadHelper.decompressWrite(Unknown Source)
at com.sun.deploy.net.HttpDownloadHelper.download(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
June 19, 2013, 03:40:53 PM
finally!
June 19, 2013, 03:34:03 PM
Holy shahmolians we finally got a block. 
June 19, 2013, 03:15:44 PM
The iphone version is attempting to validate against slushs pool. The app needs to be updated to verify against bitminter.com.
June 19, 2013, 03:04:43 PM
Ok, that clears up some of the mystery here. What about the workers that are no longer listed on my workers page? Do I need to re-enter this information? Also for the one machine that I use with cgminer do I need to change any settings? (It's currently on a backup pool but I would like to return to bitminter with it as it's my most powerful box)
The rest of the mystery: There's been a few small changes on the website. On the worker page there are now pagination buttons at the bottom. You'll need to use those to see the rest of your workers.
Also there's a new iOS (iPhone, iPad, etc.) app for BitMinter called BTC Miner, you'll find that in the "tools" -> "third party apps" menu.
June 19, 2013, 03:02:59 PM
I set TTL (time-to-live) on the DNS entry to just 10 minutes. So after I switched mint.bitminter.com over to point at the new us1.bitminter.com workers should have followed fairly quickly.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
Ok, that clears up some of the mystery here. What about the workers that are no longer listed on my workers page? Do I need to re-enter this information? Also for the one machine that I use with cgminer do I need to change any settings? (It's currently on a backup pool but I would like to return to bitminter with it as it's my most powerful box)
I'm missing some of my workers, too!!
June 19, 2013, 02:53:21 PM
I set TTL (time-to-live) on the DNS entry to just 10 minutes. So after I switched mint.bitminter.com over to point at the new us1.bitminter.com workers should have followed fairly quickly.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
Ok, that clears up some of the mystery here. What about the workers that are no longer listed on my workers page? Do I need to re-enter this information? Also for the one machine that I use with cgminer do I need to change any settings? (It's currently on a backup pool but I would like to return to bitminter with it as it's my most powerful box)
June 19, 2013, 02:45:45 PM
I set TTL (time-to-live) on the DNS entry to just 10 minutes. So after I switched mint.bitminter.com over to point at the new us1.bitminter.com workers should have followed fairly quickly.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
I can guarantee DNS caching will give you headaches for the rest of your days. It may not even be DNS servers, but local home routers which are caching the DNS beyond the TTL. To this day, I have just come to accept that DNS voodoo will leave some people stranded and there's nothing you can do to make it work for everyone.
June 19, 2013, 02:41:54 PM
I set TTL (time-to-live) on the DNS entry to just 10 minutes. So after I switched mint.bitminter.com over to point at the new us1.bitminter.com workers should have followed fairly quickly.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
But still there are 600 getwork/gbt miners and 2 stratum miners at the old server. These don't currently show up with a hashrate at the website. But if you wait 1 minute and reload the page you should see their accepted proofs of work have gone up. Live hashrates are only gathered from one server. Currently anti DDoS and stable mining has priority over fixing this.
BitMinter client specifically sets the java virtual machine to not cache DNS lookups for long. I suspect there are some (broken) DNS servers out there that ignore TTL settings. Maybe they'll cache for 24 hours no matter what TTL is.
Jump to: