OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 106.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: artpego on March 23, 2014, 02:28:01 AM

Quote from: kano on March 22, 2014, 09:20:23 AM

Quote from: n3xus on March 22, 2014, 07:08:50 AM

...
I also now noticed there is a bug in LSTime that was mentioned earlier, the time isn't displayed properly.

Thanks for the update

Yeah a fix for that is looking unlikely now ... I've been looking into it in the last few hours ...

They changed the code that outputs the "Last Share Time" somewhere recently between Ant S1 versions.

So it makes it a bit beyond silly having the API break it's extremely reliable backward compatibility for a silly change like that ...
If it was a new field, that's no issue to add to my API hack/fix, but changing an existing field from a unix time number to a h:m:s string is a problem.

The new binary works great!

I got it back to a normal appearance rather than just the UNIX timestamp.

vi /usr/lib/lua/luci/controller/cgminer.lua

Find the part where it says: "--lst_date = os.date("%c", lst)" and get rid of comment (the --).

Had to do a reboot to get the change to show, buy you guys here probably know a better solution to reload luci/lua/whatever it is. I'm very new to all of this so hope it was somewhat helpful.

From:
if lst == "0" then
lst_date = "Never"
else
--lst_date = os.date("%c", lst)
lst_date = lst
end

To:

if lst == "0" then
lst_date = "Never"
else
lst_date = os.date("%c", lst)
--lst_date = lst
end

Added a comment to my README:
https://github.com/kanoi/cgminer-binaries/commit/98099e278126ba9f917f12f1e57e3d9a986917aa

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: -ck on March 31, 2014, 09:07:48 PM

Quote from: os2sam on March 31, 2014, 08:58:16 PM

Quote from: -ck on March 31, 2014, 08:41:09 PM

Quote from: os2sam on March 31, 2014, 07:42:24 PM

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

Maybe a "T" hotkey to do a toggle?

Thanks again,
Sam

You can already toggle it from the display menu.

Toggle it or just enable/disable the switching every 5 seconds?

Anyway being able to toggle it on the fly from the main menu would be more better if that is possible, hopefully without redrawing the screen and loosing the share submissions view.

Just a thought no biggie either way to me. I didn't mind the wider screen and wouldn't mind it being wider yet to include all of the useful info.
Sam

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: os2sam on March 31, 2014, 08:58:16 PM

Quote from: -ck on March 31, 2014, 08:41:09 PM

Quote from: os2sam on March 31, 2014, 07:42:24 PM

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

Maybe a "T" hotkey to do a toggle?

Thanks again,
Sam

You can already toggle it from the display menu.

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: -ck on March 31, 2014, 08:41:09 PM

Quote from: os2sam on March 31, 2014, 07:42:24 PM

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

Maybe a "T" hotkey to do a toggle?

Thanks again,
Sam

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: os2sam on March 31, 2014, 07:42:24 PM

I've been testing version 4.2.2 for 2 days now and it looks like the memory utilization is stable at 16.5 MB RAM with GBT now. Also it seems stable and reliable with BE's.

I would still like the ability to sign the block though.

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

I sent a donation for solo mining support.

Thanks Sam. The display is a sore point for everyone, and there's just too much useful info to display. I'm thinking to make it not toggle by default next time and just show the hashrate and allow people to enable it to toggle or something.

Signing the block will be coming but I had to concentrate on making sure the implementation was rock solid and massively scaleable first.

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: os2sam on March 27, 2014, 08:55:13 PM

Quote from: -ck on March 27, 2014, 05:14:34 PM

Quote from: os2sam on March 23, 2014, 08:59:49 AM

I'm pretty happy with my testing so far. But the memory utilization is still climbing, 408MB so far.

Found this memory leak and it's now fixed in git, but there won't be a new version out just yet as I fix other issues first.

Thanks for the update. I look forward to testing the new version when it's ready.

I've been testing version 4.2.2 for 2 days now and it looks like the memory utilization is stable at 16.5 MB RAM with GBT now. Also it seems stable and reliable with BE's.

I would still like the ability to sign the block though.

Not a fan of the cycling display, it's going to cause someone to go into an epileptic fit.

I sent a donation for solo mining support.
Thanks,
Sam

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: techman05 on March 31, 2014, 01:44:26 PM

Quote from: crazyates on March 31, 2014, 12:40:02 PM

Quote from: kano on March 30, 2014, 02:35:29 AM

The Ant OpenWRT binary cgminer-ants1-4.2.2a-7b8fb34 is (as always) described here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I followed the instructions (seems basic enough), but how can I verify that cgminer is the new version? I went to System > Software > Cgminer, and it still says 3.12.0-1. Is this normal?

https://github.com/kanoi/cgminer-binaries/issues/2

Added an extra comment there:

Quote

Also, the "cgminer-api version" command, when logged it, will show the cgminer version of what is running.
For cgminer-ants1-4.2.2a-7b8fb34 it will report:
[VERSION] =>
(
[ 0] => VERSION
[CGMiner] => 4.2.2a
[API] => 3.3
)

Edit: and

https://github.com/kanoi/cgminer-binaries/commit/abc6d019adc62bb6e41c2f3a165cd18f0b69b20b

techman05

hero member

Activity: 546

Merit: 500

Quote from: crazyates on March 31, 2014, 12:40:02 PM

Quote from: kano on March 30, 2014, 02:35:29 AM

The Ant OpenWRT binary cgminer-ants1-4.2.2a-7b8fb34 is (as always) described here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I followed the instructions (seems basic enough), but how can I verify that cgminer is the new version? I went to System > Software > Cgminer, and it still says 3.12.0-1. Is this normal?

https://github.com/kanoi/cgminer-binaries/issues/2

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: kano on March 30, 2014, 02:35:29 AM

The Ant OpenWRT binary cgminer-ants1-4.2.2a-7b8fb34 is (as always) described here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1

I followed the instructions (seems basic enough), but how can I verify that cgminer is the new version? I went to System > Software > Cgminer, and it still says 3.12.0-1. Is this normal?

KNK

hero member

Activity: 692

Merit: 502

Quote from: -ck on March 31, 2014, 04:10:25 AM

Some drivers like to have their raw hashrate in the API as well but it's mostly used for debugging or finding when a large discrepancy occurs between that and the share based return hashrate.

Thank you for the explanation.
Yes, that's exactly what i wanted to achieve - showing raw hashrate in addition to the effective hashrate.

And this is how it looks

The expected hashrate fluctuates between 6.0 and 6.35 Gh only and is the theoretical max when there are no errors, so i wanted to have it in statline

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: KNK on March 31, 2014, 03:38:15 AM

Quote from: kano on March 30, 2014, 11:01:34 PM

Quote from: KNK on March 30, 2014, 05:37:34 AM

...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...

All drivers return the number of hashes done.
You must have messed something (else?) up somewhere.

Not true - BaB driver returns the nonces found:

Code:

hashcount += 0xffffffffull * babinfo->new_nonces;

My driver was returning the actual hashrate of the chip, which does not change with the luck and hardware errors, but with voltage fluctuations only.
I have switched to nonces found and provide the actual hashrate separately now. (EDIT: it doesn't fluctuate much anyway)

No driver directly displays the raw hashrate because virtually every piece of hardware has a wastage rate, be that lost work or hardware errors, and as a rule in our mainline drivers only the effective hashrate is shown based on share return since that is the one that most accurately represents the effective useful hashrate to the miner. Some drivers like to have their raw hashrate in the API as well but it's mostly used for debugging or finding when a large discrepancy occurs between that and the share based return hashrate. The most comprehensive hashrate breakdown exists in the cointerra driver, as per the example below:

From API devs (all drivers get this from cgminer but it's still a share based hashrate):

Code:

[MHS av] => 799191.36
   [MHS 5s] => 835744.05
   [MHS 1m] => 802133.15
   [MHS 5m] => 814257.17
   [MHS 15m] => 813622.90

From API stats (device specific implementation):

Code:

[Calc hashrate] => 809023317013
   [Hashrate] => 809235851416
   [Share hashrate] => 799187431945
   [Total calc hashes] => 66713335626117819
   [Total hashes] => 66730861547342974
   [Total raw hashes] => 66856703711606415
   [Total share hashes] => 65902253067730944
   [Total flushed hashes] => 5497557985280
   [Accepted hashes] => 66573727231544920
   [Accepted hashrate] => 807330305483
   [Rejected hashes] => 370758174404046
   [Rejected hashrate] => 4496132673
   [Core0 hashrate] => 98977953653
   [Core1 hashrate] => 72667358378
   [Core2 hashrate] => 101483724632
   [Core3 hashrate] => 102736610121
   [Core4 hashrate] => 101483724632
   [Core5 hashrate] => 120277006971
   [Core6 hashrate] => 85196213271
   [Core7 hashrate] => 96472182675
   [Asic0Core0] => 120:fffefffefffefffefffefffefffefffe
   [Asic0Core1] => 120:fffefffefffefffefffefffefffefffe
   [Asic0Core2] => 120:fffefffefffefffefffefffefffefffe
   [Asic0Core3] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core0] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core1] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core2] => 120:fffefffefffefffefffefffefffefffe
   [Asic1Core3] => 120:fffefffefffefffefffefffefffefffe

KNK

hero member

Activity: 692

Merit: 502

Quote from: kano on March 30, 2014, 11:01:34 PM

Quote from: KNK on March 30, 2014, 05:37:34 AM

...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...

All drivers return the number of hashes done.
You must have messed something (else?) up somewhere.

Not true - BaB driver returns the nonces found:

Code:

hashcount += 0xffffffffull * babinfo->new_nonces;

My driver was returning the actual hashrate of the chip, which does not change with the luck and hardware errors, but with voltage fluctuations only.
I have switched to nonces found and provide the actual hashrate separately now. (EDIT: it doesn't fluctuate much anyway)

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Fraggle on March 31, 2014, 02:43:49 AM

Well ver 4.2.2 resulted in the exact same message. " libusb_failed to load err -99 "
Wondering if I may have installed the wrong driver first.
Does reinstalling the driver completely over write the first attempt ?
This has stumped 2 other IT guys. lol

zadig will tell you which driver is loaded for each mining device.

Fraggle

newbie

Activity: 3

Merit: 0

Well ver 4.2.2 resulted in the exact same message. " libusb_failed to load err -99 "
Wondering if I may have installed the wrong driver first.
Does reinstalling the driver completely over write the first attempt ?
This has stumped 2 other IT guys. lol

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: KNK on March 30, 2014, 05:37:34 AM

...
And one question: In my driver (from scanwork) i return the number of hashes done (not nonces found), but in this case the hashrate does not show the correct results.
...

All drivers return the number of hashes done.
You must have messed something (else?) up somewhere.

Fraggle

newbie

Activity: 3

Merit: 0

Well that could be the problem in a nut shell. I unpacked V 3.12.3- windows.
I will punctually get 4.2.2 and post the results.
Thanks

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on March 30, 2014, 04:43:30 PM

There were some generic changes done to the windows libusb for 4.2.2 but no one has tested them or reported back.

Further to this discussion, are there any windows users who can confirm any change or otherwise of the latest version? Specifically any change from working to non-working, or those with USB3 slots that previously never worked that have tried this version?

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: techman05 on March 30, 2014, 06:16:11 PM

Hi I would like to know if there is a way to api an antminer s1. I thought I saw an enable command for cgminer for antminer s1 in your readme but I don't think I saw a command to call an antminer to a pc or Linux box. Where would I look for further to this.

Thanks

https://bitcointalksearch.org/topic/antminer-s1-privileged-api-499837

techman05

hero member

Activity: 546

Merit: 500

Hi I would like to know if there is a way to api an antminer s1. I thought I saw an enable command for cgminer for antminer s1 in your readme but I don't think I saw a command to call an antminer to a pc or Linux box. Where would I look for further to this.

Thanks

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Fraggle on March 30, 2014, 03:36:01 PM

Hi all.
Just got an antminer U2. for trial but cant get it to run. I keep getting " err-99 libusb failed to start "
Running win 7 64 bit, installed driver using zadig , WinUSB v6.1.7600.16385 .
Tried driver updates, running in and out of admin, restarting and or repluging after , even get this message with just Cgminer exe , no u2 , no command line.
Got me frizzed.
Any help would be good !

What version of cgminer? There were some generic changes done to the windows libusb for 4.2.2 but no one has tested them or reported back. If you were on 4.2.2, try 4.2.1 which doesn't have those changes, or vice versa.

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