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

Great work Con and my goffset mod for diakgcn also works .

Edit: One small glitch, after pressing Q and a succesful shutdown on Windows at the end is this line here

Could there be an overwritten char * buffer or sth. like that?

Dia

And I read it too... I think that's my cue to get some sleep.

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

Queued work seems to be about 6-7x normal for my setup. At start, LP looks like it's being enabled for multiple pools. Ran 1k shares with 2.3.4 to verify, and E was much higher than 2.3.5 using the same conf.

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

I'm not sure what Eloipool is, but assuming it is the backend for Eligius, yes, that output was while mining on Eligius.  Incidentally, if you go back to the original quote, I was then, too, but I don't think you were active in this thread yet.  However, it sounds plausible that I could have been witnessing this:In which case I will need to update to 2.3.5 (which might also help with my disconnects if it has fewer sessions as previously indicated.

I'm not running as root. DISPLAY is already set. And I'm not using SSH, I'm on the local console.

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:

I tried moving my hard drive from a motherboard that only had one GPU to a motherboard that had three GPU's plugged in.

I did the sudo aticonfig -f --adapter=all --initial and rebooted, I also deleted the .bin file in cgminer's directory.

CGminer gave an error about the number of devices not matching. It saw three devices, but OpenCL was only seeing one?

Where else does OpenCL know about the number of video cards besides xorg.conf and what else should I have done besides running aticonfig?

The system was build with these instructions: https://github.com/kanoi/linux-usb-cgminer/blob/master/linux-usb-cgminer

Likely a simple fix but trying to run cgminer 2.3.4 under Debian 6.01 x64 I get

./cgminer -n
cgminer: error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory

Any ideas?

Nevermind I finally stopped being a Linux wimp and using the prebuilt binary and compiled it myself.  It only took .... (don't laugh I am a SQL Server developer by trade) ... little over an hour.

Still I learned something and it working fine now.

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

Eloipool always enables submitold. There's no real reason not to enable it, unless the pool wants to misreport a lower stale rate.

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.

Today seems like a good day to beat a dead horse...So, given that there was a longpoll, and then a stale share submitted (that was apparently accepted), and there was not another longpoll, should it be safe to assume submitold was enabled during this [~11 second] communication failure?  If it is safe to assume that, does this output indicate that maybe I really did see what I thought I saw before regardless of my faulty assumptions at that time?  If so, note that this is on 2.3.2 (in case the relevant code may not be the same after the recent network changes), but I figured I should report it anyway since I'm not specifically looking for this and it's dumb luck when I catch a communication failure or stale share being discarded.

Thanks for comments. I was quite happy merging code for FPGAs with just the simplest of code audits on my part. The problem began when multiple people wanted to hack on the same code and I chose conservative changes over aggressive ones. My "lack of interest in FPGAs" was more to do with annoyance at wasting time managing that argument than actually having anything against FPGAs. Meanwhile luke-jr kept getting more and more aggressive towards my avoiding his code pushes. I stood my ground, he forked off. Now we have some weird middle ground where collaboration is expected yet the plan is to run as two separate projects. Apparently he's still willing to do code pushes to cgminer when suitable and will take my changes as I add to cgminer. Which still makes me wonder why there should be two projects at all. In my experience, forks diverge irrevocably over time and the push pull relationship will cease. There is still time to rescue this back into one project, but I think luke-jr has already burnt that bridge. Vaguely reminds me of the BIP16 saga.

I don't consider it an "arms race", and if peoples' changes are compatible with CGMiner, I encourage doing development there.

Not that it matters much in the event of an arms race, of course, but I just wanted to state publicly that while I have a lot of respect for luke-jr's work and I *love* the name (which was kano's idea, I believe), my money is on cgminer for now.

Reasoning is:
- No one knows the core better
- As ztex worker maintainer I prefer a high entrance price development style, i.e. one where all my commits are verified
- I cannot possibly work on two code bases at once
- I have committed myself to supporting other devices on cgminer

I do think that ckolivas lack of interest on FPGAs is a negative point, but honestly so as long as he keeps doing the great job he has done so far (and I'm sure luke-jr will still help cgminer development as he's building on top of it) it just doesn't matter.

I do however understand luke-jr and others frustration, I just don't share it