Con,
2.9.1 is extremely unstable for me on Win7 64bit... I went back to 2.8.5.
Can I get you extra debugging info?
Yes you can. The instructions and debug versions required are here: http://ck.kolivas.org/apps/cgminer/debug/Same goes for any windows related crashes. |
|
|
|
Somewhere between 2.8.5 and 2.9.1 the mhs 5s fields changed from 5 to 3. What is the setting to change this back to 5s?
Thanks,
gigavps
--log|-l <arg> Interval in seconds between log output (default: 3) That change was after 2.9.1 in git only at the moment |
|
|
|
Another thing...
The Stratum pool isn't be read correctly from the conf file.
I added it via the API, saved config and it correctly shows in conf file:
{
"url" : "stratum+tcp://stratum.ozco.in:3333",
"user" : "xxxxx",
"pass" : "xxxxx"
}
But then when cgminer starts, it shows via the API as a disabled pool, without the 'stratum+tcp://' prefix or port suffix, just 'stratum.ozco.in'.
Leave the striked out bit out of the conf file. It's a bug in the configuration reading code. |
|
|
|
Working nicely.
Have GW, GBT & Stratum pools all up and running.
Something in the order of:
11,000% efficiency on Eclipse (GBT + Var Diff)
1,800% efficiency on MaxBTC (GW)
550% efficiency on Ozcoin (Stratum)
Get VERY large discards on GBT though, on the order of 1000%
Roughly 30% on Stratum and GW
Kano, did you said you're gonna add data counters to the pools? That'd be very interesting to see.
The switch between regular and GBT pools is still not ideal and the GBT work on switching to it can be stale for a while. There is a fix in git for this. |
|
|
|
Well here are my results using stratum vs. getwork
These were on the standard getwork us.ozco.in:8332. My hash rate was 520Mhs U:7.5 WU:7.5
206873 2012-11-07 12:41:51 4,393 0.03354776
206808 2012-11-07 02:54:22 806 0.03152941
206800 2012-11-07 01:11:42 1,592 0.03447590
206778 2012-11-06 21:53:48 2,368 0.03428086
These were on Stratum stratum.ozco.in:3333. My hash rate was 523Mhs U:6.7 WU:7.3
206752 2012-11-06 17:35:01 757 0.02448683
206736 2012-11-06 15:03:56 1,054 0.02756680
206723 2012-11-06 12:44:48 946 0.02476589
206709 2012-11-06 08:56:48 3,747 0.02780425
I've gone back to us.ozco.in:8332 for now.
Thanks,
Sam
I've observed the same thing here. I had 2 miners pointing to stratum, one around 660mh (one 7970), one around 2gh (3x7970). The one 7970 is running up to par. But the 3x7970 is running subpar. All cards were running at 650 or less, and unit output is decreased. I generally get a unit work of 9.1/7970. The 3x7970 was running at 22, should be around 27. (I have another 3x7970 on p2pool, and it's at 26.) So I've switched my 3x7970 back to LP on oz, for now I'm leaving my 1x7970 on stratum. M Unless you're getting lots of disconnects with stratum, and your SS: count has risen, then there is no way to blame this on stratum. I often regret putting utility in as a counter in cgminer because it is a measure of hashrate x luck and people often blame stretches of bad luck on whatever their last software change was. Now if it is an issue of lost shares due to disconnects, that's another story. The SS counter will tell you that. EDIT: It's also worth noting most people are noticing a universal rise in their hashrate, which makes sense given the lack of dropout in work between getworks that stratum exhibits. Hashrate being an objective figure unrelated to luck. |
|
|
|
|
Okay I don't understand that one bit, but I assume that the build fixes that went in for BSD to compile broke windows. Meh.
|
|
|
|
Both of my GPU rigs are Linux, but I have 2 FPGAs running on a Windows 7 laptop. If the new client will support these FPGAs (even only for testing as I know this goes against the idea of CoinLab) I can use those for testing, otherwise I'll have to wait for a Linux client.
The custom client will be for GPUs only. |
|
|
|
|
cgminer just accepts the input in whatever format you use since it detects what kind of server is at the other end. None of these differ on the pool side for how they're managed.
|
|
|
|
Ok, latest git 2.9.0 is compiling again  ? if 2.9.0 compiled, when did it break? |
|
|
|
Latest cgminer from git doesn't seem to want to do long polling in conjunction with p2pool any more. Pastebin link to log: http://pastebin.com/g3A3z1hb (note line 46, where the long polling URL is sent) After reverting to 2.8.7 (git checkout v2.8.7), long polling works again. Thanks, will investigate. |
|
|
|
New (and old feature ie mm) engineering will begin again soon. Been busy, moving around, new jobs, yadda yadda yadda.
Big Plans - Much love
RR
|
|
|
|
|
lol which git checkout did build then since it's pretty much identical?
|
|
|
|
|
cgminer mines LTC and has fan control built in.
|
|
|
|
|
For my part, the client works on both linux and windows (and maybe one day osx). However for a release, they need a front end/GUI, and I have had nothing to do with it so cannot comment on the release plan.
|
|
|
|
Software change is VERY unlikely since no one has changed the BFL code for a month.
Not impossible of course, but certainly not a likely suspect.
Right, none of the fpga code has been touched in a while. On the other hand, cgminer keeps devices busier than ever so if they're borderline, it will push them over. |
|
|
|
|
rpi is notorious for lousy usb. Get a powered usb hub for it.
|
|
|
|
Do you still see the same behavior on say US3 vs US1?
Testing... Much the same. pool 2 is us3 in this example. [2012-11-06 15:10:28] Accepted 546c28db Diff 3/1 GPU 1 pool 2
[2012-11-06 15:10:33] Stratum from pool 3 detected new block
[2012-11-06 15:10:36] Accepted 3bbe84f0 Diff 4/1 GPU 0 pool 2
[2012-11-06 15:10:37] Accepted a017ef1d Diff 1/1 GPU 2 pool 2
[2012-11-06 15:10:37] Accepted c1b972f0 Diff 1/1 GPU 1 pool 2
[2012-11-06 15:10:38] Accepted aaaeaba9 Diff 1/1 GPU 0 pool 2
[2012-11-06 15:10:41] GBT LONGPOLL from pool 2 requested work restart
[2012-11-06 15:10:42] Rejected a9542179 Diff 1/1 GPU 1 pool 2 (stale-prevblk)
[2012-11-06 15:10:44] Accepted 5ca1ab35 Diff 2/1 GPU 2 pool 2
[2012-11-06 15:10:44] Accepted 21e2296e Diff 7/1 GPU 2 pool 2
[2012-11-06 15:10:45] Accepted 20cdce48 Diff 7/1 GPU 3 pool 2
[2012-11-06 15:10:46] Accepted 86978852 Diff 1/1 GPU 3 pool 2
[2012-11-06 15:10:48] Accepted 022acdbb Diff 118/1 GPU 1 pool 2
[2012-11-06 15:10:49] Accepted c4a25647 Diff 1/1 GPU 3 pool 2
[2012-11-06 15:10:51] Accepted 659a84b6 Diff 2/1 GPU 1 pool 2
[2012-11-06 15:10:51] Accepted ad389866 Diff 1/1 GPU 2 pool 2
[2012-11-06 15:10:54] GBT LONGPOLL from pool 2 requested work restart
[2012-11-06 15:10:54] Stale share detected, submitting as user requested
[2012-11-06 15:10:54] Accepted aad92828 Diff 1/1 GPU 2 pool 2
EDIT: Note this is not unique. Other pools struggle trying to notify of blocks as fast as slush does too, over and above the stratum vs GBT difference. No idea what his magic is. |
|
|
|
Here we go. Same test case: [2012-11-06 14:46:08] Accepted e40fc282 Diff 1/1 GPU 1 pool 2
[2012-11-06 14:46:09] Stratum from pool 3 detected new block
[2012-11-06 14:46:10] Stale share detected, submitting as user requested
[2012-11-06 14:46:10] Accepted 1ec336f1 Diff 8/1 GPU 0 pool 2
[2012-11-06 14:46:10] Accepted 7feedf4b Diff 2/1 GPU 2 pool 2
[2012-11-06 14:46:12] Accepted b4d46b3d Diff 1/1 GPU 0 pool 2
[2012-11-06 14:46:12] Accepted 1cae983c Diff 8/1 GPU 0 pool 2
[2012-11-06 14:46:12] Accepted e9e286b4 Diff 1/1 GPU 3 pool 2
[2012-11-06 14:46:13] Accepted 41e88213 Diff 3/1 GPU 1 pool 2
[2012-11-06 14:46:14] Accepted 85495569 Diff 1/1 GPU 0 pool 2
[2012-11-06 14:46:15] GBT LONGPOLL from pool 2 requested work restart
[2012-11-06 14:46:15] Rejected 83a701d9 Diff 1/1 GPU 2 pool 2 (stale-prevblk)
[2012-11-06 14:46:18] Accepted f7216fee Diff 1/1 GPU 1 pool 2
[2012-11-06 14:46:18] Accepted 01486fe5 Diff 199/1 GPU 3 pool 2
[2012-11-06 14:46:19] Accepted 8447cf5a Diff 1/1 GPU 0 pool 2
[2012-11-06 14:46:20] Accepted 398c9fd9 Diff 4/1 GPU 1 pool 2
[2012-11-06 14:46:21] GBT LONGPOLL from pool 2 requested work restart
[2012-11-06 14:46:25] Accepted 93a5f6e9 Diff 1/1 GPU 1 pool 2
Stratum is seeing the block change faster routinely up to 10 seconds faster, but at least you're not rejecting shares now before your own longpoll. |
|
|
|
Switching from a stratum pool to a gbt pool is a little broken it seems on 2.9.0... No need to report this bug  EDIT: Hotfix quick update to 2.9.1 getting rid of this bug. |
|
|
|
Con, I have some changes pushed to all servers that should help with the problem you list. Can you check if that solves the problem?
One question, though, it appears you are polling for a new block template every 30 seconds is that intended?
Great. Will check. Yes it is intentional, to keep transactions current, much like stratum does. It's also a reliable way to know you can still receive stuff from the pool to know when it's down. |
|
|
|
|
Show Posts
