The official MacMiner thread [BTC/LTC-CPU/GPU/FPGA/ASIC] - page 5.

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: nwoolls on May 08, 2014, 11:24:08 PM

Good call - I'll send out a note. The change was specifically about the "Statistics API" but, in hindsight, that's not super clear. The change is only for that specific endpoint.

Yeah, I should have checked the website, sorry about that! A fixed version is out now, tested a little better

This version also adds a Gridseed setting to CPU miner so those gridseed owners who've been using that should either switch to bfgminer with GPU window (recommended) or change the CPU miner settings from scrypt (Litecoin etc.) to Gridseed (scrypt)

nwoolls

hero member

Activity: 840

Merit: 1002

Quote from: Anonymailer on May 08, 2014, 09:22:35 PM

Quote from: nwoolls on May 08, 2014, 10:54:05 AM

The RemoteCommands endpoint should also be passed a MachineName on the QueryString:

http://www.mobileminerapp.com/#api

Code:

{Root URL}/RemoteCommands?emailAddress={Email Address}&applicationKey={Application Key}&machineName={Machine Name}&apiKey={API Key}

Whoops, sorry! I think you should notify people of this Nate, I only just changed this the other day as the email you sent on the 5th said

"You should no longer send the MachineName as an argument in the URL query string. Instead you should provide the MachineName on the JSON object you are sending via HTTP POST."

In retrospect obviously this didn't apply to the commands - I'll fix ASAP!

Good call - I'll send out a note. The change was specifically about the "Statistics API" but, in hindsight, that's not super clear. The change is only for that specific endpoint.

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: nwoolls on May 08, 2014, 10:54:05 AM

The RemoteCommands endpoint should also be passed a MachineName on the QueryString:

http://www.mobileminerapp.com/#api

Code:

{Root URL}/RemoteCommands?emailAddress={Email Address}&applicationKey={Application Key}&machineName={Machine Name}&apiKey={API Key}

Whoops, sorry! I think you should notify people of this Nate, I only just changed this the other day as the email you sent on the 5th said

"You should no longer send the MachineName as an argument in the URL query string. Instead you should provide the MachineName on the JSON object you are sending via HTTP POST."

In retrospect obviously this didn't apply to the commands - I'll fix ASAP!

nwoolls

hero member

Activity: 840

Merit: 1002

Quote from: XFox on May 08, 2014, 10:22:38 AM

Quote from: Anonymailer on May 07, 2014, 12:58:15 PM

I found the root of the continuing MobileMiner issues and have updated to fix that as well as added some sanity checks in hope of fixing the mysterious and elusive crashing bug some users are experiencing on second app launch.

With 1.5.20b2 I see this error in system log (e-mail address and API key obscured):

Code:

08/05/14 16:19:35,357 MacMiner[72481]: Error getting https://api.mobileminerapp.com/api/[email protected]&applicationKey=xxxx-xxxx-xxxx&apiKey=26efrOXrizmEF3, HTTP status code 404

The RemoteCommands endpoint should also be passed a MachineName on the QueryString:

http://www.mobileminerapp.com/#api

Code:

{Root URL}/RemoteCommands?emailAddress={Email Address}&applicationKey={Application Key}&machineName={Machine Name}&apiKey={API Key}

XFox

full member

Activity: 144

Merit: 100

Quote from: Anonymailer on May 07, 2014, 12:58:15 PM

I found the root of the continuing MobileMiner issues and have updated to fix that as well as added some sanity checks in hope of fixing the mysterious and elusive crashing bug some users are experiencing on second app launch.

With 1.5.20b2 I see this error in system log (e-mail address and application key obscured):

Code:

08/05/14 16:19:35,357 MacMiner[72481]: Error getting https://api.mobileminerapp.com/api/[email protected]&applicationKey=xxxx-xxxx-xxxx&apiKey=26efrOXrizmEF3, HTTP status code 404

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 07, 2014, 08:24:27 PM

I'm worried that ASIC will kill scrypt - it was built specifically to be ASIC resistant so what's it for now?

Kill it from what perspective? The _real_ reason for "mining" is to verify transactions. ASIC scrypt is really good for this because it is very low power, efficient, green.

Coin was not created in order to make money mining. Mining rewards were created to solve the chicken-egg problem of getting people to run verification servers, uh, that is miners to bootstrap BTC.

So, yeah, LTC was naive in trying to make GPU mining easier than ASIC, if they had been smart they would have realized that ASICs would come to scrypt. Or maybe they knew and purposely sought a more efficient process but had to mis-direct the mining community in order to get the miners involved in scrypt.

nwoolls

hero member

Activity: 840

Merit: 1002

Quote from: Anonymailer on May 07, 2014, 08:24:27 PM

I'm worried that ASIC will kill scrypt - it was built specifically to be ASIC resistant so what's it for now?

Seems like a constant cat-and-mouse game. Now GPU miners are looking at Scrypt-N and X11. The problem is, if they gain enough popularity, then you'll see a HW implementation of those as well. With enough interest any SW algorithm can be done in HW in theory.

Anonymailer

hero member

Activity: 662

Merit: 500

Thanks Nate! I think I'm good for now.. we'll see!

I'm worried that ASIC will kill scrypt - it was built specifically to be ASIC resistant so what's it for now?

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 07, 2014, 12:58:15 PM

Not optimistic about the future value of any particular coin then?

Scrypt looks good, the tradeoff of processing power for memory gives lower power requirements providing possibly a long life against the cost of power.

nwoolls

hero member

Activity: 840

Merit: 1002

Quote from: Anonymailer on May 07, 2014, 12:58:15 PM

I found the root of the continuing MobileMiner issues and have updated to fix that as well as added some sanity checks in hope of fixing the mysterious and elusive crashing bug some users are experiencing on second app launch.

As always feel free to give me a shout if you ever need a hand with the MobileMiner API. Thanks again for supporting it!

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: DanZaph on May 07, 2014, 12:18:22 PM

Quote from: Anonymailer on May 07, 2014, 07:24:51 AM

You mean the BFL and the cube? Sad to see the earlier ASICs becoming redundant already! The gridseed should be profitable for scrypt for a while..

It is close, yesterday was un-profitable, today marginally profitable. I also see where waldohover shut down Jupiter miners.

Not optimistic about the future value of any particular coin then?

I found the root of the continuing MobileMiner issues and have updated to fix that as well as added some sanity checks in hope of fixing the mysterious and elusive crashing bug some users are experiencing on second app launch.

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 07, 2014, 07:24:51 AM

You mean the BFL and the cube? Sad to see the earlier ASICs becoming redundant already! The gridseed should be profitable for scrypt for a while..

It is close, yesterday was un-profitable, today marginally profitable. I also see where waldohover shut down Jupiter miners.

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: DanZaph on May 07, 2014, 06:46:04 AM

I'll try that.
But it is really late for the those miners, they are no longer profitable at the current BTC price with poor luck so I am shutting them down in the next week. My electricity cost is $0.08/kWh.

You mean the BFL and the cube? Sad to see the earlier ASICs becoming redundant already! The gridseed should be profitable for scrypt for a while..

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 07, 2014, 03:38:20 AM

Quote from: DanZaph on May 06, 2014, 11:17:59 PM

The miners that did not work were an ASICMiner V3 Erupter Cube and a BFL Jalapeño.

I'm using a BFL Jalapeño with this version - we've probably got a backend behaviour here - one thing I would suggest is starting the BTC miners BEFORE starting the gridseed miners on LTC mode

If that's not it, I wonder whether it's an issue with the proxy for the cube…

I'll try that.
But it is really late for the those miners, they are no longer profitable at the current BTC price with poor luck so I am shutting them down in the next week. My electricity cost is $0.08/kWh.

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: DanZaph on May 06, 2014, 11:17:59 PM

The miners that did not work were an ASICMiner V3 Erupter Cube and a BFL Jalapeño.

I'm using a BFL Jalapeño with this version - we've probably got a backend behaviour here - one thing I would suggest is starting the BTC miners BEFORE starting the gridseed miners on LTC mode

If that's not it, I wonder whether it's an issue with the proxy for the cube…

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 06, 2014, 07:55:22 PM

Quote from: DanZaph on May 06, 2014, 07:50:43 PM

Bad: Neither of my BTC miners work, back to 1.5.18e.

What are the BTC miners that are not working?

The miners that did not work were an ASICMiner V3 Erupter Cube and a BFL Jalapeño.

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: DanZaph on May 06, 2014, 07:50:43 PM

Good: "-S gridseed:all" works for me, finds and mines with both Gridseed devices.
Bad: Neither of my BTC miners work, back to 1.5.18e.

Well that's awesome progress with the gridseeds! What are the BTC miners that are not working?

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 06, 2014, 05:08:55 PM

Quote from: DanZaph on May 06, 2014, 09:44:53 AM

Quote from: Anonymailer on May 05, 2014, 01:46:43 PM

I'm also particularly interested for gridseed users to give the bfgminer included a shot as this is the latest from github.

I have two Gridseed 5-chip units, currently mining with minerd via Terminal, one device per minerd. I am willing to try 1.5.20b1 but would like some setting information. Also do I need to have two instances of MacMiner, one per Gridseed unit?

Unfortunately using the CPU miner window which uses minerd you do have to have two instances but I'm hoping you'll now be able to use the devices in one instance of the GPU window with manual flags either

-S gridseed:all

or

-S dualminer:all

i :: think :: the latter is for 1 chip and vice versa but not totally sure.

Good: "-S gridseed:all" works for me, finds and mines with both Gridseed devices.
Bad: Neither of my BTC miners work, back to 1.5.18e.

Anonymailer

hero member

Activity: 662

Merit: 500

Quote from: DanZaph on May 06, 2014, 09:44:53 AM

Quote from: Anonymailer on May 05, 2014, 01:46:43 PM

I'm also particularly interested for gridseed users to give the bfgminer included a shot as this is the latest from github.

I have two Gridseed 5-chip units, currently mining with minerd via Terminal, one device per minerd. I am willing to try 1.5.20b1 but would like some setting information. Also do I need to have two instances of MacMiner, one per Gridseed unit?

Unfortunately using the CPU miner window which uses minerd you do have to have two instances but I'm hoping you'll now be able to use the devices in one instance of the GPU window with manual flags either

-S gridseed:all

or

-S dualminer:all

i :: think :: the latter is for 1 chip and vice versa but not totally sure.

DanZaph

member

Activity: 104

Merit: 10

Quote from: Anonymailer on May 05, 2014, 01:46:43 PM

I'm also particularly interested for gridseed users to give the bfgminer included a shot as this is the latest from github.

I have two Gridseed 5-chip units, currently mining with minerd via Terminal, one device per minerd. I am willing to try 1.5.20b1 but would like some setting information. Also do I need to have two instances of MacMiner, one per Gridseed unit?

Topic: The official MacMiner thread [BTC/LTC-CPU/GPU/FPGA/ASIC] - page 5. (Read 166698 times)