Yes, cgminer v3.3.1 the latest, I think?
ckolivas, (or anyone else,) are you suggesting that in the place of the first "-d " and everything after it, I should just enter:
"--usb 0-14 " for 15 Erupters?
Also, I always have a space after the last character, is this a requirement, or just my silliness, now?
I'm suggesting if you have 15 erupters, don't put anything. If you have 20 erupters and only want to use 15 of them, use: --usb :15 No, the space is not needed. |
|
|
|
Hi! I'm running 10 Erupters { 5 @ 2x Vantec 10-port USB Hubs} and running cgminer on Windows Vista just fine. I'm using an HP Pavilion laptop. (For now) My .bat looks exactly like: (Where (()) has been omitted for privacy in this post.) (I am using an independent fan that keeps everything cool just fine, I believe.) - My question/problem is that I have a 3rd Vantec with another 5 Erupters all ready for mining, but cgminer won't start. I do add the following after "-d 9 " in the .bat quote above: -d 10 -d 11 -d 12 -d 13 -d 14 I can only speculate why it won't start, and I am continuing to read through this thread to try to find a solution, but I thought I'd ask straight away, regardless. My speculation is that maybe cgminer can't handle so many Eruptors, maybe it doesn't like all 3 power connections from all the hubs, or maybe the syntax for "-d 10 " has to change for some reason - I really don't know. Any ideas? Help? Thanks! This thread, BTW, is super-awesome!!!!! Still working through it! Which version of cgminer? The syntax for devices changed recently and it would be -d 0-14, although you wouldn't even need to do that since it should just detect all erupters by itself, and -d was really designed for GPU usage. The only reason to pass specific numbers of devices is if you wanted to restrict how many devices it used, and it's better to use the --usb command for that kind of restriction. |
|
|
|
That is using the exp exe files. Same thing with normal 3.3.1
(Hopefully the dll as well). Some read errors like that are harmless and are more likely at startup, provided it goes on to hash at the normal rate. Can you describe exactly what the problem is? |
|
|
|
Having a problem since I switched to using a hub with my BE's.
Any ideas? Using ANKER 9 Port hub USB 3.0
Thanks
icarus devices and usb3 is known broken with 3.3.1 on windows, try the experimental exe and dlls listed above from the upcoming release. |
|
|
|
I tried both the new dll and exe and all 3 instances of erupters did start. But I had erupters falling off and coming back up continuously. Ozco is bouncing up and down and it seems to keep trying bring it back up. I went back to stock 3.3.1 and it failed over to a backup pool and is running stable again.
Also I noticed that the U: went away. I like contrasting the U: and WU: with the variable difficulty to make sure they are in line. I wouldn't like it if U: went away. It doesn't seem that it would make a difference in window realestate.
Sam
Hmm the erupters are going zombie and being hotplugged? That's undesirable behaviour. I'm wondering if the bouncing up and down wasn't sheer coincidence to do with outage time at ozcoin? I will investigate though, somewhere in my infinite hours I have available... Actually WU is just U multiplied by diff within the cgminer code so they will ALWAYS be in line... and U, along with all diff1 calculations, was the source of endless confusion, especially with newer miners. You probably didn't even notice that the Accepted and Rejected are now scaled with difficulty as well. More information is always available via the API for advanced users, but as you have seen by the WU vs U example, fully understanding and parsing most of the displayed information is far from trivial so I'm trying to do away with information that is not useful yet is confusing on the main display. In fact, at larger ASIC hashrates, there is a screen real estate problem. |
|
|
|
|
The higher the risk with the company (the greater the promise, the shorter the alleged delivery time, lack of demonstration of real hardware, the more unknown the company etc..) the greater the potential profit (along with the greater the risk of loss or being outright scammed). At the other extreme, the lower the risk, the less you can make, right down to a point where you may not even pay off the device (eg. asicminer block eruptors).
|
|
|
|
|
That all sounds like a great idea and pretty much what I had in mind. However we're just too busy working on new (and old) drivers for now.
|
|
|
|
I feel like I'm doing something wrong.
I hooked up 3x 3-module units today and my temps seem a bit high. On all 3 of them my Temp2 sits at 60C with the fans running at 3500 RPM. Is this normal? Also what is a normal accepted/HW error ratio?
They changed the temp sensor for B3, it's closer to the chips, should have a hotter readout. As Ytterbium said, 70 is the new 50. You will have trouble keeping them under 60, so don't try to. |
|
|
|
Normal for hotplugged ones to not show on windows also - a workaround for crashes on resizing windows thanks to buggy pdcurses on windows.
Could the display toggle co Mpact mode be modified to reinit the displayed devices manually ? I noticed it did not  The whole display thing was never meant for so many devices since it's from an era of GPU mining. I keep rewriting it over and over again yet windows just likes crashing if you get too fancy with pdcurses. I keep meaning to rewrite it to just delete all the windows and start new ones but too many other things to do all taking my attention... |
|
|
|
Yep, it changed something for me. My third instance always crash's now. I run three instances 5 erupters each. Did you try the dll alone or with the new exe as well? dll alone. Try both then please? Lots of little fixes post 3.3.1 in that exe (in fact close to what 3.3.2 will be, hopefully). |
|
|
|
Yep, it changed something for me. My third instance always crash's now. I run three instances 5 erupters each. Did you try the dll alone or with the new exe as well? |
|
|
|
|
When AMUs disconnect due to USB issues, cgminer reconnects them as a new device if it can.
|
|
|
|
She's alive ! Happily hashing away with your latest under Windows on an Anker 10 port hub ! EDIT: Additionally, deployed this build to another rig hosting 58 sticks, and sometimes, a few sticks lag at startup and the display never gets updated. Eg: CGMiner starts up, and displays AMU0 through AMU51. About 30 seconds after it starts up, I see hotplug messages saying devices up to AMU57 have been found, but the display is not updated to reflect the new devices. Finally, I notice that bank often switches back and forth between difficulty 8 and 16. Is there a way I can tell CGMiner "Don't ever go higher than Difficulty 8" ? EDIT2: On my first 10 port hub, I had AMU8 go ZOMBIE with the green light on solid, and would not respond to a hotplug operation. Had to quit and shutdown CGMiner to get it working again. Also, restarting that one 10 port hub only seems to recognize AMU0 through 5 before AMU6-8 get added to the list as hotplug devices later, and again, the list of devices does not get refreshed to display this Great thanks for feedback. Unfortunately normal for windows to fail to start every single one of them and occasionally hotplug the remainders due to some being slow to initialise. Normal for hotplugged ones to not show on windows also - a workaround for crashes on resizing windows thanks to buggy pdcurses on windows. Difficulty is set by your pool and cgminer has no control over it, use a pool with a more stable variable diff algorithm. |
|
|
|
New dll and new .exe. Should I be seeing anything different if I'm not using AMUs? Cuz my BFL LS is plenty happy.
Nope, all good. Thanks for feedback. |
|
|
|
For windows users who have been fighting with the AMUs on the latest version of cgminer, can you try just dropping in this dll in place of the existing one in your cgminer directory? (Or for that matter, anyone using the latest cgminer on windows, see if this changes anything for you). It's the latest version of libusb. http://ck.kolivas.org/apps/cgminer/temp/libusb-1.0.dllAnd while I'm at it, there are new windows .exes with the latest changes as well in case changing the dll alone isn't enough: http://ck.kolivas.org/apps/cgminer/temp |
|
|
|
For windows users who have been fighting with the AMUs on the latest version of cgminer, can you try just dropping in this dll in place of the existing one in your cgminer directory? (Or for that matter, anyone using the latest cgminer on windows, see if this changes anything for you). It's the latest version of libusb. http://ck.kolivas.org/apps/cgminer/temp/libusb-1.0.dll |
|
|
|
|
I'm back and seriously jetlagged with 1000 emails and 500 snail mails to contend with first, but yes some fixes will make their way into a release soon.
|
|
|
|
|
Actually I missed the part where you wanted to send it to your own bitcoind. I thought it was just the title "block-withholding miner". No you can't redirect your block data, you can just withhold it.
|
|
|
|
ck, please revert 3b2f9ccb or add more checks for avalon. thanks!
eh? |
|
|
|
Is there a way to disable a cross-pool new block detection. I'm using cgminer for different coins where each coin is configured inside separate pool. I didn't find a an option/command to prevent cgminer from detecting new blocks over stratum from a pool which not currently mined.
line 3 or README " Do not use on multiple block chains at the same time!" I know what it is said, but look at the reality: everybody is using cgminer for multiple coins at the same time and cgminer is doing a fine job switching between multiple coins across different block chains. I was asking for some option to isolate one pool from another. Is there such option already? and if it not: would it be so much trouble to put it in? Edit: it is not the same time: first I use one pool, then I switch to another, does't mean the "same time"? Of the existing options ,try --failover-only as it will minimise this effect - it works best with stratum pools. I will NOT be adding more code to support multiple block chains concurrently, nor will I add support for any other mining algorithms (my views on this have been expressed here many times over). |
|
|
|
|
Show Posts
