lano1106
|
|
July 30, 2013, 04:05:02 AM |
|
thanks Kano.
I think that I have spotted the commit you mention:
usbutils/icarus include more locking to usbdev access on June 25th. Almost right after 3.3.1 release date. I guess that it means the next release is coming soon.
I'm now running master-git.
I still have spurious
AMU7: Comms error (werr=-7 amt=0)
that come and leave but so far I have an uptime of half an hour and things feels better.
I'll report back tomorrow how the night went with the git version.
|
BTC: 1ABewnrZgCds7w9RH43NwMHX5Px6ex5uNR
|
|
|
STT
Legendary
Offline
Activity: 4046
Merit: 1447
Catalog Websites
|
|
July 30, 2013, 04:12:44 AM |
|
install win7x64 Just do it
|
█████████████████████████ ████████▀▀████▀▀█▀▀██████ █████▀████▄▄▄▄██████▀████ ███▀███▄████████▄████▀███ ██▀███████████████████▀██ █████████████████████████ █████████████████████████ █████████████████████████ ██▄███████████████▀▀▄▄███ ███▄███▀████████▀███▄████ █████▄████▀▀▀▀████▄██████ ████████▄▄████▄▄█████████ █████████████████████████ | BitList | | █▀▀▀▀ █ █ █ █ █ █ █ █ █ █ █ █▄▄▄▄ | ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ . REAL-TIME DATA TRACKING CURATED BY THE COMMUNITY . ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ | ▀▀▀▀█ █ █ █ █ █ █ █ █ █ █ █ ▄▄▄▄█ | | List #kycfree Websites |
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 30, 2013, 05:05:55 AM Last edit: July 30, 2013, 05:17:52 AM by kano |
|
thanks Kano.
I think that I have spotted the commit you mention:
usbutils/icarus include more locking to usbdev access on June 25th. Almost right after 3.3.1 release date. I guess that it means the next release is coming soon.
I'm now running master-git.
I still have spurious
AMU7: Comms error (werr=-7 amt=0)
that come and leave but so far I have an uptime of half an hour and things feels better.
I'll report back tomorrow how the night went with the git version.
-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git) In your case it was sending work to the device. Basically means it took too long (more than 200ms) to write to the device. This can also be caused by device failure e.g. overheat The code does a device reinitialise then will try again with a new work item. i.e. I try to reset it and see if that fixes it. Edit: ... no temperature sensors ... good design that one
|
|
|
|
lano1106
|
|
July 30, 2013, 05:12:17 AM |
|
-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git) In your case it was sending work to the device. Basically means it took too long (more than 200ms) to write to the device. This can also be caused by device failure e.g. overheat The code does a device reinitialise then will try again with a new work item. i.e. I try to reset it and see if that fixes it.
You definitely made a great job. I still see werr -7 from time to time but git version seems to cope way better with the situation than 3.3.1 did. Everytime I see werr -7, after a few seconds, cgminer fallback in normal mode and all BEs are online and hashing!
|
BTC: 1ABewnrZgCds7w9RH43NwMHX5Px6ex5uNR
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 30, 2013, 05:20:54 AM |
|
-7 is a normal USB timeout (unrelated to the TIMEOUT message I've added in current git) In your case it was sending work to the device. Basically means it took too long (more than 200ms) to write to the device. This can also be caused by device failure e.g. overheat The code does a device reinitialise then will try again with a new work item. i.e. I try to reset it and see if that fixes it.
You definitely made a great job. I still see werr -7 from time to time but git version seems to cope way better with the situation than 3.3.1 did. Everytime I see werr -7, after a few seconds, cgminer fallback in normal mode and all BEs are online and hashing! Thanks - good to know it is getting the desired result.
|
|
|
|
Rugien
Newbie
Offline
Activity: 12
Merit: 0
|
|
July 30, 2013, 05:24:08 PM |
|
Why is it not possible to use socks5 proxy with stratum pool since cgminer 3.1.1? It worked fine with 3.1.0.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 30, 2013, 05:28:08 PM |
|
Why is it not possible to use socks5 proxy with stratum pool since cgminer 3.1.1? It worked fine with 3.1.0.
Check 3.1.1 changelog
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
gyverlb
|
|
July 30, 2013, 06:57:23 PM |
|
I just noticed something a bit odd with cgminer on avalon and p2pool. I compared CPU usage/load between mining on bitminter with stratum and mining on p2pool with stratum. Seemed pretty similar (with the obvious ~10min between Bitcoin blocks vs ~30s between p2pool shares).
With bitminter, cgminer uses ~12% of the CPU on the Avalon, with p2pool it uses ~65%. I forced a fixed difficulty of 64 on p2pool to try to help (the difficulty algorithm makes small changes often which could explain some additional processing) with no measurable effect. The resulting overall load is ~0.9 on p2pool and ~0.2 on Bitminter.
This is not an average with large peaks and low usage between them (that could be linked to new work every ~30s on p2pool), it's constant. Some people have reported Avalon freezes/crashes on p2pool and it might be due to a temperature problem: the poor CPU might not have been tested at a constant 60% usage. Give it an already toasty environment and add high CPU usage -> overheat.
This high CPU usage might point to some inefficiencies. I'm not yet mining full time on p2pool because preliminary results show only ~90% efficiency (which seems to imply a average ~3s latency somewhere). This latency might be a completely different problem though.
Hope it can help someone understand what is going on.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4242
Merit: 1644
Ruu \o/
|
|
July 30, 2013, 07:33:30 PM |
|
The p2pool blockchain data is massive and the power of the wrt703n in the avalon is pitiful. Presumably it's the extra workload of dealing with that that uses a lot more CPU. Also the latency of an Avalon sucks dicks on p2pool, throwing out about 3% of work when the block change is 30s (it used to be much worse at 10s). You can run the Avalon on a regular PC via a USB cable to not have CPU usage problems but that won't fix the latency issues, as it is a major Avalon design flaw. p2pool has improved to work with ASICs, but now the hardware needs to catch up.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Jcw188
|
|
July 30, 2013, 07:33:37 PM |
|
Has running the "gpu max alloc percent" worked for anyone when they were having issues? How do I do it on windows without a .bat file, can I just open a command prompt and type it in? Thanks, I'm looking for why I only get 30 khash with a 6570 no matter the settings I try
|
|
████▄██████████▄ ███▄████████████ ▄███▀ ████ ████ ████ ▀███▄ ███▀████████████ ████▀██████████▀ |
▄██████████▄ ████████████ ███████████▀███▄ ████████████████ ████████████████ ████████████████ ▀███▄███████████ ████████████████ ████▀██████████▀ |
▄██▄█████████▄██▄ ▀████▄█████▄████▀ ▀████▄█▄████▀ ███████████ ▄████▀█████▀████▄ █████████████████ █████████████████ █████████████████ ▀███████████████▀
|
▄███████████████▄ █████████████████ ████▀███▀██████▀ ███████▄█████▀ ████▄▄██████████▄ █▀▀██████▀███████ █▄██████▄███▄████ █████▀███████████ ▀██▀███▀████████▀ |
████▄███████████ ████████████████ ▄███▀███████████ ████████████████ ████████████████ ████████████████ ███████████▄███▀ ████████████ ▀██████████▀ | | | | ████████ ██ ██ ██ ██ ██ ██ ██ ██ | |
██ ██ ██ ██ ██ ██ ██ ██ ████████
| | | | | | . Listed on
| | BINANCE KUCOIN Gate.io | | |
|
|
|
gyverlb
|
|
July 30, 2013, 07:38:42 PM |
|
The p2pool blockchain data is massive and the power of the wrt703n in the avalon is pitiful. Presumably it's the extra workload of dealing with that that uses a lot more CPU. Also the latency of an Avalon sucks dicks on p2pool, throwing out about 3% of work when the block change is 30s (it used to be much worse at 10s). You can run the Avalon on a regular PC via a USB cable to not have CPU usage problems but that won't fix the latency issues, as it is a major Avalon design flaw. p2pool has improved to work with ASICs, but now the hardware needs to catch up.
Thanks I suspected something like this. Time to open this beast and make place for an USB cable :-)
|
|
|
|
bitflank
Newbie
Offline
Activity: 4
Merit: 0
|
|
July 31, 2013, 12:29:32 PM |
|
Hey everyone. I think I'm having some trouble with failsafe, and I can't seem to shake it!
LukeJr over at eligius said that the pool was working properly, so I assume this is on my side.
Yesterday, and last night, Eligius connection was interrupted. It then reassigned difficultly and sat connected instead of rolling over to my failsafe. This doesn't *seem* to be affecting my slush or BTCguild connections, but I have seen it happen when BTCguild is down.
If anyone could give me some insight or maybe some troubleshooting options for making failsafe work. I'd be insanely and infinitely
|
|
|
|
os2sam
Legendary
Offline
Activity: 3583
Merit: 1094
Think for yourself
|
|
July 31, 2013, 12:40:28 PM |
|
Hey everyone. I think I'm having some trouble with failsafe, and I can't seem to shake it!
LukeJr over at eligius said that the pool was working properly, so I assume this is on my side.
Yesterday, and last night, Eligius connection was interrupted. It then reassigned difficultly and sat connected instead of rolling over to my failsafe. This doesn't *seem* to be affecting my slush or BTCguild connections, but I have seen it happen when BTCguild is down.
If anyone could give me some insight or maybe some troubleshooting options for making failsafe work. I'd be insanely and infinitely
Well it's failover not failsafe, I believe. You use it by adding more than one pool to the command line. After the miner starts go to your pool list and verify that they are all alive. I would also switch to each one to verify that it actually works and that you entered everything correctly. Some pools fail in a way that the mining node keeps sending the miner work so the mining software can't detect the outage. I have no idea about Eligius though, so I don't know if that fits or not. Sam
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
ajas
Member
Offline
Activity: 130
Merit: 58
|
|
July 31, 2013, 10:52:51 PM |
|
Occationally the cgminer log says: BAJ 0: max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U: 2.26/m -------------------------------------------------------------------- [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0) [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0) [2013-07-31 23:36:12] BAJ 2 failure, disabling! [2013-07-31 23:36:12] Thread 3 being disabled and my Jalapeno stops working. Can anybody tell me what this (especially the codes err=..., amt=...) mean ? Thanks in advance
|
|
|
|
lano1106
|
|
July 31, 2013, 11:10:11 PM |
|
Occationally the cgminer log says: BAJ 0: max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U: 2.26/m -------------------------------------------------------------------- [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0) [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0) [2013-07-31 23:36:12] BAJ 2 failure, disabling! [2013-07-31 23:36:12] Thread 3 being disabled and my Jalapeno stops working. Can anybody tell me what this (especially the codes err=..., amt=...) mean ? Thanks in advance amt = amount (I think...). Possibly if i/o op partially succeeded. Tells you the amount of bytes that were transfered., Personally I have never seen anything else than 0 err = error code. This is specific to the function called. depending on the trace err is werr or rerr to indicate if the error happened on read or write For instance error returned for doing i/o with a USB device usually maps with libusb error codes that can be found at /usr/include/libusb-1.0/libusb.h ie: LIBUSB_ERROR_TIMEOUT = -7,
|
BTC: 1ABewnrZgCds7w9RH43NwMHX5Px6ex5uNR
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
July 31, 2013, 11:28:47 PM |
|
Occationally the cgminer log says: BAJ 0: max 46C 3.98V | ZOMBIE/941.2Mh/s | A:311 R:0 HW:127 U: 2.26/m -------------------------------------------------------------------- [2013-07-31 23:36:10] BAJ2: GetResults failed (err=-8 amt=0) [2013-07-31 23:36:11] BAJ2: RequestResults failed (err=-4 amt=0) [2013-07-31 23:36:12] BAJ 2 failure, disabling! [2013-07-31 23:36:12] Thread 3 being disabled and my Jalapeno stops working. Can anybody tell me what this (especially the codes err=..., amt=...) mean ? Thanks in advance It means the device disconnected (the second error = -4) My first guess would be a bad or loose USB cable. Second guess would be a bad hub if you are using a USB hub. Also, what version of cgminer is it? (Aside: rerr and werr are in the Icarus driver only - in the BAS driver you see the actual commands GetResults and RequestResults, since there are a lot more different commands on the BASs)
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
August 01, 2013, 05:21:09 AM |
|
I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working. It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen". I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer. Other than that issue, it's working great on my BFL equipment. Thanks!
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 01, 2013, 06:59:38 AM |
|
I'm having an issue (sort of) in Win8x64 with CGMiner 3.3.1. CGMiner stops updating it's stats, and acts like it's frozen. Key commands don't do anything, and if I didn't know otherwise, I'd think it had frozen. It's still using CPU time, using network activity, and my pools keep getting shares, so I know it's working. It happened again today. I checked my miner tonight (~1am on the 1st), and it had frozen ~10:15am on the 31st. So it sat for almost 15 hours acting like it had frozen, but it was running all day. I minimized and opened it again, and now it's working just fine, and even showing the shares that should have been going by when it was "frozen". I'm assuming you're going to say this is a curses issue? I really have no idea I'm not a programmer. Other than that issue, it's working great on my BFL equipment. Thanks! Yes I have seen curses go silly and lose an escape code and start spitting random junk into the window header name even on linux So either it is indeed curses on windows or some command prompt problem. Also note that Ctrl-S will pause the screen and Ctrl-Q unpause it. But just to check - you mean that you didn't stop/restart cgminer, just minimised the window and brought it back up?
|
|
|
|
mruiter
|
|
August 01, 2013, 09:10:01 AM |
|
http://pastie.org/private/qzjzezzghx4ojwyysygfqwon Ubuntu 13.04 the apt-get supplied libusb fails, but libusb-1.0.16-rc10 reports success. I use cgminer 3.1.1 to mine using the serial interface. Newer cgminers typically do not detect AMU or show a hashrate of ~100 MH/s . I will try building cgminer master against this libusb version and report back if i have any success. Thanks, that info is perfect and says exactly what I'd hope it says. For 12.04 the problem for you is almost certainly in the libusb version. I expect (though I'll wait to see before I'm 100% certain) that current git and latest libusb should not get SICK devices, should not hash at ~100MH/s for some devices (instead of ~333MH/s) and should not have regular TIMEOUT errors (a rare few is OK) Detection problems 'might' also be addressed by current git since there is a usb config setup change I've added that may help Though interestingly enough, writing this test code I found a situation where it would actually get out of sync with replies during initialisation, that I'll look into and see if it is related, once the libusb version issue is clarified and resolved. FYI im on 13.04 not 12.04. I just rebuilt cgminer (newest commit bda1e333222e9921be793a1e517d84d4aba88ea5) ./configure command:- LIBUSB_CFLAGS="-I/home/xxx/tmp/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="/home/xxx/tmp/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" ./configure --disable-opencl --disable-adl --enable-bflsc --enable-bitforce --enable-icarus --enable-modminer --enable-ztex --enable-avalon Summary: http://pastie.org/private/5qstv1txipwwddh97ujhmqboth AMUs are running at ~333MH/s.. and they start mining as soon as cgminer starts. Stopped and started a few times to be sure. If the problem is fixed for most linux users by using a specific libusb version AND inclusion of this version of libusb in distro repositories is not in the horizon, i guess cgminer should bundle the working lib. I Also have problems. On my USB there are 10 USB Eruptions en 1 BFL Jap. I pulled the latest again from github, build the latest libusb in the .16 range and build both with a configure pointing to the newly build usblib libs. Result: Same problem, only 4 USB Erups are getting work done just above 100H the rest is going to SICK after a few moment. I am using Raspberry PI model B , Debian Weezy fully updated and github cgminer and latest usblib. The BFL is on one USB port the Eruptors are on the other with 2 hubs every hub beining powered by 5Amps PSU so it's no power issue at all. BFGMiner (using plain serial comms) is working fine with very low hardware error rate. I Guess maybee its another lib that is causing the problem , I read a lot of people on RaspPi 's with the problem and running Debian Wheezy on it. When i used ArchLinux it worked fine. But the kernel watchdog driver is not ok in that distribution and i want is the help itself when i crashes.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
August 01, 2013, 11:03:18 AM |
|
What you are showing there is libusb failing to timeout. That's what the test program will test and show for the version of libusb you use. I've put usbfail.c and the working libusb libusb-1.0.16-rc10.tar.bz2 in my binaries git: https://github.com/kanoi/cgminer-binariesOn linux, To use the working libusb for cgminer instead of the system libusb - First install udev-dev via one of: Fedora: yum install libgudev1Ubuntu derivatives: apt-get install libudev-devArch: it should be installed by default as part of systemd When you are in the cgminer folder: mkdir libusb cd libusb wget -O libusb-1.0.16-rc10.tar.bz2 https://github.com/kanoi/cgminer-binaries/blob/master/libusb-1.0.16-rc10.tar.bz2?raw=true tar -xvf libusb-1.0.16-rc10.tar.bz2 cd libusb-1.0.16-rc10 ./configure make cd .. cd ..
If you have already autogen/configured cgminer, next you want to edit Makefile Search for -I/usr/include/libusb-1.0 change all 3 to make sure it's working to -Ilibusb/libusb-1.0.16-rc10/libusb/Also search for -lusb-1.0 and change both of them to libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev (without the first -l) Then make clean makeand now your cgminer will have been compiled against my specific libusb-1.0.16-rc10 properly N.B. you have to use that version in my git, not the system versions - it would appear a lot if linux distros have a bad libusb
|
|
|
|
|