Topic: CKPool Stats - iPhone App - page 6. (Read 22137 times)

thanks for the quick update.   sounds like my height adjustment offset is off for the iPad mini.   changing a simple on/off visibility was oddly trickier than it sounds.  will add a quick iPad simulator run and see if i can correct that.  

With 1.2, on an iPad mini, when I tap the middle to hide the top right, bottom left stats, it puts a 'blank' box there and obscures part of the time at the top (right) and the marquee at the bottom (left)

I'll pm you that offline, i'll end up over the hourly limit at some point if not already.
    
With the adjustments 15s/300s(45s active), It's dropped from 950 to 140 api calls over a 5 minute period with no impact on user experience.
That will ease up some activity to your server.

I also found the block message i'm hunting for so i may be able to adjust to 60s/300s(45s) shortly with a little tweak that will get near event driven block -> push notification, backup using block num change in polling.
 {"params":["Block 397940 solved by d00d.PK217 @ ckpool!"] ..

I'll let you know when I activate the change on the live pool (today or tomorrow)
We can then see if anything needs adjusting in ckdb.
Also note I have whitelists so e.g. if you are polling the site a bit more from your data source I can set that as ignored.
But of course if everyone is doing that with the app, there can't (and of course wont) be a whitelist for 'everyone'

Edit: also, you may have noticed, but by design the hash rate stats only change once per minute.

Added some metrics.   The app (overall) is triggering 950 api calls every 5 minutes.

I will bump it to 15s/300s shortly (incrementally by EOD), and drop it down to 45s when the application is awake.

That should drop it down significantly and still provide the functions.

Felt like I was about to bump that limit soon.   I will slow it down.    

I did notice that 30 second worker change frequency and don't pull more frequently than 30s per worker.

The data is normalized through a summary node on my end to make data from kano.is look like data from solo.ckpool.

This also allows for notifications, and controls hits to your system at a known rate.   And if the downstream changes (new pool, new data, changed data structure), I don't need to wait for apple review to make adjustments.

aggregation node thread:

1 pool thread - Every 15 second, watches for block found changes.  collect pool related information
3 thread poll user status - pulls data per user if user's stamp is older than 30 seconds.  which is the minimum useful limit you noted.
(misc thread to watch status file, blockchain payout, etc)

The pool thread triggers the pool block push notification
The user thread triggers user push notifications

Every running app hits was suppose to hit the aggregation node a bit harder as it acts as the relay, and broadcast one-to-many for the 15s poll.

The user notification part has been bothering me too.  I would like not to scrap earlier notification but if it causes stress or ban, that's no good.

The target hits to kano.is:

240x times per hour for pool block change thread.
120x times per hour per app install for user thread.

Here's a few strays that are causing the numbers to be higher, and what i'm doing to address those.

If someone adds in 20 worker addresses and don't use an account.    I did not expect a lot of those, but it is there.
   - solo.ckpool does a worker list in the user view.   i can adjust this the same to save lots of hits should the parent user view eventually show workers.

User Typos.  
   - looking to apply retry suppression.   there's no stamp to baseline off.   need to better distinguish it from no api data, zero api data during restarts.

Also playing with an out of band block change notification.

The 15s/30s can be tuned as required immediately.

15s ... I can see that getting it banned shortly ... I've implemented limits in CKDB for failure events and activity events.
That was around where I was gonna limit it per hour.
There's no useful information gained by polling the site more than about once a minute.

This will also cause even more problems if you are logging in to a single account with everyone running the app ... since that will hit the account ... lots ...

If someone needs to poll the site 5760 times a day they need to find something better to do with their time ...

Even with identifying idle workers, you can't do that more than once every 30s

A worker is expected, to average, 3 shares a day of 13.33s or more.

Shares are avg 18SPM, so 1 share is avg 1.333s
a 1000% CDF is:
i.e. expect to average one in 22026.5 shares to be 10x1.333s = 13.33s
and 22026.5 shares is expected to average 8.16 hours at average 13.33s per share

FYI there's already more than 400k hits a day ...

That would best case.   15 second poll of kano.is api + apple push latency.   Every so often it will line up.   Every other time it takes folks 30s to click the screen and two more minutes to log in and check the site so it feels instant.   You still have the edge on watching the console.

Just to let you know, your notification of block 397818 popped up on my iPhone at the same instant that the message came up on my cgminer from CKPool...well done!

Thanks vh. I thought I was missing a trick lol. Awesome app.

The more the merrier.  PM me an email address and I'll load it into apple's testflight/beta list.

The refresh rate can use some optimization.   After adding the api key the worker screen will [eventually] say Hashing @ nnn.nnGHs.
But that's about it.   Some basic worker/pool stats and a few fun event notifications right now.

Hi,

Great app for starters! Use it to keep an eye on my s3 hash rate.

I'm new to this whole api key thing so take it easy on me.

I've copied and pasted the api key from Kano.is website (my account section) and pasted it into the app but can't see anymore information apart from the current hashrate. Is this right? Or am I missing something?

Thanks for the app VH btw, I like it ! 

this falls under more stats please, in the misc todo already.    it will likely be there a few iterations down.

Interesting.   Just force closing and reopening it will reinitialize all the objects and arrays, and accomplishes the same.
Might be a timing issue with a ckdb restart but i don't recall one recently.    Let's see if anyone else notices or if i can force recreate it.

I got no stats from my workers since late last night. Was working all good before that.

Anyone else have this issue ?

EDIT: workaround

1- Copy in memory your API Key
2- Remove your API key from the configuration section
3- Close the application
4- Restart the application
5- Re-Enter the Key
6- Working again

glad you find it useful.    suggestions tacked to misc todo/wishlist.

I submitted that with the app review request before starting this thread, that thread was the closest url (required) available to a support page at the time.   No sure if i can update it without another review.   I recheck to see, otherwise it will be updated with v1.2 submission.

edit: link changed and directing here.

vh,

I just noticed that the CKPool Stats Support link on the App Store points to the Kano Bitcointalk thread...it seems to be more relevant to point it to this thread instead since this is where we talk about support for the app...

Edit:  I guess my review of the app is the only one so far!