Thanks, see my post in the p2pool thread. This is more about interpretation of the expire= parameter than anything else.

Actually this is a major problem. If p2pool is rolling ntime and telling the mining software it can roll ntime, there is nothing to guarantee they wont collide. The expire=10 seconds tells the mining software how long it can roll work for, not how far into the future it can roll time. Potentially the software can roll time up to 2 hours into the future within that 10 seconds, so there can be no guarantee the work source and mining software won't clash. If you're asking the mining software to roll time, you shouldn't be rolling it within p2pool, or vice versa. Since p2pool generates its own work locally, I see no point even asking the mining software to roll the time if it's going to roll it itself. Since rolling time requires a lot less CPU than generating fresh work, it really is a matter of where you want the time to be rolled - the source of the work (in this case p2pool) or the mining software. It should not be done at both ends.

Yes. That's the closest they came to "sponsorship" of the work.

Yes I guess you should set scantime to 10 seconds for now. In a future version I'll actually honour what otherwise appears to be a bogus roll expire time if the pool really wants that.

Try dropping intensity by 1 or number of gpu threads by 1. Perhaps you're just over the efficiency/time to search peak.

Expire was added in cgminer 2.4.4

Expire=10 was a bug in much pool software. It did not make sense at all to have that value for anything but p2pool so the scantime is used if it is longer than expire (expire should be more like 120 seconds). This can't be creating duplicates though.

p2pool has a recent bug where duplicate work items are sent out regardless of the mining software. Anyone on p2pool?

Lots going on folks.... There is always more than meets the eye.

sdk 2.1 and amd drivers 12.4 onwards are totally incompatible

That should be pretty clear from the screenshot. Alas I only had access for less than a day.

Early access I don't think so. Timely access, likely. Hardware sponsorship guaranteed they will NOT. However gigavps has taken it almost entirely upon himself to donate as much as BFL themselves probably should have been doing (which is disappointing). His sponsorship has made me care where otherwise I was happy to leave this crap with luke behind forever.

This was me working on 2 minirigs remotely:

Being a windows driver bug, there really is nothing I can do about it apart from suggesting trying a different driver version. I'm surprised you hit this bug so quickly after 2.5.0 though since most people find it hitting after a week of running.

You now have the dubious honour of being the first ever person on this forum I've ignored.

Thanks for the feedback. That was one of the improvements mentioned that I finally got sick of the arguments over and coded up the solution myself. Glad it works for you 

Various catalyst versions introduce different buggy underclocking issues. I believe 12.3 was one of them. Roll back or forwards on catalyst.

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've just released cgminer 2.5.0 which has full minirig and substantially updated single support.

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%.

New Version: 2.5.0 - 6th July 2012

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 pool
stats.
- Make disabling BFL nonce range support a warning since it has to be explicitly
enabled on the command line now.
- miner.php allow renaming table headers
- Make bitforce nonce range support a command line option --bfl-range since
enabling it decrease hashrate by 1%.
- Add sanity checking to make sure we don't make sleep_ms less than 0 in
bitforce.
- The fastest minirig devices need a significantly smaller starting sleep time.
- Use a much shorter initial sleep time to account for faster devices and nonce
range 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 inaccuracy
of 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 bitforce
devices.
- 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 in
bitforce.
- No point counting wait time until the work is actually sent to bitforce
devices.
- 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 the
function.
- 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 nonce
range or not.
- Initially enable support for nonce range support on bfl, splitting nonces up
into 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 its
support.
- 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 check
results 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 bitforce
code.
- More improvements to comms. BFL return nothing when throttling, so should not
be considered an error. Instead repeat with a longer delay.
- Polling every 10ms there's not much point checking the pthread_cond_timedwait
as it just adds overhead. Simply check the value of work_restart in the bfl main
polling loop.
- Use a pthread conditional that is broadcast whenever work restarts are
required. Create a generic wait function waiting a specified time on that
conditional that returns if the condition is met or a specified time passed to
it has elapsed. Use this to do smarter polling in bitforce to abort work, queue
more 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 human
readable Send work busy re-tries after 10ms delay