[ANN][The Original Multipool - Scrypt/SHA256/Scrypt-N/X11] multipool.us

[gnomicide]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

Averaged out it shouldn't matter. Although it would be nice if multiport had 10x higher hashrate!

[flound1129]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

At this hashrate we'll find (avg.) 4 LTC blocks per day.  It will average out as gnomicide said.

[rqdxrocket]

I really like the pool switching to the most profitable coin but I have been have random hangups on my machines.  It seems to happen when it switches from one coin to the next.  Because of this I have stopped mining on port 7777 and I haven't have any disconnects since.  Anyone know what the problem could be?

[flound1129]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

Hmm, estimates are actually broken right now.  Not sure what the problem is, but it's related to a change I made last night.

[flound1129]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

Hmm, estimates are actually broken right now.  Not sure what the problem is, but it's related to a change I made last night.

And, they're fixed..  Not sure what the issue was..  Cronjobs had a MySQL error but when I ran the script from the command line, it ran ok.  And it seems to have been running OK since.

[ranlo]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

Hmm, estimates are actually broken right now.  Not sure what the problem is, but it's related to a change I made last night.

And, they're fixed..  Not sure what the issue was..  Cronjobs had a MySQL error but when I ran the script from the command line, it ran ok.  And it seems to have been running OK since.

How often are the site stats updated btw? Would help to have some sort of like timer that tells how long before the next update, instead of having to refresh randomly in the hopes that things are updated, and not knowing how old the stats are, :p.

[flound1129]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

Hmm, estimates are actually broken right now.  Not sure what the problem is, but it's related to a change I made last night.

And, they're fixed..  Not sure what the issue was..  Cronjobs had a MySQL error but when I ran the script from the command line, it ran ok.  And it seems to have been running OK since.

How often are the site stats updated btw? Would help to have some sort of like timer that tells how long before the next update, instead of having to refresh randomly in the hopes that things are updated, and not knowing how old the stats are, :p.

Pool stats (upper right) are updated every minute.  For user stats (upper left), the script runs every 10 minutes, but some of the stuff is cached in memcache.

[ranlo]

Could we take LTC out of the switching pool?  I lost over 2500 shares because the size of the current block causing them to 'expire'.  I'm not sure why it's profitability is so high when the diff is up and LTC/BTC is down!  It's good to help it along but not if the shares evaporate because of the round size!

Just my 0.02 LTC...

Hmm, estimates are actually broken right now.  Not sure what the problem is, but it's related to a change I made last night.

And, they're fixed..  Not sure what the issue was..  Cronjobs had a MySQL error but when I ran the script from the command line, it ran ok.  And it seems to have been running OK since.

How often are the site stats updated btw? Would help to have some sort of like timer that tells how long before the next update, instead of having to refresh randomly in the hopes that things are updated, and not knowing how old the stats are, :p.

Pool stats (upper right) are updated every minute.  For user stats (upper left), the script runs every 10 minutes, but some of the stuff is cached in memcache.

Got ya. It was the user stats I'm mostly interested in.

Thanks!

[flound1129]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

[ranlo]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late.

[Zalfrin]

Could you take a look at the multipool graphs when you get a chance? The pie chart has different data than the bar graph, or one has mislabeled data. It'd be nice if they covered the same coins.

[flound1129]

Could you take a look at the multipool graphs when you get a chance? The pie chart has different data than the bar graph, or one has mislabeled data. It'd be nice if they covered the same coins.

Once I add FTC to the bottom graph it will all be correct.  I can't add it right now because it has some NULL entries that are messing up the display and I can't be bothered to go fix those lines in the DB.  It should be fixed by tonight.

[flound1129]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late.

Yeah, I just had an "oh shit" moment while looking at the db..  See if you can see what I found wrong here:

| id       | time                | rem_host     | username             | our_result | upstream_result | reason | solution | block_num | prev_block_hash                              | useragent | difficulty |
+----------+---------------------+--------------+----------------------+------------+-----------------+--------+----------+-----------+----------------------------------------------+-----------+------------+
| 67587309 | 2013-06-11 22:58:31 | 127.0.0.1    | sens.1               |          1 |               0 |        |          |    369216 | 9WQaCrsu9CTCspdYVQBnUuiAXBnXZn8KDZxHchmewFrc |           |         

[ranlo]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late.

Yeah, I just had an "oh shit" moment while looking at the db..  See if you can see what I found wrong here:

| id       | time                | rem_host     | username             | our_result | upstream_result | reason | solution | block_num | prev_block_hash                              | useragent | difficulty |
+----------+---------------------+--------------+----------------------+------------+-----------------+--------+----------+-----------+----------------------------------------------+-----------+------------+
| 67587309 | 2013-06-11 22:58:31 | 127.0.0.1    | sens.1               |          1 |               0 |        |          |    369216 | 9WQaCrsu9CTCspdYVQBnUuiAXBnXZn8KDZxHchmewFrc |           |         

No difficulty?

[flound1129]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late.

Yeah, I just had an "oh shit" moment while looking at the db..  See if you can see what I found wrong here:

| id       | time                | rem_host     | username             | our_result | upstream_result | reason | solution | block_num | prev_block_hash                              | useragent | difficulty |
+----------+---------------------+--------------+----------------------+------------+-----------------+--------+----------+-----------+----------------------------------------------+-----------+------------+
| 67587309 | 2013-06-11 22:58:31 | 127.0.0.1    | sens.1               |          1 |               0 |        |          |    369216 | 9WQaCrsu9CTCspdYVQBnUuiAXBnXZn8KDZxHchmewFrc |           |        

No difficulty?

No, difficulty is there, it got cut off when I copy/pasted.

Hint: It's a performance-related thing.

[ranlo]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late.

Yeah, I just had an "oh shit" moment while looking at the db..  See if you can see what I found wrong here:

| id       | time                | rem_host     | username             | our_result | upstream_result | reason | solution | block_num | prev_block_hash                              | useragent | difficulty |
+----------+---------------------+--------------+----------------------+------------+-----------------+--------+----------+-----------+----------------------------------------------+-----------+------------+
| 67587309 | 2013-06-11 22:58:31 | 127.0.0.1    | sens.1               |          1 |               0 |        |          |    369216 | 9WQaCrsu9CTCspdYVQBnUuiAXBnXZn8KDZxHchmewFrc |           |        

No difficulty?

No, difficulty is there, it got cut off when I copy/pasted.

Hint: It's a performance-related thing.

Looking at it... I have no idea. You've piqued my interest now though, :p. I'm still a newbie to SQL performance -- I can make things work but when it comes to optimizing I lack the knowledge.

[flound1129]

I have some ideas for speeding up the estimates script.  Once those are implemented I should be able to update the user stats much more frequently.

Awesome! I look forward to seeing that, . Thanks for being an active dev; it's something that's seen somewhat seldom as of late.

Yeah, I just had an "oh shit" moment while looking at the db..  See if you can see what I found wrong here:

| id       | time                | rem_host     | username             | our_result | upstream_result | reason | solution | block_num | prev_block_hash                              | useragent | difficulty |
+----------+---------------------+--------------+----------------------+------------+-----------------+--------+----------+-----------+----------------------------------------------+-----------+------------+
| 67587309 | 2013-06-11 22:58:31 | 127.0.0.1    | sens.1               |          1 |               0 |        |          |    369216 | 9WQaCrsu9CTCspdYVQBnUuiAXBnXZn8KDZxHchmewFrc |           |        

No difficulty?

No, difficulty is there, it got cut off when I copy/pasted.

Hint: It's a performance-related thing.

Looking at it... I have no idea. You've piqued my interest now though, :p. I'm still a newbie to SQL performance -- I can make things work but when it comes to optimizing I lack the knowledge.

prev_block hash is about 1/3 to 1/2 the total data that is being saved in EVERY share record inserted into the DB, and it's an absolutely *USELESS* thing to save with the share.  It's not used for ANYTHING.  (It's used for some internal pool calculations, maybe, but it's never retrieved from the shares table).

I'm modifying all of the pools to stop writing this value to the db with the saved shares.  That should cut our write disk bandwidth by 30-50% by itself.

[ranlo]

prev_block hash is about 1/3 to 1/2 the total data that is being saved in EVERY share record inserted into the DB, and it's an absolutely *USELESS* thing to save with the share.  It's not used for ANYTHING.  (It's used for some internal pool calculations, maybe, but it's never retrieved from the shares table).

I'm modifying all of the pools to stop writing this value to the db with the saved shares.  That should cut our write disk bandwidth by 30-50% by itself.

Oh, I did see that part and felt it was large, but I assumed it was used for the listing where it tells what blocks were found/when/other info about them.

[LOLMoney]

Site appears to currently be down.
Also, when switching altcoins, it appears my hashrate changes even though they are all scrypt. Any reason to that?

[ranlo]

Site appears to currently be down.
Also, when switching altcoins, it appears my hashrate changes even though they are all scrypt. Any reason to that?

Site is up for me.

Regarding hash rate changes, do they go back up? Mine slow down at the beginning and then speed back up (I assume "revving up" or something) within a few seconds.