Win 7 would say it was downloading the BFL driver, but it wasn't actually doing something correct with it. I installed the BFL driver and all of the devices received COM numbers. Using -S COM# would only get six devices running in cgminer. I did some searching and found:

New version number signifying the updated BFL hardware support. Non-bfl miners have only bugfixes since 2.4.4.

Human readable changelog:

- Bitforce minirig support - including support for use on p2pool through use of the --bfl-range option, provided you have a new enough minirig that supports the nonce-range feature. By default this feature is disabled because it costs ~1% in hashrate, but given the massive loss of hashes you would otherwise have mining on p2pool, this is worth using. Other miners should leave it disabled.- Huge update to other bitforce device. I've merged all of p_shep's changes into this code (thanks!). These can reenable devices, time out gracefully and mark them sick/overheated and so on. - I've also created my own workaround for the biggest problem with existing bitforce devices - the can now abort work as soon as a longpoll hits which means literally half as much work on average wasted across longpoll than previously, and a much lower reject rate. Note these devices are still inefficient across longpoll since they don't even have the support the minirig devices have - and they never will according to bfl. This means you should never mine with them on p2pool.- Fixed the dynamic GPU intensity behaviour which was getting stuck at -10 on faster GPUs.- Updated API code with lots of changes under the hood courtesy of Kano, and updated miner.php.

Full changelog:

- Fix --benchmark not working since the dynamic addition of pools and poolstats.- Make disabling BFL nonce range support a warning since it has to be explicitlyenabled on the command line now.- miner.php allow renaming table headers- Make bitforce nonce range support a command line option --bfl-range sinceenabling it decrease hashrate by 1%.- Add sanity checking to make sure we don't make sleep_ms less than 0 inbitforce.- The fastest minirig devices need a significantly smaller starting sleep time.- Use a much shorter initial sleep time to account for faster devices and noncerange working, and increase it if nonce range fails to work.- Use nmsleep instead of usleep in bitforce.- Provide a ms based sleep function that uses nanosleep to avoid the inaccuracyof usleep on SMP systems.- delay_time_ms is always set so need not be initialised in bitforce.- Increase bitforce timeout to 10 seconds.- Add more hysteresis and poll ~5 times to allow for timer delays in bitforcedevices.- miner.php allow alternating line colours (off by default)- Display the actual duration of wait when it is greater than the cutoff.- Set nonce to maximum once we determine nonce range support is broken.- Initial wait time is always known so no need to zero it beforehand inbitforce.- No point counting wait time until the work is actually sent to bitforcedevices.- Use string comparison functions instead of explicit comparisons.- Account for wait_ms time when nonce_range is in use on BFL.- Split nonces up into 1/5 chunks when nonce range is supported.- limit clear buffer iterations.- Ad fd check to clear buffer.- miner.php remove incorrect 'DATE' error message- miner.php allow summary header in custom pages- Disable nonce range support in BFL when broken support is detected.- Restart_wait is only called with a ms value so incorporate that into thefunction.- Only try to adjust dev width when curses is built in.- miner.php define custom sum fields as a simple array- Fix off-by-one error in nonce increment in bfl.- Use BE when setting nonce in bitforce nonce range work.- Enable nonce range in the normal init sequence for bfl.- Queue extra work at 2/3 differently depending on whether we're using noncerange or not.- Initially enable support for nonce range support on bfl, splitting nonces upinto 3/4 size and only disable it if it fails on work submit.- Attempt to detect nonce range support in BFL by sending work requring itssupport.- Limit retrying on busy for up to BITFORCE_TIMEOUT_MS- Attempt to initialise while bitforce device returns BUSY.- Extend length of string that can be passed to BFL devices.- Fix signedness warning.- Adjust device width column to be consistent.- Use cgpu-> not gpus[] in watchdog thread.- Add api stats (sleep time)- Timing tweaks Added long and short timeouts, short for detecting throttling,long to give up totally. Reset sleep time when device re-initialised Still checkresults after timeout Back up a larger time if result on first poll.- Add API Notify counter 'Comms Error'- Style police on api.c- Do all logging outside of the bitforce mutex locking to avoid deadlocks.- Remove applog call from bfwrite to prevent grabbing nested mutexes.- Bitforce style changes.- Minor style changes.- Remove needless roundl define.- Made JSON error message verbose.- Fine-tune timing adjustment. Also remove old work_restart timing.- Check for gpu return times of >= 0, not just 0, to fix intensity dropping to-10.- Restart is zeroed in the mining thread so no need to do it inside the bitforcecode.- More improvements to comms. BFL return nothing when throttling, so should notbe considered an error. Instead repeat with a longer delay.- Polling every 10ms there's not much point checking the pthread_cond_timedwaitas it just adds overhead. Simply check the value of work_restart in the bfl mainpolling loop.- Use a pthread conditional that is broadcast whenever work restarts arerequired. Create a generic wait function waiting a specified time on thatconditional that returns if the condition is met or a specified time passed toit has elapsed. Use this to do smarter polling in bitforce to abort work, queuemore work, and check for results to minimise time spent working needlessly.- Add busy time to wait time.- api.c put version up to 1.14- Add tiny delay after writing to BFL Change BFL errors to something more humanreadable Send work busy re-tries after 10ms delay

Alas, it's not like I actually own a minirig, but some generous donating and temporary remote access allowed me to work on the code for it. Note that this was a laptop connected to 2 minirigs, each with 17 devices in it. The silicon quality apparently varies from device to device which is why they're 2 speeds in this example. Note that this machine was generating 50Ghash, with an efficiency over 9000 and the CPU usage was recording 1%.

Alas, it's not like I actually own a minirig, but some generous donating and temporary remote access allowed me to work on the code for it. Note that this was a laptop connected to 2 minirigs, each with 17 devices in it. The silicon quality apparently varies from device to device which is why they're 2 speeds in this example. Note that this machine was generating 50Ghash, with an efficiency over 9000 and the CPU usage was recording 1%.

<sigh>

M

I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!

Alas, it's not like I actually own a minirig, but some generous donating and temporary remote access allowed me to work on the code for it. Note that this was a laptop connected to 2 minirigs, each with 17 devices in it. The silicon quality apparently varies from device to device which is why they're 2 speeds in this example. Note that this machine was generating 50Ghash, with an efficiency over 9000 and the CPU usage was recording 1%.

Thanks for this work Con. You are the best in the business. I have cgminer 2.5.0 running on 14 singles and 3 mini rigs without issue.

Anyone else having a problem of cgminer saying their BFL is over the heat threshold when it's only at 45C and stopping work on it?

Check your configuration file or command line doesn't have temperature parameters for GPU(s), and that zero is being used for the BFL.

I found this too. My config file had 95 set for my two GPUs, then nothing more specified. by default, it should set any remaining devices to 95, but it didn't. I'm thinking it set it to 0. Anyway, I removed the conf. line and it worked fine.

When you unplug a device then plug it back in it enumerates to a different port. Cgminer doesn't scan ports (yet) so it can't work out where it's gone.

For what it's worth, I'm pulling the plug on the power (the laptop that's running cgminer keeps running on batteries). When I restart cgminer, it's still using the same serial ports (specified on the command line with -S).

When you unplug a device then plug it back in it enumerates to a different port. Cgminer doesn't scan ports (yet) so it can't work out where it's gone.

For what it's worth, I'm pulling the plug on the power (the laptop that's running cgminer keeps running on batteries). When I restart cgminer, it's still using the same serial ports (specified on the command line with -S).

When you unplug a device then plug it back in it enumerates to a different port. Cgminer doesn't scan ports (yet) so it can't work out where it's gone.

For what it's worth, I'm pulling the plug on the power (the laptop that's running cgminer keeps running on batteries). When I restart cgminer, it's still using the same serial ports (specified on the command line with -S).

Edit:Yeah, a quick look suggests that a wait between closing and reopening may help.

I'm confused as to why the port would change. My experience with various removable serial ports (USB and otherwise, spanning at least 4 or 5 different device drivers) in Windows is that the enumerate the same consistently so long as they are plugged in the exact same port. IOW, as long as any hubs are connected/initialized in the same order (so that the USB ports are still addressed the same) and the same singles are connected to the same USB ports, the same serial port numbers should be used. Unless something is different about the controller BFL uses, the serial port numbers shouldn't change (Windows would need to think the same controller was plugged into a different port or a different controller was plugged into the same port when that hadn't happened). I could see a mini-rig having a problem with address consistency if the chained hubs get detected in a different order, but I've never seen that happen with built-in ports or single hubs on a desktop or laptop. Am I missing something?

Fair enough. For some reason, I was thinking you were specifically discussing Windows. Either I crossed this conversation with another one in the same thread or I confused the -S designations for Windows vs Linux (I don't own any BFL product to help keep this straight in my head, and I was only trying to help).

I'd like to chime in and say that after upgrading to CGminer 2.5.0, I'm getting an increased number when dividing DW by Q while solo mining. Doing this USED to get me ~ .003 - .006 in BFGminer 2.4.4. Now I'm getting above .01 on 2 different machines, both running Win 7x64. To be honest I'm not even sure doing this math means anything while solo mining, but it's what I've been doing to try and see how much work has been useless, and I can't see it being a good thing. Running 11 singles with a couple odd gpu's in 2 different cmd prompts across 2 machines.

Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught

I'd like to chime in and say that after upgrading to CGminer 2.5.0, I'm getting an increased number when dividing DW by Q while solo mining. Doing this USED to get me ~ .003 - .006 in BFGminer 2.4.4. Now I'm getting above .01 on 2 different machines, both running Win 7x64. To be honest I'm not even sure doing this math means anything while solo mining, but it's what I've been doing to try and see how much work has been useless, and I can't see it being a good thing. Running 11 singles with a couple odd gpu's in 2 different cmd prompts across 2 machines.

Do these numbers actually mean nothing when solo mining or..? I figured I'd post this just in case. Maybe it was for naught

I don't think it means anything. AFAIK, DW is work requests that have been discarded for whatever reason. Work that has not be started, just retrieved from the server then thrown away.