No, it is not necessary to disable the GPU functionality, but you do need to specify the com ports.

Wait where did you hear that? That was never said, and you can run GPUs with BFL. Gigavps runs 14 BFL with 2 GPUs getting 13GH on one machine.

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

Which you can do at startup with the memdiff option:
--gpu-memdiff -150

Melbourne, my town? Sure why not... though mentioning a venue and time would be good...

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.

Right, I didn't say it was good practice, sanctioned, moral, appropriate or anything else of the sort. Just casting a purely objective observation about what it did.

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.

There is also one other potential use that I'm not sure if I should point out or not

If you see this:

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

Ah my bad 

Curious. What possible useful information does .01 hashes/minute resolution give you? Variance of share luck alone is usually in the +/-10% range, and the 2nd decimal place was only ever there for CPU miners to see something besides zero.

NEW RELEASE - VERSION 2.3.6, 29 APRIL 2012

This is a hotfix release around 2.3.5 so anyone on 2.3.5 I suggest you upgrade as soon as possible.

Human readable changelog

Important: --submit-stale option no longer exists. I have replaced it with --no-submit-stale and made it submit stale shares by default now. The reason for this change is that with the new longpoll code in cgminer, it can detect block changes if you have backup pools almost always faster than the primary pool can detect the block change (unless the primary pool found the block). This means the primary pool is still accepting shares for the old block, so it won't consider them stale yet.

I've further revised the networking code to be able to cope with multigigahash machines that can overwhelm the one upstream and one downstream connection that was introduced into 2.3.5. Now it tries to get the best of all worlds. It does this by keeping one connection open for up and one for down and reuses that at all times, but, when it detects a backlog of share submission or getworks will occur, it starts recruiting extra connections. Thus it will be as nice as it can be to networks, but get nasty if it needs to.

Two crashes were fixed: One was that hot-adding of pools was broken in 2.3.5. The second crash would very rarely occur across a longpoll when many pools were set up.

The double longpoll message from the same pool should be fixed.

Slight changes to make the screen output even neater.

Full changelog
- Shorten stale share messages slightly.
- Protect the freeing of current_hash under mutex_lock to prevent racing on it
when set_curblock is hit concurrently.
- Change default behaviour to submitting stale, removing the --submit-stale
option and adding a --no-submit-stale option.
- Make sure to start the getwork and submit threads when a pool is added on the
fly. This fixes a crash when a pool is added to running cgminer and then
switched to.
- Faster hardware can easily outstrip the speed we can get work and submit
shares when using only one connection per pool.
- Test the queued list to see if any get/submits are already queued and if they
are, start recruiting extra connections by generating new threads.
- This allows us to reuse network connections at low loads but recuit new open
connections as they're needed, so that cgminer can scale to hardware of any
size.

No, the sick rate should not be changed by this code update. The symptoms usually happen on machines with >2GH connected to GPUMAX. What happens is that it starts submitting lots of stale shares and then eventually submits nothing but rejects because the network simply can't keep up at the other end.

Morning all. There will be another quick release in succession as there is a problem with keeping up with slow responding pools when you have mutli-gigahash machines.

Yes, the changelog said as much... LP is being used on every pool you are connected to now.

NEW RELEASE - VERSION 2.3.5, 28 APRIL 2012

Human readable changelog:
Much nicer on networks, should have significantly less connections and not induce network congestion. This will help both miner and pool hardware.
Much smoother across longpolls, uses one longpoll per pool now at all times
Simpler screen output, yet more info
More ztex hardware support
New diakgcn kernel
Numerous bugfixes surrounding stale handling and display
Updated miner.php
--no-longpoll does not exist any more
Numerous min(e)r improvements

Full changelog:
- Restarting cgminer leads to a socket that can't be bound for 60 seconds, so
increase the interval that API binding waits to 30 seconds to minimise the
number of times it will retry, spamming the logs.
- Give a longpoll message for any longpoll that detects a block change, primary
or backup, and also display which pool it was.
- Decrease utility display to one decimal place.
- Small cosmetic output alignment.
- Add pool number to stale share message.
- Add space to log output now that there is more screen real estate available.
- Indentation clean up.
- Merge branch 'master' of github.com:ckolivas/cgminer
- Remove thread id display from rejected shares as well.
- Merge pull request #185 from Diapolo/diakgcn
- add goffset support for diakgcn with -v 1 and update kernel version
- Set have_longpoll to true when there is at least one pool with longpoll.
- Don't display the thread ID since it adds no useful information over the
device number.
- Don't display the first 8 bytes of a share since they will always be zero at
>= 1 difficulty.
- work->longpoll is reset across test_work_current so we need to recheck what
pool it belongs to.
- Use longpolls from backup pools with failover-only enabled just to check for
block changes, but don't use them as work.
- Start longpoll only after we have tried to extract the longpoll URL.
- Check for submitold flag on resubmit of shares, and give different message for
stale shares on retry.
- Check for submitold before submitstale.
- Don't force fresh curl connections on anything but longpoll threads.
- Create one longpoll thread per pool, using backup pools for those pools that
don't have longpoll.
- Use the work created from the longpoll return only if we don't have
failover-enabled, and only flag the work as a longpoll if it is the current
pool.
- This will work around the problem of trying to restart the single longpoll
thread on pool changes that was leading to race conditions.
- It will also have less work restarts from the multiple longpolls received from
different pools.
- Remove the ability to disable longpoll. It is not a useful feature and will
conflict with planned changes to longpoll code.
- Remove the invalid entries from the example configuration file.
- Add support for latest ATI SDK on windows.
- Export missing function from libztex.
- miner.php change socktimeoutsec = 10 (it only waits once)
- Bugfix: Make initial_args a const char** to satisfy exec argument type warning
(on Windows only)
- miner.php add a timeout so you don't sit and wait ... forever
- Create discrete persistent submit and get work threads per pool, thus allowing
all submitworks belonging to the same pool to reuse the same curl handle, and
all getworks to reuse their own handle.
- Use separate handles for submission to not make getwork potentially delay
share submission which is time critical.
- This will allow much more reusing of persistent connections instead of opening
new ones which can flood routers.
- This mandated a rework of the extra longpoll support (for when pools are
switched) and this is managed by restarting longpoll cleanly and waiting for a
thread join.
- miner.php only show the current date header once
- miner.php also add current time like single rig page
- miner.php display rig 'when' table at top of the multi-rig summary page
- README - add some Ztex details
- api.c include zTex in the FPGA support list
- api.c ensure 'devs' shows PGA's when only PGA code is compiled
- cgminer.c sharelog code consistency and compile warning fix
- README correct API version number
- README spelling error
- api.c combine all pairs of sprintfs()
- api.c uncomment and use BLANK (and COMMA)
- Code style cleanup
- Annotating frequency changes with the changed from value
- README clarification of 'notify' command
- README update for API RPC 'devdetails'
- api.c 'devdetails' list static details of devices
- Using less heap space as my TP-Link seems to not handle this much

2.3.5, which I'm in the process of completing shortly.

opencl has nothing to do with xorg I'm afraid, but what you need before starting cgminer is:

Just for further reference:

Ah there was also one bug where submitold was not being checked on re-submission. This has been fixed in my git tree.

Pools usually selectively request submitold on work items, usually for merged mining reasons - that is because a share for an old nmc block is still a relevant share for the existing BTC block. Most pools do not universally enable it except in the case of p2pool.