It looks like the address is resolving to 127.0.0.1 - which is your local machine. It may be that some AV software has blocked the site by adding it to your LMHOSTS file so it resolves to localhost (assuming you are using Windows)? |
|
|
|
...
I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device.
So what did I do wrong? I did not try CGMiner under Linux, but whether or not that works would not change the fact that there was a problem with the Win 7 configuration, and that is the problem I reported.
Can someone just go delete every post related to this moron in this thread ... I answered it with my very first post. https://bitcointalk.org/index.php?topic=28402.msg2960179#msg2960179Quote from: xyzzy099 on August 18, 2013, 10:23:09 PM ...
So which is it? Wrong version? Wrong libusb.dll? You built it yourself and didn't follow the libusb instructions? ... and cgminer will be rock solid on linux also if you do it as per instructions. You were running an old version of cgminer for fucked if I know what reason. So indeed you are a complete fucking waste of time here 3.3.2 came out on the 9th of August that used a replacement fixed libusb ... Actually I was mistaken when I said 3.3.1 was current at that time. I just checked and verified that I had 3.3.2 installed on the Windows machine, if you really even care about this issue. Actually, it looks like the last version I installed - which would be the one I was using when I initially posted - was 3.3.4. |
|
|
|
The only other the "I" could suggest is to try the latest CGMiner.
But I understand that you have a working rig now. So you may not want to fix what is no longer broken for you.
I have not seen this behavior with 3.3.1, .2, .3, .4 and I just updated to 3.4.0 yesterday and have not seen this behavior.
My setup is very similar to what you described, Win7 32 bit, 64 bit since yesterday, 15 BE's on 5/7 Port Rosewill hubs and one Jalapeno.
When changing versions I would recommend rebooting the machine to make sure the new .dll is loaded vs. the old one. But I doubt the usb .dll's would effect this since your on USB 2.0 hubs.
Sam
You're right, I don't want to interrupt a working set-up. I could troubleshoot the issue all the way to the hardware level, if I needed to - I have a nice LeCroy O-Scope with a USB analyzer module at work. Maybe I would have been willing to go that route just to help out the CGMiner project, if I had not been greeted with such animosity by Kano. Well, we didn't manage to figure out what the problem was, but at least we managed to have a civilized conversation about the issue. Thanks for your help. |
|
|
|
The hubs are DLink DUB-H7 7-port hubs, with 5 sticks in each hub with 3A power supplies. It's my understanding that each BE should use 0.5A, so this should provide sufficient overhead for 5 sticks. These hubs are well-known to work well with BEs in groups of 5.
Most importantly though, they work flawlessly when attached to a Linux box running different S/W, so I think blaming the hardware is probably a dead-end.
Yep, I agree. Is it always the same Erupter/USB port. I'm not trying to "blame" your hardware just trying to cover all the bases, in the unlikely event you haven't. How many instances of CGMiner were you running? Were you trying to use any command line options? No it was not always the same erupter or port or hub. It seemed to be completely random. Even the erupters plugged into the 1.2A fast-charge ports had the issue randomly, with the same frequency as the sticks in the normal ports. I was only using one instance of CGMiner, and the only options on the command line were '-G' to avoid using the GPU, and -c to load the correct config file. |
|
|
|
I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device.
That sounds like a hub not supplying enough power. What hub(s) are you using and what is the current and voltage rating of the Power Supplies. Sam The hubs are DLink DUB-H7 7-port hubs, with 5 sticks in each hub with 3A power supplies. It's my understanding that each BE should use 0.5A, so this should provide sufficient overhead for 5 sticks. These hubs are well-known to work well with BEs in groups of 5. Most importantly though, they work flawlessly when attached to a Linux box running different S/W, so I think blaming the hardware is probably a dead-end. |
|
|
|
Wrong. I am not a CGMiner developer. I have no responsibility or interest in personally debugging CGMiner.
Both developers and users are part of the Open Source Software community, users have responsibility to report problems and help ascertain what the cause is, when possible. but he chose to just blindly attack me instead.
He didn't "blindly" attack you, You, gave first offense, now your refusing to take responsibility for it. You want Kano to take responsibility for his offensive post, but why should he when YOU refuse? You failed to quote my whole post - as I said, I was willing to help debug the problem, but was not afforded that opportunity. Exactly HOW did I "give first offense"  I did NOTHING but point out a problem I had. I said NOTHING to offend anyone. I did not know that Kano had some kind of bizarre hatred of [THE MINER THAT DARE NOT SAY ITS NAME IN THIS THREAD]. Clearly Kano read offense into a post that contained NONE. Since you seem to possess the OSS community spirit, maybe you and I could talk about the problem in more detail, so we can identify the part where I did something stupid that resulted in my problem? I installed the Windows binary distribution of CGMiner - 3.3.1, I believe, was the current release at that time. I read the README, and downloaded the Zadig binary linked on page 1, and installed the WinUSB driver for my block erupters, and for my BFL devices. I then (just to be careful) rebooted the PC. All devices appeared to be using the correct WinUSB drivers, so I then started CGMiner. The devices were all recognized, and seemed to function as expected. Over the next few days, however, I found that at least one Block Erupter would stop working after, on average, ~2-3 hours. CGMiner would be constantly printing a communications error with the failed device, and the device itself would have an LED that was fully on constantly. Manually unplugging and re-plugging the device would fix the problem, and CGMiner would autodetect the newly-reinserted device. So what did I do wrong? I did not try CGMiner under Linux, but whether or not that works would not change the fact that there was a problem with the Win 7 configuration, and that is the problem I reported. |
|
|
|
In all fairness, I think even you would have to agree that this trainwreck was created by Kano.
No! You need to take responsibility for your own actions. You started this "trainwreck" with no intentions of finding out what the problem was you were having with the program. This is a community where we all work together to identify and resolve problems. You had no intention of doing that. You just lobbed a hand grenade and got offended by a remark in response you YOUR offensive remark. Grow Up! Wrong. I am not a CGMiner developer. I have no responsibility or interest in personally debugging CGMiner. Especially now, since I no longer even use it. That being said, I thought the developers might want to be aware of the issue, that's why I posted it. I would have been perfectly happy to provide more details to help Kano debug the issue, if he had requested that - but he chose to just blindly attack me instead. |
|
|
|
Yeah, well one mining program uses stupid USB drivers which need so many hoops to be jumped through to get working, if they do at all, for no apparent benefit. The author(s) refuse(s) to accept that changing to the new more difficult and stupid USB drivers was a mistake, and won't go back to the original "just works" way of doing things. That miner also has issues compiling it's OGL kernel, crashing out instantly, unless the correct number of chickens are slaughtered while the moon is in the third quadrant and sacrificed to the SDK gods. The issue is also ignored by the authors, and has been for months upon months.
The other needs one set of USB or GPU drivers installed and everything just works.
I won't say which one is which, but I think anyone reading this has a fair idea..
Pure unadulterated troll. Anyone else want to get in on the act before mods have to come in to clean up this trainwreck you've all created over the last few pages? In all fairness, I think even you would have to agree that this trainwreck was created by Kano. |
|
|
|
So by your own admission, the first part of your post was pretty much useless ...
Now, you can fairly say that that is not a very detailed bug report, and therefore of limited value to the developer. I did not invest any time at all in trying to fix CGMiner, because my goal was just to get my hardware reliably making money ASAP, and I accomplished that.
...
But in case it wasn't obvious, it was not of limited value, it was of no value at all. It works for others who do it correctly and read the READMEs, so your complete lack of any information at all says indeed the first half of your post was completely useless. And the 2nd part of your post is saying to use another miner. OK, it's worse than fail logic, it's a completely pointless post that only tells people to use another miner. ... and to top it off you're filling this thread up with big useless crap posts also ... As I said at the start of this: Go away. I will also point out something that you probably completely missed also ... that your USBs you have bought will never mine the amount of BTC you paid for them. It was of NO value because instead of asking for more detail, you just attacked me irrationally, claiming I was advertising for your 'competition'. I never instructed anyone to use any other miner. I just stated what happened in my case. I used configuration A, and it failed. Then I used configuration B, and it worked 100 %. End of story. |
|
|
|
Trying to run cgminer to mine Litecoin with Kattare pool on an NVIDIA GTX 550 Ti and getting the following error with these BAT file settings:
For Litecoin try cudaMiner: https://bitcointalk.org/index.php?topic=167229.0It's way faster on Nvidia cards. Oh, no - please don't mention a different miner in this thread! Kano will post a 10 paragraph reply accusing you of being a shill who is just advertising for that crapminer you mentioned.  A miner that adds features that CGMiner does not have is not a bad thing. A miner that copies CGMiner and then claims that CGMiner is inferior in every imaginable way is something that Kano does not seem to take lightly. See the difference?  I don't care about the difference. When a user posts a bug report and happens to mention that the problem does not occur with some other mining software, that user does not deserve to be attacked, and the report ignored just because Kano has personal issues with another developer. No. As I stated in the reply before, the logic you presented was complete fail. Something didn't work for you with program A whatever you did wrong. So you ran program Bleargh on another operating system with a different configuration. Even a inept fool should be able to see the logic fail there. Kano, you need to chill out dude. You're a tremendous douche-bag at times. No need for that unless you are applying for a job at Butterfly Labs. Maybe I missed where the OP of the complaint stated that he tried compiling on windows, or compiled CGminer on Linux. Re-reading it a few times I noted the OP had only stated trying the binary release on windows. Not compiling, not an older version, not switching to Linux. What the OP did was shortly after posting a problem that could be A) windows related, B) cgminer software related or C) hardware related the OP posted that switching the OS to Linux, the software to another software that the problem disappeared. As far as I know the OP of the complaint switched hardware too as I am not seeing where the OP had gone to the trouble of reformatting to run Linux. So sure by changing everything but the block erupters I can assure you the problem was not directly the block erupters. But as far as a bug in cgminer I think maybe a little more stringent diagnostic procedure is required to have a guess at that. To be honest I can assure you using less shortcuts on the same testing strategy months before I had issues with CGminer on windows. All timeout related. Even increasing the timeout (Kano did it to try to fix the problem) there was nothing fixing that version. I could have stratum on eclipse or far lower errors on cgminer rolling back to an older version. I did build on windows from kano's git. I did try other things. I finally ordered a Raspberry pi compiled the newest cgminer (at the time) and suddenly the errors went away. Same version I wanted to run on windows just on Linux. Now unfortunately the problem could be A) the computer I used to use, or B) the operating system. Since I could run the previous version without issues without the hardware errors the problem wasn't directly with my hardware. There was a compatibility issue with the timer in windows not being accurate enough. Since I could keep the CGminer version the same on both I could prove that cgminer itself wasn't the issue. If the timeouts had been caused by cgminers lower latency on that version it would apply to the much slower raspberry pi with even lower latency on linux. Now given that level or more of testing I would say maybe the OP had a bug. Given the information posted either the OP didn't test anything or forgot to mention any tests the ran to try to track down the error. Maybe there is a bug. But is the bug with windows, cgminer or the OP's hardware? I can't answer that. No one can off of the information provided. I am sure they are looking for the bug right now. Given a little more information maybe they will know where to look for the bug. To me it seems better to ask what would help them find the bug that was so bothersome. Maybe hold other variables still while changing only one at a time so as to narrow down the possibilities. I have reported bugs here. I have been met with no real hostility by anyone. I just ask how to fix whatever error I was having. I let them know what versions the error hadn't shown up on until. By doing that at least the places to look for the bug is limited to the changes between the last known good version and the current version All this might be applicable, if my goal was to troubleshoot CGMiner. It was not. My goal was to get my mining hardware mining reliably. I tried one configuration, which happened to be a very generic install of the release distribution of CGMiner, and I had problems with that configuration. I then tried a different configuration that worked 100%. I'm done, my problem is solved. I posted the problem that I had experienced here to alert the developers that there might be an issue, because I thought that was the right thing to do. I would think that the information that a generic install of CGMiner appeared to have problems with Block Erupters might be worth knowing to the developers, and the fact that the same Block Erupters worked perfectly in another configuration was just included to demonstrate that there was no hardware problem involved. Now, you can fairly say that that is not a very detailed bug report, and therefore of limited value to the developer. I did not invest any time at all in trying to fix CGMiner, because my goal was just to get my hardware reliably making money ASAP, and I accomplished that. That being said, I could understand if my post was answered with "Well, that's not really enough information for me to determine the problem you were having, and I cannot reproduce this failure, so I can't act on this report." Instead, I was attacked as a SHILL, who was somehow ADVERTISING for a 'competitor'! Does that not seems just a little over the top to you? Maybe it wasn't the best bug report ever written, but I did not deserve the response I got. |
|
|
|
Trying to run cgminer to mine Litecoin with Kattare pool on an NVIDIA GTX 550 Ti and getting the following error with these BAT file settings:
For Litecoin try cudaMiner: https://bitcointalk.org/index.php?topic=167229.0It's way faster on Nvidia cards. Oh, no - please don't mention a different miner in this thread! Kano will post a 10 paragraph reply accusing you of being a shill who is just advertising for that crapminer you mentioned. A miner that adds features that CGMiner does not have is not a bad thing. A miner that copies CGMiner and then claims that CGMiner is inferior in every imaginable way is something that Kano does not seem to take lightly. See the difference? I don't care about the difference. When a user posts a bug report and happens to mention that the problem does not occur with some other mining software, that user does not deserve to be attacked, and the report ignored just because Kano has personal issues with another developer. No. As I stated in the reply before, the logic you presented was complete fail. Something didn't work for you with program A whatever you did wrong. So you ran program Bleargh on another operating system with a different configuration. Even a inept fool should be able to see the logic fail there. It's not clear to me what "logic" you are referring to. I simply reported a problem I had with CGMiner using the official release binaries on Windows 7 x64. I then pointed out that I did not have this problem when NOT using the official release binaries of CGMiner on Windows 7 x64. There was no logical implication, just a report that something that was known to work in a different configuration did NOT work when using the official release binary distribution of CGMiner on Windows7 x64. End of report. The right thing for you to do would be to simply apologize and admit that you flew off the handle because I inadvertently mentioned a topic that apparently is a hot-button for you. I did not intend to bait you, and you will notice that I have refrained, out of courtesy to you, from further mention of that specific topic. |
|
|
|
Trying to run cgminer to mine Litecoin with Kattare pool on an NVIDIA GTX 550 Ti and getting the following error with these BAT file settings:
For Litecoin try cudaMiner: https://bitcointalk.org/index.php?topic=167229.0It's way faster on Nvidia cards. Oh, no - please don't mention a different miner in this thread! Kano will post a 10 paragraph reply accusing you of being a shill who is just advertising for that crapminer you mentioned. A miner that adds features that CGMiner does not have is not a bad thing. A miner that copies CGMiner and then claims that CGMiner is inferior in every imaginable way is something that Kano does not seem to take lightly. See the difference? I don't care about the difference. When a user posts a bug report and happens to mention that the problem does not occur with some other mining software, that user does not deserve to be attacked, and the report ignored just because Kano has personal issues with another developer. |
|
|
|
Trying to run cgminer to mine Litecoin with Kattare pool on an NVIDIA GTX 550 Ti and getting the following error with these BAT file settings:
For Litecoin try cudaMiner: https://bitcointalk.org/index.php?topic=167229.0It's way faster on Nvidia cards. Oh, no - please don't mention a different miner in this thread! Kano will post a 10 paragraph reply accusing you of being a shill who is just advertising for that crapminer you mentioned. |
|
|
|
you guys that are jumping into buying these and other large hash machines should punch some numbers in one of the online calculators. Before the end of the summer the difficulty will be at at least 100 million and over 200 million before years end. The get rich scheme will not happen, on the contrary, some of you will never recover the invested money
some of us are hobbyists....and in this for the long haul..... in 2-3 years when bitcoins are $700-$1000 each... tell me about ROI.... If you just enjoy watching number whizz past on your miner UI, maybe this makes sense for you - but a higher price of Bitcoin in the future is not a justification. Instead of spending BTC80 on a piece of mining hardware that will ultimately produce BTC70 before difficulty renders it useless, you could just as well save the BTC80 to start with, and be + BTC10 in the end. |
|
|
|
I think that your 66% network increase is low short term, high long term. +1 |
|
|
|
Definitely not a bet but just an understanding of math that difficulty increase is not a linear progression and cannot be used for more than 3 months or so regardless of who is shipping what.
I think we all understand the math - and that means we understand that the increase could theoretically get even steeper before it gets less steep. None of us know what will happen for sure. I'm just saying that I think the evidence suggests that a 400GH unit bought at >$8000 in November will probably never ROI. I could be wrong. YMMV. All standard disclaimers apply. |
|
|
|
So you are betting that difficulty is at a point where it will plateau soon? Looking at all the hashpower that appears poised to start mining, I would expect it will be a while before we see that plateau. I would be glad to be wrong about that though.
It'll definitely plateau. Not in 3 months for sure. Maybe in 6 months. Definitely before 12 months. That seems like a reasonable assessment - but it also means a 400GH rig purchased at >$8000 in November 2013 will never ROI, I think. |
|
|
|
Will megabigpower be offering a discount for November orders?
I dont know but no one know and by that time maybe all miners stock might be gone when Aug. order delivery ship out. My intention is not to be rude, but if you don't know, then don't reply. You are just wasting everyone's time, most of all the OP's. The only person who *may* know is Dave. You are right and we dont know anythings then no way Dave will low price in Nov. also bad for Oct. buyers. I don't intend to do presales after the October batch ships. This means we intend to have product in-stock. Prices will probably go up, not down. I was just using the mining calc at thegenesisblock.com - and it claims that my October delivery full kit will never reach ROI if it actually ships in late October, and starts mining November 1: http://mining.thegenesisblock.com/a/281853d744If this is an accurate assessment, how can the price for the same equipment go UP in November? Presale or not, it will never come close to ROI, unless BTC is a lot more than the $120ish it is as I write this. What am I missing here? If you believe that difficulty will be over 1063 MM in Feb then you should not be mining. This graph/calculator is only good at predicting short term difficulty and nothing more as it assumes the rise in difficulty will be linear and never taper off. Feb-14 1063 132 $688 $647 $(1,390) Mar-14 1765 219 $414 $373 $(1,020) Apr-14 2930 364 $250 $209 $(812) May-14 4863 604 $150 $109 $(703) Jun-14 8073 1003 $91 $50 $(653) Jul-14 13401 1665 $55 $14 $(640) Aug-14 22246 2765 $33 $-8 $(648) Sep-14 36928 4589 $20 $-21 $(669) Oct-14 61300 7618 $12 $-29 $(698) So you are betting that difficulty is at a point where it will plateau soon? Looking at all the hashpower that appears poised to start mining, I would expect it will be a while before we see that plateau. I would be glad to be wrong about that though. |
|
|
|
|
Show Posts
