Thanks for that but for such a convoluted process for the sake of one clock call when GPUs will be redundant in a couple of months seems a waste now - i.e. I'm not interested in developing in any significant fashion for GPUs any more. On the other hand, as you see from Kano's message, there are certainly other clock functions he implemented that suffer under windows that will be relevant to him.

You still haven't understood? To go through all the nonces with stratum currently as is, would require it to check 18,446,744,073,709,551,616 hashes. If that's not enough, you can just increase the size of nonce2 from 4 to 6 and get 1,208,925,819,614,629,174,706,176 hashes. This is without rolling the ntime at all. If that's not enough, rolling the ntime just once every second will give you 1,208,925,819,614,629,174,706,176 hashes per second.

That is one of the funniest posts I've read in a very long time 

cgminer times how long it takes for the gpu code to "return" after it's been given work. Unfortunately with windows, the timer resolution is so shithouse at 15ms that I have to sample many many iterations of the GPU code and then average them to see how long it took. This means that between giving the GPU code, there are short periods dependent on CPU code, and windows' scheduler does not seem to give this CPU code priority even though folding@home should be idle priority. So it ends up counting delays of the CPU scheduling as though the GPU had spent more time on its work. So it's a combination of the shit windows timer resolution and the shit windows scheduling that makes dynamic not work that well for your test case.
Thanks 

Early on I spoke to some of the ASIC-to-be manufacturers and suggested they do target testing for higher diffs internally as well, so I expect at least some of them to take a target as well That and as Eleuthria said, it's still insignificant CPU to test them anyway.

You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?

My 7970s are performing exactly the same with 2.10 as with 2.9. Coincidence related to some other problem for you perhaps?

Well actually I don't think it would even register in CPU usage even at 1.5TH of getworks with the largest asic device currently planned. It's only 375 getworks per second. It takes almost no CPU to generate that many.

Some ASICs I suspect will have rolltime built into their mining protocol since their development would have started a long time ago (theoretically), when rolltime was all the rage.

New release: Version 2.10.0, 10th December 2012

Huge upgrade of lots of code and features, so comes with the usual warnings about potential instability of the new version.


Human readable changelog:

The main change to this is a completely new work scheduler where all work spawns from. The old work scheduler would spawn threads that all tried to grab work as best as they could, and this would lead to much more work than necessary being grabbed from getwork pools, and potentially hitting the pool at precisely the same time from multiple threads making a getwork failure more likely. It was also very difficult to track how much work was really available at any one time since all the threads were off doing their own thing. Centralising the work creation means it is strictly tracked now and as soon as one work item is taken, the scheduler will generate or download another one. The advantage here is to maximise the amount of work we can get from any source, be it getwork without rolltime, with rolltime, gbt, or stratum,  or combinations of the above. It is also much less likely to have dips in providing work, should lead to less getwork failures, and scale to higher hashrates even with the old getwork protocols.

When the primary pool is stratum, GBT (or getwork in failover mode), no backup connections will be maintained to backup pools. The total number of connections when mining stratum now should be extremely small.

New MMQ driver courtesy of Kano, shows each device separately now.

New ztex drivers courtesy of Denis and Peter

Threads should now have unique names on flavours of unix (sorry windows users).

More *BSD support.

Lots of work under the hood and other minor goodies. Check full changelog.


Full changelog:

- Include prctl header for thread renaming to work.
- Set tv_idle time if a pool is not active when input from the menu.
- usb display message when device is in use/another cgminer
- libztex: avoid the use of libusb_error_name()
- minor unlikely zero pointer test
- BeaverCreek doesn't like BFI INT patching.
- Only stratum pools that are idle need to be kicked via cnx_needed.
- mmq - abbreviate the temperature numbers
- Do not do any setup if opt_api_listen is disabled in api.c.
- usbutils.c uninitialised usbstat for non-primary mmqs
- Only set the lagging flag for select_pool() on failed getwork if we're not in
opt_fail_only mode.
- libztex: in case the selectFpga() failed set the selected fpga to unknown
- Modified windows-build.txt to update git instructions.
- libztex: use a function for the twice called firmware reset code
- libztex: removed an unused struct member (ztex->valid)
- driver-ztex: support for broken fpga on a multifpga board
- Set the pool lagging flag on startup to avoid it being shown initially, and
only unset it once the maximum number of staged work items has been reached.
- Avoid recursive locking of the stgd lock. (bug found by Luke-jr).
- Return value of keep_sockalive is no longer used.
- Remove dependency on mstcpip.h for windows build by making curl version >=
7.25.0 mandatory on windows builds, and use curl functions for keepalive
whenever possible instead.
- Make main() the getwork scheduler once everything is set up, so that all app
exits use the kill_work and quit paths.
- ztex: more style and whitespace fixes
- libztex: silenced another warning
- Set successful connect to true on auth stratum to allow summary on exit from
single stratum pool.
- Only consider work stale for stratum of different job_id if it's not a share.
- Increment version preempting changed version signifying different codebase to
2.9
- Hash_pop should signal further waiters on its own pthread conditional in case
there are multiple waiters.
- Check the job_id has not changed on stratum work when deciding if the work is
stale as might occur across disconnections.
- Perform pool_resus on getwork pool that generates work in getwork_thread.
- Set pool lagging message for getwork pool that falls to zero staged in getwork
thread.
- Stage extra work when the primary pool is a getwork pool without rolltime.
- Do not try to clean up twice if kill message is given.
- Only recalculate total_staged in getwork thread if required.
- Include the correct config header in libztex and include it before other
includes.
- Implement a completely new getwork scheduler. Stage all work from the one
thread, making it possible to serialise all requests minimising the number of
getworks requested or local work generated. Use a pthread conditional to wake up
the thread whenever work is removed to generate enough work to stay above the
watermark set by opt_queue. Remove all remnants of the old queueing mechanism,
deleting the now defunct queued count.
- libztex: fixed some warnings and removed some whitespaces
- libztex: silenced some warnings
- Remove all references to the now unused workio_cmd structure.
- Remove the old workio command queue thread, replacing it with a kill
conditional to exit the program.
- Remove getwork command from workio_cmd queues and do them directly from
queue_request.
- Begin tearing down the old workio command queues by removing submit commands
from there and submit them asynchronously via their own threads.
- Update windows build instructions.
- Set pool probed to true on successful authorisation with stratum to avoid it
being pinged later with pool_getswork.
- driver-ztex: libztex_setFreq() must be called before ztex_releaseFpga()
- driver-ztex: changed two pairs of malloc()/memset() to calloc()
- libztex: Read bitstream file in 2kb blocks with simpler and faster code
- Added the binary versions of ztex_ufm1_15d4.ihx and ztex_ufm1_15y1.ihx
- Trivial space removal.
- libztex: Add firmware download support for ZTEX 1.15d and 1.15x
- libztex: Factor out local version of libusb_get_string_descriptor_ascii()
- Shut up some boring old cpu warnings.
- Style changes.
- Allow pool active to be called on stratum or disabled pools in the watchpool
thread if the pool has not been probed.
- libztex: Make log messages say bitstream when refering to bitstreams
- libztex: Don't return error when a bitstream was already configured
- libztex: Read bitstream file in 64kb blocks with simpler and faster code
- libztex: Verify that the mining firmware is not a dummy firmware
- libztex: Match mining firmware ZTEX descriptor against the dummy firmware
- Combine shared padding into one char.
- libztex: Start download sequence only after reading in the new firmware
- libztex: Download mining firmware to all devices with dummy firmware
- lock (most of) the threaded statistics updates
- README stats don't add up
- usbutils.c remove compiler warning
- Make need connection return true if a pool is idle.
- API add Best Share to summary
- Check on creating new GBT work if the structures are up to date and update
them as required rather than regularly.
- Update windows build instructions.
- Enable backup stratum connections for getwork when the primary pool doesn't
have longpoll aka solo mining.
- Check for correct absence of opt_fail_only in cnx_needed.
- Remove unused variable.
- The specification for stratum has been elaborated to say that a changed diff
applies only to new work so do not retarget when submitting shares.
- Use a variable length string array in submit_upstream_work to cope with
massive GBT submissions.
- API lock access to some summary statistics (and copy them)
- Suspend stratum connections to backup pools when there is no requirement to
potentially grab work from them.
- Fix missing export for RenameThread.
- enumerate the mining threadnames
- MMQ avoid possible number overrun crashes
- mmq usb v0.4 + api usb stats
- setting the name of the threads for linux,freebsd,openbsd and osx code is
borrowed from bitcoins util.c, so it is already tested
- Don't show broken WU value with scrypt mining.
- Style police.
- Remove unused getwork times in getswork.
- Fix readme wordwrap.

<Farnsworth>Good news everyone</>

Okay after a day of debugging on windows, I found the disconnect crash bug was actually in libcurl itself, which was rather awkward but anyway it means it should get better if you download and use the following dll instead:

http://ck.kolivas.org/apps/cgminer/temp/libcurl-4.dll

Just put it into your cgminer directory, replacing the existing libcurl dll.

EDIT: I've repackaged the 2.9.7 release for win32 as 2.9.7-1 including the fixed dll. I urge anyone on windows to update at least the dll. The package is otherwise the same version of cgminer.

EDIT2: Bug submitted to curl maintainers so hopefully it will be fixed next version: https://sourceforge.net/tracker/?func=detail&aid=3594381&group_id=976&atid=100976

The coinlab pool thread itself...
https://bitcointalk.org/index.php?topic=99643.0

Shit if you did that, you'd go back and mine with your current hardware 2 years ago.

Nope. It's not tagged as such, but it's there to demonstrate the substantially different code base if anyone's running it. That will be the version when it is finally released. Release versions are tagged in git (except when I forget to do it).

They're (we're) working on custom GPU software that will be used for bitcoin mining initially and long term for other HPC jobs.

No, likely it's the same windows special crash to do with internet going down which has been there a while. The new dll was there in the hope it fixed this, but obviously it does not.

Anyone debugging on windows could you try the instructions and builds in http://ck.kolivas.org/apps/cgminer/debug/ and use the debug build of libcurl dll that's in there as well please. Thanks.

The rewrite of how work is gathered into a getwork scheduler is well underway and in the git master tree now undergoing testing. It would not be surprising if it introduces new instability, but I'm hoping for the master branch to be tested and debugged over the next week paving the way for the next version. For what it's worth, it's currently running fine for me. Other goodies including new mmq and ztex code are in there too.

I experimented with native cuda on nvidia GPUs here at home and it performed the same speed as opencl for bitcoin mining. The only advantage I found with native cuda was I could get the CPU usage down by disabling polling in it, which you cannot do with opencl on nvidia. So in summary, just use any miner with an opencl kernel that runs on your GPU. cgminer works fine.

You're welcome The price of continued development is temporary instability, and it's users that give feedback that allow me to achieve stability once more.

Make sure to test latest, it was addressed in 2.9.7