OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[os2sam]

Code:

 [2012-04-29 13:59:37] LONGPOLL from pool 3 detected new block
 [2012-04-29 13:59:39] LONGPOLL from pool 0 requested work restart

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...

I'd donate a BTC or two for a new management strategy that acted on that info.
Sam

[1714008752]

1714008752

[1714008752]

1714008752

[1714008752]

1714008752

[-ck]

Code:

 [2012-04-29 13:59:37] LONGPOLL from pool 3 detected new block
 [2012-04-29 13:59:39] LONGPOLL from pool 0 requested work restart

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...

I'd donate a BTC or two for a new management strategy that acted on that info.
Sam

It wouldn't be hard to do now, but realistically for hopping to be worthwhile you need to only do it on prop pools for the maximum benefit, know their hashrate and do it for the magic percentage of duration. Then you have to factor in for different payschemes and how long to stay there and where to hop back to and so on... I had no intention of developing and maintaining such a database, which would be very fluid and change day by day. On the other hand if all you wanted was one that would hop to the pool that found the latest block each time, and you plugged in what pools you wanted it to work on, that would be very easy to do.

[os2sam]

Code:

 [2012-04-29 13:59:37] LONGPOLL from pool 3 detected new block
 [2012-04-29 13:59:39] LONGPOLL from pool 0 requested work restart

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...

I'd donate a BTC or two for a new management strategy that acted on that info.
Sam

It wouldn't be hard to do now, but realistically for hopping to be worthwhile you need to only do it on prop pools for the maximum benefit, know their hashrate and do it for the magic percentage of duration. Then you have to factor in for different payschemes and how long to stay there and where to hop back to and so on... I had no intention of developing and maintaining such a database, which would be very fluid and change day by day.

 On the other hand if all you wanted was one that would hop to the pool that found the latest block each time, and you plugged in what pools you wanted it to work on, that would be very easy to do.

That's exactly what came to my mind.  I have no desire to enter the nefarious world of complex pool hopping.  But if my miner always switched the the pool that last found a block, or seems to have, I would always have the confidence I was mining on a active and properly functioning pool.

Several pools have been having problems in recent times where remote servers loose connection to the database and my miner is hashing away happily on a pool that is actually down but doesn't know it.  So when I travel for work I always leave my miner on the pool that has never had this problem, to my knowledge.
Thanks for the thoughts,
Sam

[kano]

Some amazing results tonight with Xiangfu's Icarus mining farm running on a single cgminer instance.

It's 1 cgminer with 91 Icarus hashing away at ~33.75GH/s BUT still only using 3% of the CPU in a 32 bit ubuntu linux!

Here's the main API output reformatted to fit here:

Code:

Date: 07:11:39 29-Apr-2012 UTC-07:00
Computer: cgminer 2.3.6       
Elapsed  MHS av    Found Blocks  Getworks  Accepted  Rejected  Hardware Errors       Utility  
19m 22s  33270.28  0             15091     9132      25        0                     471.46/m 

  Discarded  Stale   Get Failures  Local Work  Remote Failures  Network Blocks  Total MH
  2740       0       1             18262       0                3               38665911.5942

Date: 07:11:39 29-Apr-2012 UTC-07:00
Computer: cgminer 2.3.6       
GPU Count  PGA Count  CPU Count  Pool Count  ADL  ADL in use  Strategy  Log Interval  Device Code  OS
0          91         0          3           N    N           Failover  5             ICA          Linux   

[bombo999]

Is there a windows binary with bitforce support turned on?

[Luke-Jr]

Is there a windows binary with bitforce support turned on?

Pretty sure it should be in all BitFORCE-capable versions (since like 2.2.0); if not, I know it is for BFGMiner.

[Epoch]

In short, what I am observing is: the one throttling device reproducibly reduces the all-time-average hashrate of the non-throttling devices reported by cgminer (Linux, 2.3.5). I am not sure whether this is just a measurement error or if my assumption with the stalling communication thread causing lags sounds reasonable.

Con, you're da Linux scheduler guru. Any ideas? Since you have no Singles at hand (and even more no reliably throttling ones), I'd try to implement and test potential fixes myself if you had some ideas. Or do you have a throttling one, Luke?

Zefir, I cannot reproduce your observations on cgminer 2.3.4, 2.3.5, or 2.3.6 (under Windows 7 64-bit; I realize you are running on Linux so my observations may not be relevant here).

I have created 2 separate clusters of Singles, and have modified 1 unit in each cluster (by swapping in a too-weak fan) such that it throttles after 5-10 minutes of operation. That is, after 5-10 minutes the front LED blinks, the hashrate drops, temperature drops, it recovers, rinse, lather, repeat.

What I have observed after 24 hours of operation is that ALL of the non-throttling Singles in the cluster average 811-813Mhps (the peak sustained rate of each of my Singles as reported by cgminer is 826Mhps). This rate is unaffected by the presence (or absence) of a throttling unit in the same cluster.

My throttling ones average anywhere from 710-760Mhps. The key thing is that whether they throttle or not, it does not affect the hashrates of the others in the same cluster. Again, this has been my experience with cgminer 2.3.4, 2.3.5, and 2.3.6 under Windows 7 64-bit.

[jddebug]

In short, what I am observing is: the one throttling device reproducibly reduces the all-time-average hashrate of the non-throttling devices reported by cgminer (Linux, 2.3.5). I am not sure whether this is just a measurement error or if my assumption with the stalling communication thread causing lags sounds reasonable.

Con, you're da Linux scheduler guru. Any ideas? Since you have no Singles at hand (and even more no reliably throttling ones), I'd try to implement and test potential fixes myself if you had some ideas. Or do you have a throttling one, Luke?

Zefir, I cannot reproduce your observations on cgminer 2.3.4, 2.3.5, or 2.3.6 (under Windows 7 64-bit; I realize you are running on Linux so my observations may not be relevant here).

I have created 2 separate clusters of Singles, and have modified 1 unit in each cluster (by swapping in a too-weak fan) such that it throttles after 5-10 minutes of operation. That is, after 5-10 minutes the front LED blinks, the hashrate drops, temperature drops, it recovers, rinse, lather, repeat.

What I have observed after 24 hours of operation is that ALL of the non-throttling Singles in the cluster average 811-813Mhps (the peak sustained rate of each of my Singles as reported by cgminer is 826Mhps). This rate is unaffected by the presence (or absence) of a throttling unit in the same cluster.

My throttling ones average anywhere from 710-760Mhps. The key thing is that whether they throttle or not, it does not affect the hashrates of the others in the same cluster. Again, this has been my experience with cgminer 2.3.4, 2.3.5, and 2.3.6 under Windows 7 64-bit.

Epoch,

Damn cool that you would take the time and effort to test that. I wanted to but didn't have time right now.

Thanks for verifying whether the problem was reproducible.

Tip sent.

[zefir]

[...]
My throttling ones average anywhere from 710-760Mhps. The key thing is that whether they throttle or not, it does not affect the hashrates of the others in the same cluster. Again, this has been my experience with cgminer 2.3.4, 2.3.5, and 2.3.6 under Windows 7 64-bit.

Thanks Epoch for taking your time!

Yes, I'm running my setup from a Linux machine and did most of the measurements with cgminer-2.3.5. Plus, the same process is driving 3 GPUs worth 1.7GH/s that did not suffer while dealing with the throttling Single. I'm building an OpenWRT router to control the proper working units and leave the throttling one attached to the GPU rig.

Lucky you, you had to force your BFL to throttle

Thanks again. Sent you a coin to at least compensate you for the loss of hashing power during measurement.

[Epoch]

Epoch,

Damn cool that you would take the time and effort to test that. I wanted to but didn't have time right now.

Thanks for verifying whether the problem was reproducible.

Tip sent.

jjdebug: Completely unnecessary, but much appreciated! For better or worse, I've become quite familiar with Single behavior under temperature throttling due to my obsession with finding a 'quiet' solution to the Singles' stock loud fans.  

[Epoch]

Thanks Epoch for taking your time!

Yes, I'm running my setup from a Linux machine and did most of the measurements with cgminer-2.3.5. Plus, the same process is driving 3 GPUs worth 1.7GH/s that did not suffer while dealing with the throttling Single. I'm building an OpenWRT router to control the proper working units and leave the throttling one attached to the GPU rig.

Lucky you, you had to force your BFL to throttle

Thanks again. Sent you a coin to at least compensate you for the loss of hashing power during measurement.

Much appreciated, Zefir! Although I'm sure the temporary loss of hashing power was more than compensated for by gaining a better understanding of the Singles' behavior.

Yes, lucky me ... none of my Singles throttle with the stock fans.  I do have some marginal ones now, since I've swapped in slower fans. Apparently, with BFL's EasyMiner software, users will be able to adjust the clocks and that should help the throttling situation. Although that won't help Linux users such as yourself. 

On the topic of cgminer, I've noticed that 'hot removal' is not handled well. If you remove a Single from a hashing cluster, cgminer quits. It doesn't crash or lock up, but it quits. My workaround is calling cgminer in a batch file with a loop. If it quits, the batch file will just call it again. Not a big deal, but it does interrupt mining for half a minute or so while the next instance initializes.

[zefir]

Much appreciated, Zefir! Although I'm sure the temporary loss of hashing power was more than compensated for by gaining a better understanding of the Singles' behavior.

Yes, lucky me ... none of my Singles throttle with the stock fans.  I do have some marginal ones now, since I've swapped in slower fans. Apparently, with BFL's EasyMiner software, we will be able to adjust the clocks and that should help the throttling situation. Let's hope.

On the topic of cgminer, I've noticed that 'hot removal' is not handled well. If you remove a Single from a hashing cluster, cgminer quits. It doesn't crash or lock up, but it quits. My workaround is calling cgminer in a batch file with a loop. If it quits, the batch file will just call it again. Not a big deal, but it does interrupt mining for half a minute or so while the next instance initializes.

You're always friendly and respectful, just my reference on how people should behave on this forum to make a better community.

As for the Singles in your bedroom: water-cooled ones ahead in the pipeline. Time for you to silently raffle away your old loud ones for 150% resale value

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).

What I noticed as problematic (but this might be a Linux specific thing) is, I added cgminer to the autostart service and it usually worked fine with the GPU setup and assured that system is automatically restarted when a card hangs. With the 5 BFLs attached I see every now and then that only two or three of them are detected immediately after reboot. Re-starting cgminer activates them all again. Kind of bad if you plan to leave your miner unattended for two weeks


Edit: sorry you talked about hot-removal, not hot-plugging. With Linux you do not stop cgminer completely. You just stop the threads dedicated to that BFL. If it was the last/only one, then cgminer stops, but otherwise it just continues with one unit less (though statistics are displayed further, no indication that device is gone). Plugging the unit back will not make it operating again automatically.

[JBDive]

So I'm more or less a noob at all the ins and outs with cards, drivers and SDK's and have tried to follow more or less what is said here and to stick with the basics when setting up and running various miners. I went ahead and updated my drivers today while leaving the SDK at 2.4 and I'm seeing what I think is small decrease in performance. I also updated from 2.3.1 to 2.3.6 and if anything I find it slower but it could be the drivers.

Anyway that's not really my comment or question. I'm more interested in knowing where the I (intensity) setting comes into play. My command line has been all default except for I 9 forever, mainly because somebody else suggested the setting. Since I was playing with things today I thought I would try other intensity levels to see what happens and the difference was HUGE in terms of CPU use. I found that just about any setting 1-10 resulted in the same 50% CPU use I had been seeing and accepting as normal to only 1-5% CPU use by cgminier using I 7. Now what would CPU cycles be higher at 5 or 6 than 7, as well as 8,9,10 I can understand if it's a rising scale? I'm seeing maybe 7Mh/s less with 2.3.6 and Intensity 7 but my CPU is idling while GPU is maybe a touch hotter but overall machine heat is way down due to lower CPU use.

CARD: 5770
GPU/Mem: 975/350
OS: Win7X64
SDK: 2.4
Catalyst: 12.4

[Epoch]

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).

Hmm, I would have thought the autodetect routines for FPGAs are fine in cgminer. My command line for 2 Singles looks something like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6 -S COM7

Notice there is nothing in that command line to tell cgminer that I have a Single, an Icarus, or Ztex. But cgminer detects and starts the Singles on COM6 and COM7 fine.

[-ck]

Is there a windows binary with bitforce support turned on?

Pretty sure it should be in all BitFORCE-capable versions (since like 2.2.0); if not, I know it is for ...

Yes all binaries have it. Peddle not ye wares here.

[bombo999]

cgminer does not seem to detect my connected bfl single ... is there a setting that i'm missing?

[zefir]

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).

Hmm, I would have thought the autodetect routines for FPGAs are fine in cgminer. My command line for 2 Singles looks something like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6 -S COM7

Notice there is nothing in that command line to tell cgminer that I have a Single, an Icarus, or Ztex. But cgminer detects and starts the Singles on COM6 and COM7 fine.

Some senior moment at my side, I guess. This thread became too long but I remember a discussion with xiangfu that due to the way how an Icarus is detected (you have to feed some work and check the resulting share for success) there are corner-cases where it becomes unreliable (like looking for a BFL first can kill its state-machine). That was when the initial Icarus support was planned, and since it works for you it was obviously solved meanwhile.

[kano]

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).

Hmm, I would have thought the autodetect routines for FPGAs are fine in cgminer. My command line for 2 Singles looks something like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6 -S COM7

Notice there is nothing in that command line to tell cgminer that I have a Single, an Icarus, or Ztex. But cgminer detects and starts the Singles on COM6 and COM7 fine.

The detection code is quite straight forward for each FPGA.

If you wish to force it to be specifically BFL or ICA you can e.g. "-S bitforce:COM6" or "-S icarus:COM6"
ZTX detection is completely different so there is no real overlap (you don't specify the ztex devices, it always directly detects them)

It checks for BFL first:
It sends it a command (ZGX) which the BFL replies and is checked for the string "SHA256" in it - part of the reply is also where the "Model" in the API command 'devdetails' comes from

Next it checks for Icarus:
It simply just sends it some work and waits 0.1s for the answer
(I checked the block chain for a low nonce and found Ozcoin block 171874 nonce = (0xa2870100) = 0x000187a2 takes ~0.53ms on Rev3 Icarus to be the lowest nonce in the thousands I got a script to look at until the script bugged out)
This is mandatory for ICA since there is no identification anywhere other than the USB device identification
(which course could be used by other non Icarus devices since it's not unique)

Thus with that code (above) the ordering naturally should be BFL first and ICA 2nd if you don't specify "-S bitforce:COM6" or "-S icarus:COM6"

ZTX is detect third since that was added 3rd (though I might consider moving it up to first since it's very direct how it works and unlikely to ever affect any other device)
You don't specify -S for ZTX

Edit: for auto detection of course ZTX is always auto
ICA doesn't ever do auto
BFL does auto only in linux and only when you specify -S auto - however it has 2 methods:
 1) where it looks in /dev/serial/by-id (which can sometimes only show 1 BFL on some linux versions if you have more than 1 BFL)
 2) by libudev checking the USB Model when libudev is compiled in

[Epoch]

cgminer does not seem to detect my connected bfl single ... is there a setting that i'm missing?

If you are in Windows, your basic command line should look something like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6

The '-S COM6' is the relevant part for your Single. It happens to be COM6 for me, but it will likely be something else for you.

You'll need to open up Device Manager, go to the Ports section, and you should see an entry that looks like 'USB Serial Port (COMx)'. Whatever 'COMx' is in your case, that's what you put into cgminer's '-S COMx' setting. Then your Single should be detected.

edit: I should add that if your COM port is greater than 9, you need to use the 'longhand' form for cgminer. So if, for example, your assigned COM port for your Single was COM12, your command line would need to look like this:

Code:

cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S \\.\COM12

[bombo999]

got it ... thank you very much ... didn't realize you had to disable the gpu to get the bfl to work ... guess i'll have to run two instances ...thanks again