any updates with avalon? are they suitable for p2pool?
No
|
|
|
Since profit margins vary wildly depending on how efficiently people have set up their rigs, how much their electricity costs, and how much they expect to make off selling their GPUs, it is fair to say that "the GPU line is being crossed now", it's just that the line is thick and some have crossed, some are crossing, and some have yet to cross it. It's also worth noting that it may be worth mining with GPUs for a relative loss for some period after the line has crossed if you assume that BTC will eventually climb further in value, provided you're willing to hang onto them. How long after is a question no one can answer, but there comes a point where you're earning nothing but dust in terms of absolute BTC and by then it's clear (which is the case for CPUs now).
|
|
|
I'm having trouble getting one of these to work... I'm using cgminer on linux. I'm probably missing something obvious, so any help is appreciated.
cgminer seems to detect it because I can get this (cgminer v. 3.2.0): Started cgminer 3.2.0 No devices detected! Waiting for USB hotplug devices or press q to quit
Pretty sure I'm just being an idiot and missing something obvious, but any help would be appreciated.
What you're missing is that support for this device was broken in 3.2.0... try 3.2.1 or roll back to 3.1.1
|
|
|
Trying version 3.2.1 for a new Asicminer USB with Windows 7 x64, cgminer crashes with segmentation fault when I enable debug output. With debug output turned off it runs for about a minute, but keeps failing with AMU0: Comms error (rerr=-9 amt=0) ...
Version 3.1.1 still remains the most stable release for your hardware, but bear in mind you will need to use zadig to re-associate the device with the ftdi driver instead of WinUSB when you go back to it. 3.2.0 did not work at all for AMU devices so if you're trying the new code, use 3.2.1. 3.2.1a is just a binary built for older versions of ubuntu and no different to 3.2.1. Compiling it yourself will not make it more stable as my builds should be optimal - the only advantage to building yourself is you can build a stripped down version containing support only for the hardware you want to use, and assuming you're on windows, compiling it is FAR from trivial. Version 3.1.1 worked fine, but I went ahead and compiled it anyway out of interest. The segfault is from libpdcurses when writing applog(LOG_NOTICE, "Probing for an alive pool"); It might be specific to windows. I left a stacktrace on http://pastebin.com/5eMb5dsfAbout having seperate threads - I agree it doesn't make sense to start new ones if it means you have to monitor them all. A bug tracker may be easier to work with than forum threads though. Thanks. There's a pdcurses bug where it crashes if ap is null. ncurses on linux does not have this problem. Should be fixed in the next version. Disabling the curses interface will avoid it (-T)
|
|
|
GPU-README
See: Q: I upgraded cgminer version and my hashrate suddenly dropped!
|
|
|
What do other people think about having multiple forum threads?
FWIW, I would say just stick with this one thread and update the OP with a link to the latest notes ITT. Seeing a thread with 545 pages commands a certain degree of respect and gravitas, with respect to this project. Afraid making a post for each release would fragment things further. Thanks, that's precisely what I do. The top thread always points to the announce for the latest release, and I do go to great pains to write human readable changelogs so people can see what has changed, but that does not give the full history. I certainly don't have the time to maintain a wiki.
|
|
|
My prediction: You will find that GPU mining will be profitable on alt currencies for a little while longer beyond it being unprofitable to mine BTC, but eventually the altcoins will reach parity with GPU mining on BTC. The altcurrencies think they're immune to the effect of ASICs, but in fact they are on a course of delayed parity with bitcoin mining as far as I can see. While there's a growing demand for cryptocurrency usage, there's not enough to sustain many of them...
Nice thing about GPUs, though, you can always sell them.
|
|
|
Yeah I'm using cgminer 3.1.1 I didn't upgrade to 3.2 as it has no improvements for gpus... what is the correct format for cgminer 3.1.1? I'd like to persist with 3.1.1 as "if it aint broke don't fix it" so to speak.... would the format be 0:1? or 0,1?
Thanks for your help.
-d 0 -d 1 --remove-disabled but note that you cannot save device settings to a configuration file with the old format, hence why the new one has a new format. While there are no GPU specific changes in the newer versions, there are other generic bugfixes, and the "breakage" is only with new drivers, so GPU users should actually be the safest ones to upgrade.
|
|
|
Not quite, there is no module requirement if you are mining with cgminer 3.2.1+ as it uses direct usb communication and will unload that module you just recommended.
Oh, thanks. Is there a reason for using direct USB communication? More efficient? Yes, to bypass one layer between cgminer and the device, and give us more control over it. It has allowed us to shave a lot of CPU off by doing so. It is unfortunately a lot more work, and keeps revealing to us interesting hardware limitations that the drivers paper over, but that is often the case that the better solution takes more effort.
|
|
|
This thread is hard to follow - so apologies if this is already posted. Maybe there should be a new one per release?
That almost makes sense. I was tempted to make a new thread every major or minor release update (The version numbers are Major:Minor:Micro 3.2.1 being a micro update and 3.2.0 being a minor update). However that would just mean I'd have to monitor and respond on multiple forum threads. Having all the discussion in one place, even if it is only historically organised, means at least everyone knows where to look or ask for help. As an aside, major version upgrades are reserved for major hardware support changes (eg going to 3 for ASICs), minor version upgrades are for major internal software changes (eg changes to driver design, new features such as stratum etc) and micro version updates are for mostly bugfixes to stabilise a minor release branch. What do other people think about having multiple forum threads?
|
|
|
Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash). It looks there are more HW errors, but I'm not 100% sure.
The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code). OK, thanks for explanation. I'm sending you "Avalon" tip . Much appreciated, thanks
|
|
|
Finally got mine! AMU 0: | 334.7M/328.5Mh/s | A:45 R:0 HW:1 U:5.44/m It's actively cooled, and alone on a USB hub with two power sources. So I doubt you can do better regarding HW errors (unless the heatsink is really bad?). Linux users with their own kernel setup should compile/load the cp210x kernel module. Not quite, there is no module requirement if you are mining with cgminer 3.2.1+ as it uses direct usb communication and will unload that module you just recommended.
|
|
|
That version of cgminer is also ancient... I don't even remember when I added scrypt support to cgminer to mine LTC but it has had a billion bugfixes since then.
|
|
|
No way, the 3770 cpu is faster than a hd 400 gpu? I thought the worst gpu kills the best cpu. Oh well I stopped the hd 4000. I finally got some lancelots and didn't want to shorten the 3770s life.
Heh, now you know better... The worst AMD GPU is better than the best CPU. The same is not true for intel GPUs, or even Nvidia (to a lesser extent with the 210 for example). Intel GPUs are a token gesture with adequate graphics for most normal people; they are hopeless for any high performance application, including opencl.
|
|
|
hey guys
I have 3 gpus in my system 1 apu and 2 dedicated gpus, how can i startup cgminer with the third gpu (gpu 2) turned off? I tried setting intensity to 0 but that doesn't work.
Do I specify it via the -d switch? If so what is the syntax?
Thanks
-d 0-1 --remove-disabled I added that to my bat file and i get "invalid device number" fyi: GPU 0 = 6950 GPU 1 = 5770 GPU 2 = APU Thanks for your help What is the output of 'cgminer -n' ? [2013-06-08 11:52:52] CL Platform 0 vendor: Advanced Micro Devices, Inc. [2013-06-08 11:52:52] CL Platform 0 name: AMD Accelerated Parallel Processing [2013-06-08 11:52:52] CL Platform 0 version: OpenCL 1.2 AMD-APP (938.2) [2013-06-08 11:52:52] Platform 0 devices: 3 [2013-06-08 11:52:52] 0 Cayman [2013-06-08 11:52:52] 1 Juniper [2013-06-08 11:52:52] 2 Scrapper [2013-06-08 11:52:52] GPU 0 AMD Radeon HD 6900 Series hardware monitoring enabled [2013-06-08 11:52:52] GPU 1 ATI Radeon HD 5700 Series hardware monitoring enabled [2013-06-08 11:52:52] GPU 2 AMD Radeon HD 7480D hardware monitoring enabled [2013-06-08 11:52:52] Failed to ADL_Overdrive5_FanSpeedInfo_Get [2013-06-08 11:52:52] 3 GPU devices max detected [2013-06-08 11:52:52] USB all: found 8 devices - listing known devices [2013-06-08 11:52:52] No known USB devices Also I'm using worksize of 128, would it better for me to use 256? Or is 256 only good for 7XXX series amd gpus? All looks fine. However, if it says invalid device number I'm betting you're using an older version of cgminer and it's not accepting device in that format. Upgrade.
|
|
|
Somehow my Jalapeno hashrate dropped from 5.75GH/s to about 5.55GH/s. snip
I don't know but when I first got mine it worked at 6GH for a couple of days and then spontaneously "dropped a gear" after a move and reconnect and it's been 5.7GH ever since. I've never been able to regain that .3 either
|
|
|
This thread is hard to follow - so apologies if this is already posted. Maybe there should be a new one per release?
Trying version 3.2.1 for a new Asicminer USB with Windows 7 x64, cgminer crashes with segmentation fault when I enable debug output. With debug output turned off it runs for about a minute, but keeps failing with AMU0: Comms error (rerr=-9 amt=0)
With version 3.2.0 it kept failing with ""AMU: cgid 0 SetBaud got err 4". I saw something about version 3.2.1a but that seems to be for Ubuntu? If it would help to send a stack trace are there debug symbols for the windows release about?
Next steps are to try another machine, and maybe try and compile from GIT if there aren't too many dependencies.
Version 3.1.1 still remains the most stable release for your hardware, but bear in mind you will need to use zadig to re-associate the device with the ftdi driver instead of WinUSB when you go back to it. 3.2.0 did not work at all for AMU devices so if you're trying the new code, use 3.2.1. 3.2.1a is just a binary built for older versions of ubuntu and no different to 3.2.1. Compiling it yourself will not make it more stable as my builds should be optimal - the only advantage to building yourself is you can build a stripped down version containing support only for the hardware you want to use, and assuming you're on windows, compiling it is FAR from trivial.
|
|
|
Just tried the 3.2.1 version on Windows 7. It seems to have the same problem I have seen in the past. It opens a command line window for about 200 milliseconds and then closes.
Short cut command used was C:\cgminer\cgminer3.2.1\cgminer-nogpu.exe -o stratum.btcguild.com:3333 -u XXXXXX_2 -p 123 --icarus-options 115200:1:1 --icarus-timing 3.0=100 -S //./COM3
This command works well in version 3.1.1. It also does not work in 3.2.0
I'm happily hashing with 3.1.1
New version does not take -S parameter all, and will also not need icarus options or icarus timing set since it knows the devices, so get rid of "--icarus-options 115200:1:1 --icarus-timing 3.0=100 -S //./COM3"
|
|
|
Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash). It looks there are more HW errors, but I'm not 100% sure.
The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).
|
|
|
hey guys
I have 3 gpus in my system 1 apu and 2 dedicated gpus, how can i startup cgminer with the third gpu (gpu 2) turned off? I tried setting intensity to 0 but that doesn't work.
Do I specify it via the -d switch? If so what is the syntax?
Thanks
-d 0-1 --remove-disabled I added that to my bat file and i get "invalid device number" fyi: GPU 0 = 6950 GPU 1 = 5770 GPU 2 = APU Thanks for your help What is the output of 'cgminer -n' ?
|
|
|
|