|
"Should" be fine. The cgminer code is designed to work with usb1.1 but I don't think anyone's using it on anything less than usb2 at the moment.
|
|
|
|
Under Windows 7 I've used zadig to replace the FTDI driver with the WinUSB driver. When I start cgminer, I get this:
snip
Yes it's a known about problem with slower USB/timeouts on some of the devices. There is a fix for this in the master git development tree, but no official release with it yet unfortunately. Hopefully soon... |
|
|
|
At the Bitcoin 2013 conference, security researcher Dan Kaminsky predicted that the current algorithm will not survive the year.
Time for a different prediction: He's been wrong about bitcoin before, and he'll be wrong again. |
|
|
|
Hello, I wanted to ask cgminer community about "efficiency" parameter. For example: if I have efficiency = 8%, then does this mean that I can potentially find 92%/8% = 11.5 more shares in the same time-frame with proper pool and miner settings? Personally I think this parameter is rather useless, because even if I change share because of new blocks, then probability of finding this new share would either:
1) not change much (if cgminer remembers what hashes he previously computed for previous share).
2) not change at all (if cgminer computation is totally random).
But my friend thinks that we should reduce share difficulty of our pool, so that computations of shares almost never interrupted.
Note: Efficiency parameter is located in pool management [p] -> Information .
Efficiency means nothing any more. It was a metric from the days when getwork was used for providing work and means nothing in the stratum world. I will make sure to get rid of it from the pool information. |
|
|
|
No I have not gotten one yet, nor have we had remote access to one, though I'm pretty sure we (Kano and I) will get ours soon. We have been left totally out of the development loop with BFL, only getting hardware when it's finished. So we can't finalise the driver till the actual hardware is right beside us. Given it took us less than a day with the 5GH miner, it should be the same when we get our singles. Hardware errors are common with ASIC devices of this nature and the aim is usually to clock them to keep them bound to under 1%. |
|
|
|
|
Looks more like a double now.
|
|
|
|
[2013-06-12 09:04:10] Failed to resolve (?wrong URL) us.eclipsemc.com:3333/
[2013-06-12 09:04:10] Failed to resolve (?wrong URL) mint.bitminter.com:3333/
Get rid of the trailing slashes. |
|
|
|
I'm trying to disable two AMU's, out of 4 total, in each CGMiner session.
"-d 0 -d 1 --remove-disabled" in the first session works fine.
"-d 2 -d 3 --remove-disabled" in the second session does not work.
when I run CGMiner-nogpu -n it says "failed to open, err -3"
It appears that you intend for CGMiner to be able to do this and I would like to run two sessions for two different pools.
Thanks,
Sam
The --usb command gives you finer control over this. The --device command only takes one set of values now (-d 0-1 instead of -d 0 -d 1) and only works for usb devices since version 3.2.1, and it is a coarse command. |
|
|
|
Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.
Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.
Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?
At intensity 20 it takes forever for your GPU to return its results, so by the time it has returned them, fast chain changing altcoins are all onto their next block. This also explains why orphans are extremely common with fast block coins and why ultimately, they're crap since such a system provides no extra actual security (or fast confirmations since you can't trust any confirmations), just more chain fights. And why it takes forever? Why with I 13 it does not take forever? What is different? ...you're turning the intensity up meaning your handing the GPU many many times more work. GPUs take work, work on it for a while and return results at the end, they're nothing like CPUs. Going up in intensity you're giving it many many many times more work (it's an exponential function to intensity). |
|
|
|
|
The days of commodity hardware being good at bitcoin mining are over. Don't look to generic hardware any more to make any kind of impact, only dedicated hardware will matter (ignoring altcoins).
|
|
|
|
Maybe it is somewhere here in this thread but there are so many posts that i would not find it in a day, so I will just ask.
Why there is so big difference in rejected ratio in CGMiner mining with intensity 13 and with intensity 20? I am mining DigitalCoin (crypt, 20s block time)
When i mine with I 13 my rejection ratio is ~0.5% @ 540kh/s per card.
When i mine with I 20 my rejection ratio is ~7.5% @ 700kh/s per card.
Why is there so big difference? It is caused by CGMiner, by Pool, by connection, ... ? Is there a way to lower rejection ratio with intensity 20?
At intensity 20 it takes forever for your GPU to return its results, so by the time it has returned them, fast chain changing altcoins are all onto their next block. This also explains why orphans are extremely common with fast block coins and why ultimately, they're crap since such a system provides no extra actual security (or fast confirmations since you can't trust any confirmations), just more chain fights. |
|
|
|
Download zadig which will allow you to associate your devices with the winusb driver to allow cgminer to mine with them: http://ck.kolivas.org/apps/cgminer/zadig/Make sure to only associate your mining device with WinUSB, not any other usb devices. After I do this they become completely undetected. And upgrade to cgminer 3.2.1 I have a Bitforce Single FPGA. Will WinUSB in Zadig auto detect BFL devices without needing to download a driver ? I'm still running an older version of CGMiner that inherently supports the FPGA as I've not gotten around to updating that one rig yet. Zadig is a tool that is used to change drivers. It does not autodetect anything or change anything without you telling it so. Cgminer versions before 3.2 need the FTDI driver, versions after 3.2 need the WinUSB driver. Both need a driver either way. If you are running an older cgminer then you have already installed the FTDI driver. |
|
|
|
The diff for bitcoins should be 18M right now, not 15M still... there was another 20,000GHs added to the network, and no change in DIFF. It just flat-lined at 15M)
The difficulty adjusts every 2,016 blocks. According to Bitcoin Watch we still have 891 to go. As os2sam said: 15605632.68129 | Next Diff in 889 blocks | Estimated Change: 20.3644% in 4d 21h 56m 38s All looks fine to me. |
|
|
|
Maybe you can try disabling hotplug too? --hotplug 0
Still getting these  [2013-06-11 07:58:35] AMU3: Idle for more than 60 seconds, declaring SICK! [2013-06-11 07:58:35] AMU3: Attempting to restart [2013-06-11 07:58:35] AMU4: Idle for more than 60 seconds, declaring SICK! [2013-06-11 07:58:35] AMU4: Attempting to restart [2013-06-11 07:58:35] AMU6: Idle for more than 60 seconds, declaring SICK! [2013-06-11 07:58:35] AMU6: Attempting to restart [2013-06-11 07:58:37] AMU2: Idle for more than 60 seconds, declaring SICK! [2013-06-11 07:58:37] AMU2: Attempting to restart [2013-06-11 07:58:39] AMU0: Idle for more than 60 seconds, declaring SICK! [2013-06-11 07:58:39] AMU0: Attempting to restart [2013-06-11 07:58:41] AMU1: Idle for more than 60 seconds, declaring SICK! [2013-06-11 07:58:41] AMU1: Attempting to restar Thanks for trying it at least. We have a call into libusb on that platform that never returns (which shouldn't happen). We're still investigating... |
|
|
|
I have been trying to run the same setup but with 4 block erupters and i keep getting issues. The block erupters keep being announced as SICK because they wont start, and if i happen to get all four to start somehow, they are running at a fraction of the hashrate they should be.
This happens to me using 3.2.1 on just a normal Ubuntu box. The erupters all connect fine and start hashing, but then they go "SICK" because they haven't produced any work in 60s. A few seconds later, they reconnect and submit shares, this happens over and over, but overall the hash rate is much much lower for each erupter than it should be. They work fine on 3.1.1 however. Maybe you can try disabling hotplug too? --hotplug 0 |
|
|
|
Had the same problem, even with fresh install of Windows. Fresh install, installed 12.8 drivers, crash. Another fresh install, 13.4 drivers, crash. Another fresh install, 12.8 drivers, SDK, crash.  Seems GPU mining is ignored now, developer is like a bitch in heat over USB mining bollocks. Gave up with not getting any answers on here, tried latest BFGMiner with 13.4 and it's working no problems. Thanks. P.S. Try disabling USB hotplug if you're not using USB devices --hotplug 0 |
|
|
|
|
Show Posts
