OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[Mobius]

is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !

well you should be able to with task schedule

You can also use:
--shares <arg>      Quit after mining N shares (default: unlimited)

in a loop

[1714058616]

1714058616

[1714058616]

1714058616

[1714058616]

1714058616

[1714058616]

1714058616

[1714058616]

1714058616

[1714058616]

1714058616

[disclaimer201]

So, is it safe to use 2.6.4 for ltc mining now? I'm on solo and one message I received among the "new block detected on network" was "rejected 040ccc8e blabla Gpu1". Do I have to worry? Should I use an older version? Total noob to cgminer. Used cgeasy to configure (Thanks! great help) to set everything for solo ltc mining.

Edit: Thanks Rav3n ------------->

[rav3n_pl]

So, is it safe to use 2.6.4 for ltc mining now? I'm on solo and one message I received among the "new block detected on network" was "rejected 040ccc8e blabla Gpu1". Do I have to worry? Should I use an older version? Total noob to cgminer. Used cgeasy to configure (Thanks! great help) to set everything for solo ltc mining.

It is quite normal to get reject just after new block and/or longpool on any version.

[joyyen]

is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !

well you should be able to with task schedule

You can also use:
--shares <arg>      Quit after mining N shares (default: unlimited)

in a loop

i dont know how to use window scheduler and

--shares <arg>      Quit after mining N shares (default: unlimited) 

you mean the miner will quit after mining example : 5000 share and it will auto restart and mining again ?

[crazyates]

is really annoying for the 7 days bug !

i wonder if possible to add auto restart feature for windows CGminer

so every 7 days it will auto restart itself !

well you should be able to with task schedule

You can also use:
--shares <arg>      Quit after mining N shares (default: unlimited)

in a loop

i dont know how to use window scheduler and

--shares <arg>      Quit after mining N shares (default: unlimited) 

you mean the miner will quit after mining example : 5000 share and it will auto restart and mining again ?

You create a .bat file with a loop that runs CGMiner, and when CGMiner closes itself after 5000 shares, the loop restarts CGMiner. Lather, rinse, repeat.

[farfie]

You create a .bat file with a loop that runs CGMiner, and when CGMiner closes itself after 5000 shares, the loop restarts CGMiner. Lather, rinse, repeat.

I would be careful about this. You may want to add a TIMEOUT or use the ping technique to make sure threads are closed, and that the OS has released handles, otherwise the new cgminer instance won't properly grab them. 5 or 10 seconds should do the trick.

[crazyates]

You create a .bat file with a loop that runs CGMiner, and when CGMiner closes itself after 5000 shares, the loop restarts CGMiner. Lather, rinse, repeat.

I would be careful about this. You may want to add a TIMEOUT or use the ping technique to make sure threads are closed, and that the OS has released handles, otherwise the new cgminer instance won't properly grab them. 5 or 10 seconds should do the trick.

When I did this, I added a 30 delay after startup to start, and a timeout of 10 second in the loop.

[P_Shep]

If I had the time/could be bothered I'd put timers around each of the send/receive and find the max/min/avg values. But that ain't gonna happen in the next week or so.

I've done that, get the following:

ID: BFL0   Dev Max: 0.024049   Dev Min: 0.000366   Dev Av: 0.009301
ID: BFL1   Dev Max: 15.335547   Dev Min: 0.000389   Dev Av: 0.012155
ID: BFL2   Dev Max: 15.335506   Dev Min: 3.8E-5   Dev Av: 0.011484
ID: BFL3   Dev Max: 15.33545   Dev Min: 0.00036   Dev Av: 0.027547
ID: BFL4   Dev Max: 0.02345   Dev Min: 0.00036   Dev Av: 0.009153
ID: BFL5   Dev Max: 0.023163   Dev Min: 0.000404   Dev Av: 0.008941

So I put get times immedately before and after the serial port read function inside BFgets.
Dev max is (surpisingly) the max time a read took
Dev min is (surpisingly) the min time a read took
Dev av is (surpisingly) the overall average, that is all the read times summed, then divided my the read count.

So it's pretty apparent that when the single throttles, comms just stop.

[P_Shep]

Also, I started adding the temp to the log when a unit throttles...
I'm thinking about adding code with slows the unit a bit as it reaches it's individual throttle temp. Like waiting 500ms before sending new work or something. Maybe. Dunno.

[kano]

If I had the time/could be bothered I'd put timers around each of the send/receive and find the max/min/avg values. But that ain't gonna happen in the next week or so.

I've done that, get the following:

ID: BFL0   Dev Max: 0.024049   Dev Min: 0.000366   Dev Av: 0.009301
ID: BFL1   Dev Max: 15.335547   Dev Min: 0.000389   Dev Av: 0.012155
ID: BFL2   Dev Max: 15.335506   Dev Min: 3.8E-5   Dev Av: 0.011484
ID: BFL3   Dev Max: 15.33545   Dev Min: 0.00036   Dev Av: 0.027547
ID: BFL4   Dev Max: 0.02345   Dev Min: 0.00036   Dev Av: 0.009153
ID: BFL5   Dev Max: 0.023163   Dev Min: 0.000404   Dev Av: 0.008941

So I put get times immedately before and after the serial port read function inside BFgets.
Dev max is (surpisingly) the max time a read took
Dev min is (surpisingly) the min time a read took
Dev av is (surpisingly) the overall average, that is all the read times summed, then divided my the read count.

So it's pretty apparent that when the single throttles, comms just stop.

Ah well, then that just means BFL is full of shit as usual:
https://bitcointalk.org/index.php?topic=78256.msg885143#msg885143

During throttle, the device does respond to temperature read, status read, etc.
A new job, however, cannot be issued, as the unit will respond with 'BUSY'.

Good Luck,

Now to decide a workaround for more BFL design shit that doesn't involve simply saying "a BFL appearing dead for up to 30s is OK" ...

The MiniRig cards are ~twice this speed, and I have one person with 2xMR running 2.6.2 modified and he's had 29 comm errors out of 4,171,889 accepted shares - so no issue at all.

... sigh - I presume this crap is all due to the fscking stupid throttling design done by BFL where their hardware decides and controls the whole process rather than allowing the software to control it (or know about it)

[rjk]

If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.

[kano]

Also, I started adding the temp to the log when a unit throttles...
I'm thinking about adding code with slows the unit a bit as it reaches it's individual throttle temp. Like waiting 500ms before sending new work or something. Maybe. Dunno.

When my 2nd FPGA "died" in my BFL I did exactly this.
The result was useless in my case.
Adjusting it up and down (I used a getenv() to set it) appeared to make no difference at all.
(I set it to delay getenv() ms before sending new work - I tried from 100 up to about 1000)
I got the impression that the idle time was doing more bad than good

Though the death was probably something else in it crapping out since:
In my case the final fix was stupid anyway
I installed the 880 bitstream ... and it's been fine ... 2 weeks and counting ...

tl;dr story follows
I got it 4-May, but working OK from 5-May then got problems 11-Jul ... as the weather got colder ... it started to throttle and fail
(It's now the coldest part of winter here)
Then it would only mine on one FPGA.
I'd never touched the firmware coz that meant moving the stupid thing to my kids windows computer and plugging it in there to use the POS EasyMiner program.
So I did this (moved it upstairs to me instead of down in my cold basement garage) and EasyMiner said it was no good (running a test) ... but cgminer would still mine on one FPGA.

I did find a few times that if I pulled the power on it completely it would start up mining normally at 825MH/s for a while and in one case this lasted 2 days (21-Jul to 23-Jul)
After being annoyed at it for 2 weeks (code changes, power cycles etc) I decided to try kill it by putting in the 880 bitstream (26-Jul)
(sending from Aus->USA is not a cheap thing to do, so while it still partially worked I didn't want to do that)
With the 880 bitstream it's been fine ever since, upstairs here next to me, under a chair, reporting 10C higher
(air coming out is only slightly warm, not hot)
My BFL is the version with the new heatsink but only 1 fan on top so not exceptionally loud

Yeah my opinion of the throttling hardware/design is ... not good

[kano]

If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.

You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer

[P_Shep]

If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.

You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer

15.3355, in fact

[kano]

If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.

You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer

15.3355, in fact

Yeah that seems to suggest it also.
But was there a 'BUSY' reply as BFL-Engineer said there is?

[rjk]

If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.

You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer

Sorry yes, https://bitcointalk.org/index.php?topic=92409.msg1018768#msg1018768
Not returning "BUSY" as specified is lame.

[P_Shep]

If it means anything, I think BFL has specified that a throttle period lasts 15 seconds.

You got a link/reference?
Coz that one from BFL-Engineer ... is from BFL-Engineer

15.3355, in fact

Yeah that seems to suggest it also.
But was there a 'BUSY' reply as BFL-Engineer said there is?

I don't recall every seeing a 'busy', but then I've not looked for it.
I'll have another poke around...

[dave3]

I compiled 2.6.4 for windows and I've had it running for over 24 hours so far without any problems.

Code:

 cgminer version 2.6.4 - Started: [2012-08-08 12:21:53]
--------------------------------------------------------------------------------
 (5s):1629.0 (avg):1613.4 Mh/s | Q:4759  A:33041  R:567  HW:0  E:694%  U:22.2/m
 TQ: 0  ST: 4  SS: 0  DW: 1333  NB: 174  LW: 35434  GF: 46  RF: 0
 Connected to http://us2.eclipsemc.com:8337 with LP as user ---
 Block: 000006fde06dc9cde7ab56000892379d...  Started: [13:01:47]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BFL 0:  55.9C         | 811.0/806.7Mh/s | A:16567 R:283 HW:0 U:11.12/m
 BFL 1:  57.4C         | 811.0/806.7Mh/s | A:16476 R:284 HW:0 U:11.06/m
--------------------------------------------------------------------------------

[-ck]

I compiled 2.6.4 for windows and I've had it running for over 24 hours so far without any problems.

At last 
Thanks 

[RandomQ]

if someone hasn't announced this cgminer 2.6.4 works great with windows 8 pro RTM build 9200 x64.

I'm testing right now to see if its stable long term.

I'm using driver version drivers 9.00-120612a unofficial beta.

Getting around 7% better Mh/s than win 7 using same configs on a 5770 card.

Anyone working in IT that hasn't used WIN 8 its going to be a nightmare doing end user training.