Awesome. My AMU device should arrive soon and I'll just directly try 3.2.0 on my linux box.
If it's not here yet, the official 3.2.0 will almost certainly be out before you get it  |
|
|
|
If cooling them down doesn't help, try again with the next version (3.2.0) - when it comes out soon - and see if that helps, there have been a few big changes, I rewrote a lot of the Icarus driver  (and switched it to direct USB) (and it calls them AMUs in the next version) 2) Next version (3.2.0) you won't need all the -S, current version (3.1.1) does of course Are your changes already in the main git branch or are you still working on them? Master git branch is ready for prime time on linux right now. We're playing to make sure losedows is okay before I release it. |
|
|
|
|
You probably have not changed directories with 'cd' into the directory and are calling cgminer with a pathname instead.
|
|
|
|
|
GPU-README
search for --gpu-memdiff
|
|
|
|
|
As I've said elsewhere, previous versions of cgminer would create garbage hashes without hardware errors if you're mining at high difficulty on scrypt. If the new version produces more hardware errors, it's only because they're all visible now.
|
|
|
|
|
Mining with cgminer? You probably have a crappy USB implementation and it's lagging when cgminer is doing its hotplug check. Try disabling it with --hotplug 0
|
|
|
|
The direct USB code does not really work at all on the MIPS router that is built into the Avalon device itself
Cancel that. Xiangfu set me up with usbmon on his standalone avalon and I was able to track down the problem so direct USB is now working on the avalon itself \o/ |
|
|
|
Hi, All! May be someone can give me advice.
I want to run fans on my gpus minimum at 60% for better vrm cooling. I have following settings in my cgminer.conf:
"auto-fan":true,
"gpu-fan":"60-80,60-80,60-80,60-80",
"temp-target" : "69,69,69,69",
In last days weather is relatively cold, and i have following situation:
1) Before starting cgminer, fans run at 50%.
2) I start cgminer, but fans stay run at 50%.
3) when gpu temperature reaches temp-target, cgminer will change fan speed and after this moment it holds fan speed in defined 60%-80% range.
But if weahter is cold and 50% of fan speed is enough to hold gpu temp under temp-target, cgminer don't touches fan speed at all, and fans run all time at speed that was before starting cgminer.
This is correct behavior?
As i understand, workaround is manually set fan speed 60% before start cgminer, but this is not a good solution...
Thanks for help!
PS: cgminer v3.1.1
Indeed the startup default is 50% and it does not touch fan speeds until temp is close to range It is a "soft" bug. |
|
|
|
What else is running? I have 2 machines with the same setup with 4x7970 with no problems.
I had 2 separate machines - one connected via the LAN and one via wireless same internet connection, and they both did the same thing. I think it has something to do with a connection drop. Does yours do it when your Internet connection pauses/hangs or drops? No. It's been quite a few versions before I had that issue. I removed the libcurl code for stratum in the last cgminer version which fixed quite a few crashes. However I wonder if there's a difference between a simple disconnect and a local IP or routing change. |
|
|
|
|
To be clear, Avalon have offered to send me one in the next shipment if I pay for it, or alternatively send me a small ~6GH module for free. As I wasn't actually looking to buy one, I have at this stage opted for the latter. BFL offered me hardware with no strings attached, and to show them I appreciate the gesture I have ordered a second unit (though we all know what the story is with their hardware delivery at this stage so let's not go there). I am a developer, not an investor and I am, and have always been, unhappy about the idea of forking out almost 10k (now) up front for something in such a volatile market even if it is likely to pay itself off in about a month.
|
|
|
|
I'm planning on using the built in TP-LINK WR703N. It's trivial to flash the unit with new a new .bin file. I'd rethink my plan if there was a substancial performance boost, but it doesn't seem that would be the case.
All that being said, if / when the TP-Link eats it, I'll probably replace it with whatever I have laying around.
It's not that I'm opposed to building my own binaries, just don't see the benefit for the time spent on it.
Performance will be identical because the serial driver is not rate limiting. However reliability may be different, but only time will tell that for sure. |
|
|
|
Will SSH access to a retail TP-Link 703n, or even a (to be delivered Real Soon Now) Avalon help you?
Specifically what I need is an equivalent mips router like the 703n with a kernel that has usbmon support built into it that is attached to a real Avalon via USB so I can monitor the communications that way. |
|
|
|
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.
The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .
Will SSH access to a retail TP-Link 703n, or even a (to be delivered Real Soon Now) Avalon help you? Hi ckolivas, is new code and/or are new avalons able to fully restart the control unit (FPGA)? I'm asking because this would be the real advantage, if not I'd go with the new serial code since a stuck avalon would need a full restart anyway. spiccioli The previous code used the fpga reset command but at some stage the fpga stopped responding to that command. It's hard to know if that was because it reached a point where it needed to be power cycled or the old code was not able to send the command in sync at the right time ever again. I'm hoping that with the new code it will avoid the latter situation but will be unable to do anything about the former. So the answer is: I'm not sure. |
|
|
|
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.
The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .
The second is an even more complete rewrite, built on the avalon-serialdev one with direct USB bypassing the ftdi driver entirely. The avalon does some weird and (not so) wonderful things to emulate running serial at 115200 baud, and the ftdi chip has some serious limitations I never would have known about had I not started poking around (for instance, the driver reads from the device every 1 millisecond because the buffer is so small it easily overflows). The modified code is more efficient and uses a lot less OS-kernel time but the demonstrable CPU usage of cgminer itself looks the same. This code works reliably and solidly... on a linux PC. This code is currently in a git branch called avalon-usbdev .
Now this is where it gets tricky. The direct USB code does not really work at all on the MIPS router that is built into the Avalon device itself. I'm not really sure if it's a libusb limitation, a different implementation or what, but it just does not work, and what does work appears extraordinarily slow. Only installing usbmon onto the device will tell me for sure, and that's not as trivial as I wish it were. We'll see how much time I get in the future to investigate this and whether it's even worth doing or not.
So down to my questions. How many avalon users here wish to be running them via a PC instead of as the standalone device it is? I suspect precious few. How many of you even want to be building your own binaries versus the number downloading the latest firmware? It would be possible to release a new version of cgminer that has both drivers but that will become a maintenance burden long term - and without having an avalon myself, it could end up going to bitrot. I've already made massive improvements to the serial usb based code and would be happy to push that alone into the next cgminer version and Xiangfu should be able to make you all new firmware with it.
I should add the Avalon team have made it clear they will not be providing me with a free Avalon outright to further development. Talks continue on that front...
|
|
|
|
|
So I have completed 3 major rewrites of the avalon driver code to improve it. One was playground for testing things out and never really built, but I'm left with two different rewrites, and a question for existing users.
The first is a complete rewrite of the read/write mechanism using the existing serial usb driver (ftdi) which should be much more robust at staying in sync with results coming in from the device, as well as more accurately picking when the device is misbehaving and hopefully be more reliable at resetting it. This code is currently in a git branch called avalon-serialdev .
The second is an even more complete rewrite, built on the avalon-serialdev one with direct USB bypassing the ftdi driver entirely. The avalon does some weird and (not so) wonderful things to emulate running serial at 115200 baud, and the ftdi chip has some serious limitations I never would have known about had I not started poking around (for instance, the driver reads from the device every 1 millisecond because the buffer is so small it easily overflows). The modified code is more efficient and uses a lot less OS-kernel time but the demonstrable CPU usage of cgminer itself looks the same. This code works reliably and solidly... on a linux PC. This code is currently in a git branch called avalon-usbdev .
Now this is where it gets tricky. The direct USB code does not really work at all on the MIPS router that is built into the Avalon device itself. I'm not really sure if it's a libusb limitation, a different implementation or what, but it just does not work, and what does work appears extraordinarily slow. Only installing usbmon onto the device will tell me for sure, and that's not as trivial as I wish it were. We'll see how much time I get in the future to investigate this and whether it's even worth doing or not.
So down to my questions. How many avalon users here wish to be running them via a PC instead of as the standalone device it is? I suspect precious few. How many of you even want to be building your own binaries versus the number downloading the latest firmware? It would be possible to release a new version of cgminer that has both drivers but that will become a maintenance burden long term - and without having an avalon myself, it could end up going to bitrot. I've already made massive improvements to the serial usb based code and would be happy to push that alone into the next cgminer version and Xiangfu should be able to make you all new firmware with it.
I should add the Avalon team have made it clear they will not be providing me with a free Avalon outright to further development. Talks continue on that front...
|
|
|
|
Windows 7 - 64bit
AMD 13.1 & 13.4 drivers. (And whatever sdk is with those)
Cgminer 3.1.1
What else is running? I have 2 machines with the same setup with 4x7970 with no problems. I suspect this is related to some reconnection or IP change or something along those lines so you need a flaky connection to have a problem. |
|
|
|
Unfortunately, it stopped again with the same error and did not restart. cgminer just hung.  Is there some type of logging I can turn on? I'm quite sure it's just drowning deep in some windows networking code unable to resolve a new address while the old connection is stuck somewhere in the void... Usual debugging is to start with "-D -T --verbose" as well (as it says in the readme), but expect lots of noise spewed out. Not sure it will really help but at least it will identify what the last thing is it tries to do when it hangs. |
|
|
|
ckolivas, I think the debug version of cgminer might me a bit old? It doesn't recognise the option "--scrypt"
Sorry to be a pain in the butt!
I just built it but I guess I missed that. Hang on while I make another. haha thanks Okay, try again. |
|
|
|
ckolivas, I think the debug version of cgminer might me a bit old? It doesn't recognise the option "--scrypt"
Sorry to be a pain in the butt!
I just built it but I guess I missed that. Hang on while I make another. |
|
|
|
Thanks mate, really appreciate it.
I have noticed lately that it doesn't crash any more, cgminer just hangs (Without the cgminer has stopped working window).
Does this mean the debugger won't give you the information you need?
Goddamnit windows. A debug build may behave differently anyway so it's still worth a shot. |
|
|
|
|
Show Posts
