Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 587. (Read 5806015 times)

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,

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.

[...]
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.

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.

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?

Is there a windows binary with bitforce support turned on?

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.

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

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 have two asus 5770's running on stock Ubuntu 11.04.  aticonfig can read the gpu temps just fine, but these stats don't appear in cgminer.  I've tried numerous versions of cgminer, AMD sdk's, all with the same results.  

...
Note that some pool operators don't really like this behavior because it increases pool load during LPs (and thus stales or other pool users) without actually using the pool much. From what I know some pools even ban you if you do this (submit less than some threshold of shares for a given amount of requested work / long polls).

Note that some pool operators don't really like this behavior because it increases pool load during LPs (and thus stales or other pool users) without actually using the pool much. From what I know some pools even ban you if you do this (submit less than some threshold of shares for a given amount of requested work / long polls).

That is not a dumb question at all and in fact you are right in thinking there may be an advantage, but it is complicated.

The reason comes down to what happens at longpoll time. A longpoll occurs when the block on the network has changed. This is the time you are most likely to submit stale shares because you are working on the old block still when the new block is already spreading throughout the network. Furthermore, once the longpoll hits, you have to throw out all work and ask your pool(s) for more work so it is the time you are most likely to have a drop in hashrate while waiting for the new work (this is why the older releases of cgminer used to say waiting for fresh work).

Now because cgminer checks longpolls from *any* pool you are connected to now, it can tell when the block changes on the network often faster than your primary pool finds out because you may be connected to the pool which discovered the block as well. So cgminer then knows to stop working on anything from that old block in anticipation that it will be wasted work. However until your primary pool discovers that the block has changed, you cannot actually get useful work from it. The beauty of longpoll, though, is that it is actually giving cgminer work as well, so you will be getting work from the backup pools to fill in the trough period until your primary pool finds out the block has changed. For this to be useful, though, you do actually have to be happy for the backup pools to get some of your shares over time, and therefore enough shares have to accumulate to eventually give you a payout from them. If you enable the --failover-only option, you lose this benefit because not only will cgminer stop working on the old block before your primary pool discovers the block has changed, but you won't even accept any work your primary pool gives you until then, so it will dip in hashrate for longer.

In my limited ztex knowledge (nelisky wrote that and I don't have one)
The 15y board supported was added with 2.3.6
(It was in 2.3.5 also but best not to use 2.3.5)

But not in 2.3.4 or earlier

[...]
While I am at it, I figured out a SW issue that could be quite relevant for all multi-Single setups driven by cgminer: while I removed the throttling device from the setup for further inspection, the average hashrate of the remaining 4 climbed up noticeably. To double check, I repeatedly run it long enough to exclude variation and this is what I get:
1) running all 5 devices the hashrate for all of them starts at 828 and after running a day the throttling settles at 705 all-time-average, while the properly working ones settle at 790
2) running the 4 proper ones alone, all start at 828 and after the day they are still at ~825

In other words, the throttling one is not just reducing its own hashing power but also those of the proper ones. In my 5-units setup the estimated loss is ~250MH/s.

This could be caused by the communication between PC and Single being frozen during the throttling. From the SW design view there should theoretically be no inter-dependencies, since every device is handled by its own threads. But in practice if the device throttles while communicating to the host and thereby stalls, the related thread will eat its scheduling quantum busy looping the serial port.

Luckily ckolivas is not only cgminer developer but also a Linux scheduler guru, so I'll sort this SW issue out in his thread. Meanwhile I will separate the throttling device from my setup and run it from a different host.

Tl;dr: if you have a multi-BFL Singles setup with one or more throttling units (front LED is blinking now and then) you should consider operating the throttling ones from a different host for a better overall hashrate.

Any1 can tell me haw to use zteX board? i`m getting error -3 in the beggining. i got 15y board.

I have two asus 5770's running on stock Ubuntu 11.04.  aticonfig can read the gpu temps just fine, but these stats don't appear in cgminer.  I've tried numerous versions of cgminer, AMD sdk's, all with the same results.  

...

Anyone have any ideas what's causing this?