Author

Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 134. (Read 499597 times)

sr. member
Activity: 409
Merit: 251
Crypt'n Since 2011
Very nice - what are you using to generate the charts?

Thanks.

I am using the Flot plugin for Jquery.

I was thinking that you could set up an api where I can send a request with POST data in a variable called 'bulk_users'.  The data would be JSON encoded as follows.

{"users":[{"api":"user1api","action":"userstats"},{"api":"user2api","action":"userstats"},{"api":"user3api","action":"userstats"}]}

would that work?
legendary
Activity: 1260
Merit: 1000
Very nice - what are you using to generate the charts?
sr. member
Activity: 409
Merit: 251
Crypt'n Since 2011
Just completed a webpage for charting hash rate of my miners.  I set it up so anyone can enter their API and chart their own hash rate. Is anyone interested?  If there is a lot of interest I would like to get Inaba to set up the api so I could grab multiple users data in one HTTPS call.

Here is a link to my webpage for tracking your hashrate. I put my API here to show an example. More graphs and features will follow.

http://serason.com/projects/emccharts/?api=jaycoinapi&method=hashrate
legendary
Activity: 2450
Merit: 1002
Inaba, go kill more people in BF3, we need this 10hr block to solve!
legendary
Activity: 1260
Merit: 1000
Hmm, I need to update that page. It uses the old calculation of +/- % instead of 0 - 100% that the block stats page uses.  Basically they are the same number, just expressed in different ways. 

The blocks stats page is saying 59.72% of the blocks are longer than this one.

Your found blocks page is saying it is 48.45% under difficulty.
sr. member
Activity: 245
Merit: 250
After Hack Now User 5tift
On the Block Stats Page I see 59,72% luck
Clingman88    165904        14:51:47     01:41:56    711147        59.72%

when I click on Clingman88 stands there -48,45%
510    165904    2012-02-08 14:51:47    01:41:56    711147    -48.45%

What´s the different?

./stiftmaster
legendary
Activity: 1260
Merit: 1000
JayCoin: I will be happy to setup whatever makes it easier to aggregate the data, just let me know what you need specifically.

freshzive: I don't have an iPhone, so I'm not sure what it's doing (or not doing exactly) but I can change/add to the API to make it easier for applications like that to pull the data, I just need to know what is the best format to do.

Right now, the API returns the data in GH/s or MH/s by default depending on your speed.  However, you can disable this and only return MH/s or only return GH/s by adding either gh=Y or mh=Y do the end of the http GET call.  mh=Y will only return MH/s, so even if you have a 2 GH/s miner, it will read 2000 MH/s instead of 2 GH/s, the same goes for gh=Y, which will read .2 GH/s for a 200 MH/s miner. 

sr. member
Activity: 447
Merit: 250
Using BTCMon (iphone app), workers on EMC that are over 1Gh/s report an order of magnitude lower speed than they should. i.e. a worker (cgminer) doing 1.24Gh/s reports on the app 1.24Mh/s. I'm not sure if this is something to specific to how EMC reports with API or if it's the app itself misreading something. Anyway, if it is on EMC's side, is it possible for you to fix?

Thanks Smiley
sr. member
Activity: 409
Merit: 251
Crypt'n Since 2011
Just completed a webpage for charting hash rate of my miners.  I set it up so anyone can enter their API and chart their own hash rate. Is anyone interested?  If there is a lot of interest I would like to get Inaba to set up the api so I could grab multiple users data in one HTTPS call.
sr. member
Activity: 270
Merit: 250
So the problem is with my ISP?

Okay I'll see if I can get them do do something.

Thanks
legendary
Activity: 1260
Merit: 1000
So it looks like the problem is here: 68.85.38.86

I'm not sure who owns that, probably comcast, but it appears that router has some weird routing loop going on when connecting to 208.110.68.0/24. 

traceroute to XXX.XXX.XXX.109 (XXX.XXX.XXX.109), 30 hops max, 60 byte packets
 1  69.30.224.129 (69.30.224.129)  88.550 ms  88.537 ms  88.527 ms
 2  69.30.209.125 (69.30.209.125)  88.439 ms  88.444 ms  88.439 ms
 3  te0-3-0-4.mpd22.mci01.atlas.cogentco.com (38.104.86.1)  88.444 ms  88.443 ms  88.435 ms
 4  te0-4-0-5.ccr22.dfw01.atlas.cogentco.com (154.54.46.214)  88.460 ms te0-2-0-5.ccr22.dfw01.atlas.cogentco.com (154.54.80.105)  88.439 ms te0-0-0-0.mpd21.mci01.atlas.cogentco.com (154.54.30.149)  88.365 ms
 5  te0-0-0-0.ccr21.dfw01.atlas.cogentco.com (154.54.46.165)  88.400 ms te0-1-0-6.ccr21.dfw01.atlas.cogentco.com (154.54.3.17)  88.393 ms te7-3.ccr02.dfw03.atlas.cogentco.com (154.54.6.62)  288.283 ms
 6  te8-1.mpd01.dfw03.atlas.cogentco.com (154.54.25.9)  288.304 ms  299.794 ms  299.780 ms
 7  be-10-304-pe01.1950stemmons.tx.ibone.comcast.net (173.167.56.165)  99.781 ms  99.781 ms be-10-204-pe01.1950stemmons.tx.ibone.comcast.net (75.149.230.149)  99.771 ms
 8  pos-2-4-0-0-cr01.dallas.tx.ibone.comcast.net (68.86.87.217)  99.754 ms  99.751 ms  99.721 ms
 9  pos-0-11-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.222)  99.766 ms  99.756 ms  99.745 ms
10  so-7-1-0-0-ar01.goodslettvll.tn.nash.comcast.net (68.86.90.190)  99.748 ms  99.747 ms  99.742 ms
11  ae-3-0-ar03.nashville.tn.nash.comcast.net (68.86.148.70)  99.946 ms te-9-4-ar01.bluelight.tn.knox.comcast.net (68.86.176.142)  99.952 ms ae-2-0-ar03.nashville.tn.nash.comcast.net (68.85.174.237)  99.849 ms
12  te-8-3-ur01.east.tn.knox.comcast.net (68.86.136.29)  99.865 ms  99.859 ms  99.842 ms
13  68.85.38.86 (68.85.38.86)  99.815 ms  99.805 ms  99.784 ms
14  * 68.85.38.86 (68.85.38.86)  99.748 ms *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *^C
sr. member
Activity: 270
Merit: 250
Here I go again  Huh

ping us1.eclipsemc.com
PING us1.eclipsemc.com (208.110.68.114) 56(84) bytes of data.
^C
--- us1.eclipsemc.com ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11025ms

mickey@mickeyatwork ~ $ ping us2.eclipsemc.com
PING us2.eclipsemc.com (208.110.68.115) 56(84) bytes of data.
^C
--- us2.eclipsemc.com ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11014ms

mickey@mickeyatwork ~ $ ping us3.eclipsemc.com
PING us3.eclipsemc.com (208.110.68.116) 56(84) bytes of data.
^C
--- us3.eclipsemc.com ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11021ms

mickey@mickeyatwork ~ $ traceroute us2.eclipsemc.com
traceroute to us2.eclipsemc.com (208.110.68.115), 30 hops max, 60 byte packets
 1  * * *
 2  ge-2-10-ur01.east.tn.knox.comcast.net (68.85.38.93)  15.391 ms  16.938 ms  18.150 ms
 3  te-8-1-ar01.bluelight.tn.knox.comcast.net (68.86.136.30)  19.393 ms  20.639 ms  22.264 ms
 4  xe-2-1-0-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.136.18)  23.493 ms  24.756 ms  28.212 ms
 5  pos-3-7-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.205)  33.545 ms pos-3-8-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.95.197)  35.003 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125)  32.171 ms
 6  pos-0-4-0-0-pe01.56marietta.ga.ibone.comcast.net (68.86.87.138)  36.283 ms  25.703 ms  28.843 ms
 7  te4-2.ccr01.atl02.atlas.cogentco.com (154.54.10.233)  26.367 ms  28.001 ms  28.105 ms
 8  te0-0-0-1.mpd22.atl01.atlas.cogentco.com (154.54.3.145)  41.449 ms  41.504 ms  41.667 ms
 9  te0-3-0-6.mpd22.ord01.atlas.cogentco.com (154.54.29.90)  33.939 ms te0-1-0-6.mpd22.ord01.atlas.cogentco.com (154.54.29.82)  37.112 ms te0-3-0-6.mpd22.ord01.atlas.cogentco.com (154.54.29.90)  34.443 ms
10  te0-1-0-2.mpd22.mci01.atlas.cogentco.com (154.54.3.202)  57.520 ms te0-3-0-1.mpd22.mci01.atlas.cogentco.com (154.54.7.165)  57.805 ms te0-0-0-3.mpd22.mci01.atlas.cogentco.com (154.54.25.77)  59.070 ms
11  everest.demarc.cogentco.com (38.104.86.2)  54.451 ms  60.138 ms  57.155 ms
12  69.30.209.1 (69.30.209.1)  58.684 ms  50.549 ms  55.186 ms
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
member
Activity: 114
Merit: 10
Ah yeah that I can fix... and should be fixed in about 5 minutes.


THX! It worked!

Greetz
NetworkerZ
newbie
Activity: 25
Merit: 0
No, there's not really any way to do that, as it would wreck past accounting.  It's actually a fundamental design issue (perhaps you could call it a flaw) suffered by most pools that use the worker paradigm.  I could possibly hide them permanently, but then you couldn't recreate a worker with that same name.

Just a thought, but maybe they could be marked as hidden and then renamed to something like hash(rand()) ?
sr. member
Activity: 392
Merit: 250
We could have shaved another minute off that!
legendary
Activity: 1260
Merit: 1000
Just got done killin' and see, we solved a block!
legendary
Activity: 1260
Merit: 1000
Hah, yeah I guess they are... drops it by 1.6 GH/s.  I use a pair of 6990's to game.  It literally costs me money to game, jeez.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Back to the death blocks we go =/ inaba go kill some more people in BF3!
One thing I have been wondering about that discussion ...
These are the same computers that are mining right? (or wrong?)
If they are then BF3 is reducing the pool hash rate ... ... ... ... ... ... Tongue
legendary
Activity: 2450
Merit: 1002
Back to the death blocks we go =/ inaba go kill some more people in BF3!
legendary
Activity: 1260
Merit: 1000
Ah yeah that I can fix... and should be fixed in about 5 minutes.
Jump to: