c4n10
|
|
September 21, 2012, 11:11:53 PM |
|
C4n10, is long polling working properly? This looks like LP issue.
Not sure... I have two other miners that are cpu miners running different software and their stale rates are about 1.2% so I'm pretty sure it's not the pool if that's what you are asking... CPU mining is not only most likely the cause but also a complete waste of time. As per the README, it's not supported. I never said the miner in question was a cpu miner. And yes, I know cpu's are pointless for BTC mining. That's why my cpu miners are mining litecoins right now. The one using cgminer, (the one I am having a problem with and the focus of this thread) is a gpu miner.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 21, 2012, 11:53:58 PM |
|
C4n10, is long polling working properly? This looks like LP issue.
Not sure... I have two other miners that are cpu miners running different software and their stale rates are about 1.2% so I'm pretty sure it's not the pool if that's what you are asking... CPU mining is not only most likely the cause but also a complete waste of time. As per the README, it's not supported. I never said the miner in question was a cpu miner. And yes, I know cpu's are pointless for BTC mining. That's why my cpu miners are mining litecoins right now. The one using cgminer, (the one I am having a problem with and the focus of this thread) is a gpu miner. Then you need to provide a lot more information than 'I get high stales' ........... Compare mining on 2 different pools. What does the screen show during an LP? Provide some actual numbers and the pool name from the cgminer screen. GPU? OS? Cgminer version? Is it P2Pool so you may as well expect high rejects? Did you turn on --no-submit-stale? (You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)
|
|
|
|
c4n10
|
|
September 22, 2012, 01:29:00 AM |
|
C4n10, is long polling working properly? This looks like LP issue.
Not sure... I have two other miners that are cpu miners running different software and their stale rates are about 1.2% so I'm pretty sure it's not the pool if that's what you are asking... CPU mining is not only most likely the cause but also a complete waste of time. As per the README, it's not supported. I never said the miner in question was a cpu miner. And yes, I know cpu's are pointless for BTC mining. That's why my cpu miners are mining litecoins right now. The one using cgminer, (the one I am having a problem with and the focus of this thread) is a gpu miner. Then you need to provide a lot more information than 'I get high stales' ........... Compare mining on 2 different pools. What does the screen show during an LP? Provide some actual numbers and the pool name from the cgminer screen. GPU? OS? Cgminer version? Is it P2Pool so you may as well expect high rejects? Did you turn on --no-submit-stale? (You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on) I don't really think I need to compare my mining on two different pools to know that a 10% - 12% stale ratio is high... I also don't see why the pool name is relevant being that my cpu miners in the exact same pool have a stale rate of less than 1.5% but if you insist, I am on OzCoin. During an LP the screen shows what it is supposed to show, it tells me when the long polling has detected a new block, it tells me when a share has been accepted or when a share has been rejected. What numbers would you like me to provide you other than the ratio of stales I am getting? Are there other numbers which would be relevant to the number of stales I am getting? GPU - Geforce gt 520 (yes, I am aware that it is a piece of crap in relation to mining) OS - Windows 7 64-bit cgminer version - 2.7.5 I am not using the --no-submit-stale flag (i'm not using ANY flags actually) and yes, I AM getting stales as opposed to rejects. cgminer specifically says that they are stales ("prevhash submitted" or something along those lines).
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 22, 2012, 01:44:52 AM |
|
... Then you need to provide a lot more information than 'I get high stales' ...........
Compare mining on 2 different pools.
What does the screen show during an LP?
Provide some actual numbers and the pool name from the cgminer screen.
GPU? OS? Cgminer version?
Is it P2Pool so you may as well expect high rejects?
Did you turn on --no-submit-stale? (You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)
I don't really think I need to compare my mining on two different pools to know that a 10% - 12% stale ratio is high... I also don't see why the pool name is relevant being that my cpu miners in the exact same pool have a stale rate of less than 1.5% but if you insist, I am on OzCoin. During an LP the screen shows what it is supposed to show, it tells me when the long polling has detected a new block, it tells me when a share has been accepted or when a share has been rejected. What numbers would you like me to provide you other than the ratio of stales I am getting? Are there other numbers which would be relevant to the number of stales I am getting? GPU - Geforce gt 520 (yes, I am aware that it is a piece of crap in relation to mining) OS - Windows 7 64-bit cgminer version - 2.7.5 I am not using the --no-submit-stale flag (i'm not using ANY flags actually) and yes, I AM getting stales as opposed to rejects. cgminer specifically says that they are stales ("prevhash submitted" or something along those lines). Well according to you everything is as it should be except you get a high number of 'stales' (and I've no idea even when you get these 'stales') If you don't need help and wont supply the info I've requested - then why are you asking (for free help)?
|
|
|
|
c4n10
|
|
September 22, 2012, 02:04:44 AM |
|
... Then you need to provide a lot more information than 'I get high stales' ...........
Compare mining on 2 different pools.
What does the screen show during an LP?
Provide some actual numbers and the pool name from the cgminer screen.
GPU? OS? Cgminer version?
Is it P2Pool so you may as well expect high rejects?
Did you turn on --no-submit-stale? (You don't get stales unless you do that - you get rejects - and rarely should you ever turn that on)
I don't really think I need to compare my mining on two different pools to know that a 10% - 12% stale ratio is high... I also don't see why the pool name is relevant being that my cpu miners in the exact same pool have a stale rate of less than 1.5% but if you insist, I am on OzCoin. During an LP the screen shows what it is supposed to show, it tells me when the long polling has detected a new block, it tells me when a share has been accepted or when a share has been rejected. What numbers would you like me to provide you other than the ratio of stales I am getting? Are there other numbers which would be relevant to the number of stales I am getting? GPU - Geforce gt 520 (yes, I am aware that it is a piece of crap in relation to mining) OS - Windows 7 64-bit cgminer version - 2.7.5 I am not using the --no-submit-stale flag (i'm not using ANY flags actually) and yes, I AM getting stales as opposed to rejects. cgminer specifically says that they are stales ("prevhash submitted" or something along those lines). Well according to you everything is as it should be except you get a high number of 'stales' (and I've no idea even when you get these 'stales') If you don't need help and wont supply the info I've requested - then why are you asking (for free help)? What information did you request that I did not supply other than comparing the mining between two different pools (which is useless because I am 99.99% sure that the problem is not with the pool, otherwise my cpuminers would be affected as well)? I have supplied all the information you asked me for with the exception of the "actual numbers" from the cgminer screen which I asked you for clarification on because I can't provide you with numbers unless I know which numbers you need, especially when I can not find a relative correlation between the other numbers output by the miner and my stale ratio... When do I get the stales...? I get the stales when my miner attempts to submit a solved share and is answered by the server with a message that reads something like: "Stale share detected, submitting as user requested" Then it prints something like: "Rejected crazyblock.numbershere GPU 0 (prevhash-stale)"
|
|
|
|
rocks
Legendary
Offline
Activity: 1153
Merit: 1000
|
|
September 22, 2012, 06:20:00 AM |
|
Change this $ CFLAGS="-O2 -Wall -march=native" ./configure to this. $ CFLAGS="-O2 -Wall -march=native" ./configure --enable-bitforce Thanks Krak, That got it to compile (it might be helpful to add to the FPGA-README file). But cgminer still can not seem to find the bfl single. I've tried both auto-detect and specifiying various /dev/xxx paths, but nothing seems to work. $ ./cgminer -o [pool] -u name -p pw $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0 $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)
All return All devices disabled, cannot mine! 1) In Ubuntu does anyone know how to find the correct /dev/xxx device for a specific single? 2) I have x6500s running on the same machine (with MPBM) perfectly fine, could this be causing a conflict? 3) Is there any way to test the connection to a bfl single to see if the issue is an incorrectly configured miner, connection issue, or a problem with the single itself. Any suggestions would be great, I managed to get a x6500 with no issues, but have not been able to get the single running for some reason. Thanks!
|
|
|
|
Krak
|
|
September 22, 2012, 07:13:13 AM |
|
Thanks Krak, That got it to compile (it might be helpful to add to the FPGA-README file). But cgminer still can not seem to find the bfl single. I've tried both auto-detect and specifiying various /dev/xxx paths, but nothing seems to work. $ ./cgminer -o [pool] -u name -p pw $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0 $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)
All return All devices disabled, cannot mine! 1) In Ubuntu does anyone know how to find the correct /dev/xxx device for a specific single? 2) I have x6500s running on the same machine (with MPBM) perfectly fine, could this be causing a conflict? 3) Is there any way to test the connection to a bfl single to see if the issue is an incorrectly configured miner, connection issue, or a problem with the single itself. Any suggestions would be great, I managed to get a x6500 with no issues, but have not been able to get the single running for some reason. Thanks! According to the readme, you have to use --scan-serial /dev/ttyUSBn (where n is the device ID).
|
BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4256
Merit: 1644
Ruu \o/
|
|
September 22, 2012, 07:15:58 AM |
|
Probably haven't loaded the module for the bitforce devices.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
The00Dustin
|
|
September 22, 2012, 11:41:02 AM |
|
What information did you request that I did not supply other than comparing the mining between two different pools (which is useless because I am 99.99% sure that the problem is not with the pool, otherwise my cpuminers would be affected as well)? FYI, if you are mining LTC wit the CPUs and BTC with the GPU, you are mining on different pools. With the same name (ozcain), and even if they are at the same IP, they are not the same pool, because they are running on different daemons. Also, with a GPU with a hash speed that slow, you aren't going to find a lot of shares, so that rate might not be so high. Trying a different pool will confirm the problem is or isn't with ozcoin. Then, either additional information can be used to find the problem or the GPU can be blamed. Incidentally, if you try another pool and get less rejects, but the same U: (which might take weeks to normalize depending on how low your hashrate is), then these shares being submitted and rejected don't matter. I'm sure the hashrate would be helpful in determining whether or not the higher reject rate is related. When the shares occur might also be, for instance, do you see an LP or new block detected and then rejects, or are they random without LPs or new blocks detected? If the problem is in the software, I'm guessing it's very likely to be related to the fact that you're using an nVidia card, so that information might have been useful much earlier on.
|
|
|
|
rocks
Legendary
Offline
Activity: 1153
Merit: 1000
|
|
September 22, 2012, 07:06:45 PM |
|
According to the readme, you have to use --scan-serial /dev/ttyUSBn (where n is the device ID).
Yes, sorry I had tried /dev/ttyUSBx before as well (just forgot to add it to the list), but it did not work either. $ ./cgminer -o [pool] -u name -p pw $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/ttyUSB0 $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0 $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)
All return All devices disabled, cannot mine! /dev/ttyUSB0 is the right device because it appears and disappears when I plug/unplug the single. But cgminer still does not recognize it. Is there anyway to debug the connection and where the issue is? Ubuntu sees the new USB device when it's plugged in, so I'm not sure where the issue is... Thanks!
|
|
|
|
BitMinerN8
|
|
September 22, 2012, 08:06:36 PM |
|
According to the readme, you have to use --scan-serial /dev/ttyUSBn (where n is the device ID).
Yes, sorry I had tried /dev/ttyUSBx before as well (just forgot to add it to the list), but it did not work either. $ ./cgminer -o [pool] -u name -p pw $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/ttyUSB0 $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/serial/by-id/usb-Butterfly_Labs_Inc._BitFORCE_SHA256-if00-port0 $ ./cgminer -o [pool] -u name -p pw --scan-serial /dev/usbmon0 (or usbmon1/2/3/4/etc)
All return All devices disabled, cannot mine! /dev/ttyUSB0 is the right device because it appears and disappears when I plug/unplug the single. But cgminer still does not recognize it. Is there anyway to debug the connection and where the issue is? Ubuntu sees the new USB device when it's plugged in, so I'm not sure where the issue is... Thanks! I don't know if this will work for you or not, but when I built my Debian box to run all my BFL's I was running into the same type of issue. I am a linux novice but I like to learn and take a lot of notes. I ran across this command on some obscure post on the forums. I don't know exactly what this does, but it worked for me anyway. I eventually added as the last line in the /etc/rc.local file so it would start automatically on boot. Hope it works for you. modprobe ftdi_sio vendor=0x0403 product=0x6014
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 23, 2012, 01:28:07 AM Last edit: September 23, 2012, 10:32:58 PM by kano |
|
... Is there anyway to debug the connection and where the issue is? Ubuntu sees the new USB device when it's plugged in, so I'm not sure where the issue is...
Thanks!
As per the README FAQ that no one ever reads: Q: I'm having an issue. What debugging information should I provide? A: Start cgminer with your regular commands and add -D -T --verbose and provide the full startup output and a summary of your hardware, operating system, ATI driver version and ATI stream version.And the additions I've added recently that are in git: Q: How do I get my BFL/Icarus/Lancelot/Cairnsmore device to auto-recognise? A: On linux, if the /dev/ttyUSB* devices don't automatically appear, the only thing that needs to be done is to load the driver for them: BFL: sudo modprobe ftdi_sio vendor=0x0403 product=0x6014 Icarus: sudo modprobe pl2303 vendor=0x067b product=0x230 Lancelot: sudo modprobe ftdi_sio vendor=0x0403 product=0x6001 Cairnsmore: sudo modprobe ftdi_sio product=0x8350 vendor=0x0403 On windows you must install the pl2303 or ftdi driver required for the device pl2303: http://prolificusa.com/pl-2303hx-drivers/ ftdi: http://www.ftdichip.com/Drivers/VCP.htm
Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but cgminer can't mine on them A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices: sudo ls -las /dev/ttyUSB* will give output like: 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0 This means your account must have the group 'dialout' or root priviledges To permanently give your account the 'dialout' group: sudo usermod -G dialout -a `whoami` Then logout and back in againEdit: yes the above has been fixed
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
September 23, 2012, 02:06:35 AM |
|
Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but cgminer can't mine on them A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices: sudo ls -las /dev/ttyUSB* will give output like: 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0 This means your account must have the group 'dialout' or root priviledges To permanently give your account the 'dialout' group: sudo usermod -G dialout `whoami` Then logout and back in again FYI, this is bad advice and is likely to screw up your system.
|
|
|
|
TheHarbinger
Sr. Member
Offline
Activity: 378
Merit: 250
Why is it so damn hot in here?
|
|
September 23, 2012, 02:09:26 AM |
|
Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but cgminer can't mine on them A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices: sudo ls -las /dev/ttyUSB* will give output like: 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0 This means your account must have the group 'dialout' or root priviledges To permanently give your account the 'dialout' group: sudo usermod -G dialout `whoami` Then logout and back in again FYI, this is bad advice and is likely to screw up your system. Well, no. Adding your current user to the "dialout" group is not going to screw up anything.
|
12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
September 23, 2012, 02:16:22 AM |
|
Q: On linux I can see the /dev/ttyUSB* devices for my ICA/BFL/MMQ FPGA, but cgminer can't mine on them A: Make sure you have the required priviledges to access the /dev/ttyUSB* devices: sudo ls -las /dev/ttyUSB* will give output like: 0 crw-rw---- 1 root dialout 188, 0 2012-09-11 13:49 /dev/ttyUSB0 This means your account must have the group 'dialout' or root priviledges To permanently give your account the 'dialout' group: sudo usermod -G dialout `whoami` Then logout and back in again FYI, this is bad advice and is likely to screw up your system. Well, no. Adding your current user to the "dialout" group is not going to screw up anything. Indeed that wouldn't, but the commands Kano suggests also removes you from every other group. Including sudo. (BFGMiner has suggested almost idential but with the -a option for a few releases now)
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 23, 2012, 02:41:48 AM |
|
...
FYI, this is bad advice and is likely to screw up your system. quoted for lulz Fix in my posts and in the docs - lulz https://github.com/ckolivas/cgminer/pull/312Though I'm wondering if it was the green colour in my post that could cause GPU damage? Edit: Oh and if you did do it as I said without the '-a' then: whoami su - usermod -G adm,admin,cdrom,plugdev,lpadmin,sambashare -a usernameWhere username is the result of 'whoami' That should cover most of what groups you lost. On my Xubu 11.04 the above is the full list.
|
|
|
|
EnergyVampire
|
|
September 23, 2012, 03:18:12 PM |
|
Hello,
I've been testing Windows 8 Consumer Preview but I am having a few issues getting cgminer 2.7.4 working properly.
Main problem: While running cgminer, I get spammed with "New block detected on network before longpoll" ( 1000s of these displaying the same exact time) and the hashrate begin to slowly decrease over time (drops from 550 Mh/s to 350 Mh/s per GPU after about an hour or so).
Minor problem: I am unable to get cgminer running with 5 GPUs, it doesn't even work with "cgminer -n". The OS, catalyst, MSI Afterburner, GPU-Z all recognize the 5 GPUs.
Thanks in advance for your reply.
|
|
|
|
c4n10
|
|
September 23, 2012, 07:03:54 PM |
|
I recently switched to a geforce 9600 gt and I am having a problem using the scrypt algorithm in cgminer or any other miner for that matter. In cgminer everything seems to work fine and then the application seems to hang immediately after "Long-polling activated for http://web.site" and does not progress any further. Please help!
|
|
|
|
c4n10
|
|
September 23, 2012, 08:06:38 PM |
|
Never mind, I'm an idiot. I just needed to wait a few minutes...
|
|
|
|
Fefox
|
|
September 23, 2012, 10:03:01 PM |
|
I have been doing some testing of CGMINER with my BFL Mini Rigs with the Bitminter Pool and noticed that CGMINER was not reporting Hardware Errors or what I think should be showing under HW:
Under the bitminter client I have one board in a Minirig that fails about 1 out of 15 proofs (in the minter client it uses CPU to double-check the work from GPUs and FPGAs and if their work isn't valid, it gets flagged with a BOMB"
on the two minirigs, I tried running two concurrent copies of CGMINER one on a good board and one on the bad board, nothing really stands out between them stats wise, altho the bad does show up slower in the bitminter pool stats.
bad board has a U:18.8 and the good U:20.1 but other boards in the rigs are in that range..
should these errors be showing up under HW: ?
it seems the bad proofs don't get submitted to the pool, so it looks like CGMINER is checking them, finding them bad, throwing them away but forgets to count them.
not sure if this is some type of bug or im just doing something wrong?
btw Ver is 2.7.4
Thanks.
|
|
|
|
|