Topic: [ANN][The Original Multipool - Scrypt/SHA256/Scrypt-N/X11] multipool.us - page 241. (Read 424294 times)

Quote from: flound1129 on June 19, 2013, 11:13:29 AM

Quote from: kslavik on June 19, 2013, 12:49:39 PM

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

the api is perfect! .. good job.

Is there any way to get the current pool being mined via scrypt throught he api?

Check out api2.php and let me know what you think.

I would separate Multiport stats to a separate API call: apiMultiport.php (take out worker and pool data). There could be different frequency when those stats are needed, they would be on a different window/screen in the API reader most likely anyway.

They're fairly inexpensive operations, and they're cached.. Are they breaking your reader?

Nothing can break my reader: as long as it has valid JSON, it will display it.

It is just a matter of preference: only request data which is relevant and needed at the moment. I have seen pools with many different API data sets. My app can display multiple popups directed to different API services, so I would rather have two small windows than one big one with a long scroll bar. Either way is fine in the end, especially of no additional resources is involved in generating those API responses.

What do other people think who are using APIs?

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: flound1129 on June 19, 2013, 12:29:57 PM

Quote from: flound1129 on June 19, 2013, 11:13:29 AM

Quote from: kslavik on June 19, 2013, 12:49:39 PM

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

the api is perfect! .. good job.

Is there any way to get the current pool being mined via scrypt throught he api?

Check out api2.php and let me know what you think.

I would separate Multiport stats to a separate API call: apiMultiport.php (take out worker and pool data). There could be different frequency when those stats are needed, they would be on a different window/screen in the API reader most likely anyway.

By the way, the display is different when there's no API key. It just shows the hashrates for the various currencies.

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: flound1129 on June 19, 2013, 12:29:57 PM

Quote from: flound1129 on June 19, 2013, 11:13:29 AM

Quote from: flound1129 on June 19, 2013, 12:29:57 PM

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

the api is perfect! .. good job.

Is there any way to get the current pool being mined via scrypt throught he api?

Check out api2.php and let me know what you think.

I would separate Multiport stats to a separate API call: apiMultiport.php (take out worker and pool data). There could be different frequency when those stats are needed, they would be on a different window/screen in the API reader most likely anyway.

They're fairly inexpensive operations, and they're cached.. Are they breaking your reader?

kslavik

sr. member

Activity: 441

Merit: 250

GET IN - Smart Ticket Protocol - Live in market!

Quote from: flound1129 on June 19, 2013, 11:13:29 AM

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

the api is perfect! .. good job.

Is there any way to get the current pool being mined via scrypt throught he api?

Check out api2.php and let me know what you think.

I would separate Multiport stats to a separate API call: apiMultiport.php (take out worker and pool data). There could be different frequency when those stats are needed, they would be on a different window/screen in the API reader most likely anyway.

acc85

sr. member

Activity: 312

Merit: 250

perfect! gonna start using API key instead

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: flound1129 on June 19, 2013, 11:13:29 AM

Quote from: flound1129 on June 19, 2013, 11:13:29 AM

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

the api is perfect! .. good job.

Is there any way to get the current pool being mined via scrypt throught he api?

Check out api2.php and let me know what you think.

acc85

sr. member

Activity: 312

Merit: 250

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

the api is perfect! .. good job.

Is there any way to get the current pool being mined via scrypt throught he api?

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: Zalfrin on June 19, 2013, 10:59:42 AM

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

For some reason the TRC pool worker table was out of sync. I synced it up with the others.

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Is the donator list updated manually, just on a slow refresh, or... ? I bumped my donation up to 4% to be a "patron", but I'm not on the list after an hour or so. *shrug*

Oops! Bug in the stats.. I had originally planned to set patron at 5% but forgot to modify the SQL when I changed it to 4. Thanks for reporting, you should be showing up now!

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: Balthazar on June 19, 2013, 06:06:56 AM

Quote

Last 30 Blocks Found - NVC
Block Confirms Finder Time
27,351 12 mike270 2013-06-19 13:04:13

Congratulations

woohoo!

flound1129

hero member

Activity: 938

Merit: 1000

www.multipool.us

Quote from: Armchair Miner on June 19, 2013, 04:19:35 AM

I was trying to set donation to a fraction of a percent Wink

but the form apparently reset it to 0. Hint Hint.

Try putting in a leading zero (i.e. "0.1" or "0.5") rather than just ".5"..

Zalfrin

sr. member

Activity: 401

Merit: 250

Is the donator list updated manually, just on a slow refresh, or... ? I bumped my donation up to 4% to be a "patron", but I'm not on the list after an hour or so. *shrug*

acc85

sr. member

Activity: 312

Merit: 250

Quote from: acc85 on June 19, 2013, 07:00:31 AM

Quote from: kslavik on June 19, 2013, 06:48:44 AM

Quote from: acc85 on June 19, 2013, 07:00:31 AM

.....Also I wondered if it was better to order the List having the worker names as keys then have the coins as values to workers? e.g
{"workers":{"name:"{"coin":{"key":"value"},"coin":{"key":"value"}}}}

Reversing Workers tables to Worker->Currency->Key:value,Key:Value, (from "Currency->worker->key:value,key:value) would work as well, with a difference that results will be grouped by workers first.

I think it is better to leave it as it is because sortable workers list per currency would make more sense than
sortable currencies list per worker. I know that we have only hashrate for each worker over there right now as a key:value, but once more values are added (# of shares, difficulty, etc) into the table per worker, sorting would only make sense within a currency.

If anyone interested, my Web-based API reader is right here http://json.karasoft.com with Multipool templates added:

hmm I noticed that in trc coin list of workers, there are more workers than there are in the other coins, I'm guessing those were deleted workers also included in the list?

Also just suggested the Worker->Currency->Key:value,Key:Value, cause in most miner monitors i've seen.. it's more of a case os seeing which worker is active than seeing what coin is being minerd by what miner, afterall. it is a worker list

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

If only value inside the table would be "hash rate" per Currency/per worker, then table would look great if workers would be on Y axis and currencies on the X (I agree with you there):

Code:

              LTC   FTC     DGC    NVC    MNC
Worker 1       0     0       0      0     85.3
Worker 2       0     0       0      0     300.5

it would look like that internally:

Code:

{"worker1":{"coin 1":"hashrate","coin 2":"hashrate"}},
{"worker2":{"coin 1":"hashrate","coin 2":"hashrate"}}

On the other hand if there is more than 1 key:value pairs per worker/per currency, I would still like to see workers in the list (I know it will be several lists: one per currency), which would mean that Currencies should be first grouping parameter.

Multipool specific API reader would display values as they would think is the best (so either way would work), but I have a generic one (I display data as given to me by API), which makes me prefer Currency->Worker->key:value,key:value way.

it wouldn't nessecarily need to look like:

Code:

{"worker1":{"coin 1":"hashrate","coin 2":"hashrate"}},
{"worker2":{"coin 1":"hashrate","coin 2":"hashrate"}}

afterall, it's just a JSON, rearranging the data into presentable data is simple enough, could easily be {"worker1":{"coin 1":{"hashrate":value, "status":value},"coin 2":{"hashrate":value, "status":value}}}.

it's more aesthetics, not really important, as long as it hold the data it's fine. More importantly is the deleted workers still being retained in teh database or still being parsed to the JSON.

kslavik

sr. member

Activity: 441

Merit: 250

GET IN - Smart Ticket Protocol - Live in market!

Quote from: kslavik on June 19, 2013, 06:48:44 AM

Quote from: kslavik on June 19, 2013, 06:48:44 AM

.....Also I wondered if it was better to order the List having the worker names as keys then have the coins as values to workers? e.g
{"workers":{"name:"{"coin":{"key":"value"},"coin":{"key":"value"}}}}

Reversing Workers tables to Worker->Currency->Key:value,Key:Value, (from "Currency->worker->key:value,key:value) would work as well, with a difference that results will be grouped by workers first.

I think it is better to leave it as it is because sortable workers list per currency would make more sense than
sortable currencies list per worker. I know that we have only hashrate for each worker over there right now as a key:value, but once more values are added (# of shares, difficulty, etc) into the table per worker, sorting would only make sense within a currency.

If anyone interested, my Web-based API reader is right here http://json.karasoft.com with Multipool templates added:

hmm I noticed that in trc coin list of workers, there are more workers than there are in the other coins, I'm guessing those were deleted workers also included in the list?

Also just suggested the Worker->Currency->Key:value,Key:Value, cause in most miner monitors i've seen.. it's more of a case os seeing which worker is active than seeing what coin is being minerd by what miner, afterall. it is a worker list

There is something wrong with worker deletion: wrong worker is deleted when I tried to delete one, and they are not completely gone from the database.

If only value inside the table would be "hash rate" per Currency/per worker, then table would look great if workers would be on Y axis and currencies on the X (I agree with you there):

Code:

              LTC   FTC     DGC    NVC    MNC
Worker 1       0     0       0      0     85.3
Worker 2       0     0       0      0     300.5

it would look like that internally:

Code:

{"worker1":{"coin 1":"hashrate","coin 2":"hashrate"}},
{"worker2":{"coin 1":"hashrate","coin 2":"hashrate"}}

On the other hand if there is more than 1 key:value pairs per worker/per currency, I would still like to see workers in the list (I know it will be several lists: one per currency), which would mean that Currencies should be first grouping parameter.

Multipool specific API reader would display values as they would think is the best (so either way would work), but I have a generic one (I display data as given to me by API), which makes me prefer Currency->Worker->key:value,key:value way.

acc85

sr. member

Activity: 312

Merit: 250

.....Also I wondered if it was better to order the List having the worker names as keys then have the coins as values to workers? e.g
{"workers":{"name:"{"coin":{"key":"value"},"coin":{"key":"value"}}}}

Reversing Workers tables to Worker->Currency->Key:value,Key:Value, (from "Currency->worker->key:value,key:value) would work as well, with a difference that results will be grouped by workers first.

I think it is better to leave it as it is because sortable workers list per currency would make more sense than
sortable currencies list per worker. I know that we have only hashrate for each worker over there right now as a key:value, but once more values are added (# of shares, difficulty, etc) into the table per worker, sorting would only make sense within a currency.

If anyone interested, my Web-based API reader is right here http://json.karasoft.com with Multipool templates added:

hmm I noticed that in trc coin list of workers, there are more workers than there are in the other coins, I'm guessing those were deleted workers also included in the list?

Also just suggested the Worker->Currency->Key:value,Key:Value, cause in most miner monitors i've seen.. it's more of a case os seeing which worker is active than seeing what coin is being minerd by what miner, afterall. it is a worker list

kslavik

sr. member

Activity: 441

Merit: 250

GET IN - Smart Ticket Protocol - Live in market!