[ANN] ZERO - COMMUNITY TAKEOVER

[avilolo0101]

simplemining os can work on this coin?

[1714841462]

1714841462

[1714841462]

1714841462

[..XyZ..]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

[Hurtman]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

[geo25]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

This is more stable than mine. I have bigger fluctuations.
Only power limit and memory you change? I will try it tomorrow see if I had same results.

[Hurtman]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

This is more stable than mine. I have bigger fluctuations.
Only power limit and memory you change? I will try it tomorrow see if I had same results.

Yes,only memory. not need more core clock (60% PL Sweet spot )

[geo25]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

This is more stable than mine. I have bigger fluctuations.
Only power limit and memory you change? I will try it tomorrow see if I had same results.

Yes,only memory. not need more core clock (60% PL Sweet spot )

Thank you.
And something else with 2 1080ti how much zero you make per day? Because whattomine says ~2.8 and zeroforgetop says ~1.6 what is true?

[Hurtman]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

This is more stable than mine. I have bigger fluctuations.
Only power limit and memory you change? I will try it tomorrow see if I had same results.

Yes,only memory. not need more core clock (60% PL Sweet spot )

Thank you.
And something else with 2 1080ti how much zero you make per day? Because whattomine says ~2.8 and zeroforgetop says ~1.6 what is true?

Last Day   8.95535720 (suprnova) 6*RX 480 8 + 2*1080ti ~90 sol/s   

[geo25]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

This is more stable than mine. I have bigger fluctuations.
Only power limit and memory you change? I will try it tomorrow see if I had same results.

Yes,only memory. not need more core clock (60% PL Sweet spot )

Thank you.
And something else with 2 1080ti how much zero you make per day? Because whattomine says ~2.8 and zeroforgetop says ~1.6 what is true?

Last Day   8.95535720 (suprnova) 6*RX 480 8 + 2*1080ti ~90 sol/s   

2 1080ti = ~30sol/s so if you make 9 zero with 90 sols with 30 ~ 3 zero so whattomine is correct tomorrow I will change the pool to supernova. Thank you again you've been very helpful.

[SoNiC_77Gr]

If I well understand 1 h/s is the same with 1 sol/s, right?

In Crypto-CoinZ with 3 x RX 580 and 30h/s (30sol/s) gives a monthly profit around $437.88 but in WTM gives $352.51...
Which is the right one?

[eurospeedy]

http://ipic.su/img/img7/fs/1080tiZERO.1516291267.jpg

What clocks?

PL 60%
Memory 6000

This is more stable than mine. I have bigger fluctuations.
Only power limit and memory you change? I will try it tomorrow see if I had same results.

Yes,only memory. not need more core clock (60% PL Sweet spot )

Thank you.
And something else with 2 1080ti how much zero you make per day? Because whattomine says ~2.8 and zeroforgetop says ~1.6 what is true?

Last Day   8.95535720 (suprnova) 6*RX 480 8 + 2*1080ti ~90 sol/s   

2 1080ti = ~30sol/s so if you make 9 zero with 90 sols with 30 ~ 3 zero so whattomine is correct tomorrow I will change the pool to supernova. Thank you again you've been very helpful.

Me too, with ~33sol I was getting 1.4zero on zero.forgetop.com

[komodomining]

Why keep open other pools ?
 

[ConstantinGR]

Why keep open other pools ?
 

Can I ask you something? I would like you to tell me what you honestly think, since you have quite some experience.
Users mining on suprnova report that they get rewarded according to whattomine predictions.
So, according to whattomine right now, a 100S/s hashrate rewards a miner with 10.5 coins per day.
This means that a 65,000 hashrate would give 3505 coins per day.
65,000 S/s is suprnova's total hashrate.
3505 coins equal 350 blocks.
Suprnova (as yourself also noticed) mined 620 blocks in 24h.
This is a difference of 270 blocks in 24h.

Question:

If WTM is correct and miners report they get whatever WTM predicts, then where do these 270 blocks=2700 zer per day go?
If WTM is incorrect and suprnova indeed mines 620 blocks, how can miners report that they get what WTM predicts?

Am I wrong somewhere? I could. I am asking everybody to verify my calculations and to give feedback.

[sailor32]

Why keep open other pools ?
 

Can I ask you something? I would like you to tell me what you honestly think, since you have quite some experience.
Users mining on suprnova report that they get rewarded according to whattomine predictions.
So, according to whattomine right now, a 100S/s hashrate rewards a miner with 10.5 coins per day.
This means that a 65,000 hashrate would give 3505 coins per day.
65,000 S/s is suprnova's total hashrate.
3505 coins equal 350 blocks.
Suprnova (as yourself also noticed) mined 620 blocks in 24h.
This is a difference of 270 blocks in 24h.

Question:

If WTM is correct and miners report they get whatever WTM predicts, then where do these 270 blocks=2700 zer per day go?
If WTM is incorrect and suprnova indeed mines 620 blocks, how can miners report that they get what WTM predicts?

Am I wrong somewhere? I could. I am asking everybody to verify my calculations and to give feedback.

I think your math has an error.

If 100 Sols/s = 10.5 zer/day then 65,000 Sols/s would be 6,825 zer/day or 682.5 blocks. 62.5 more than suprnova mined, but only 9% off from the prediction.

[sailor32]

Why keep open other pools ?
 

Can I ask you something? I would like you to tell me what you honestly think, since you have quite some experience.
Users mining on suprnova report that they get rewarded according to whattomine predictions.
So, according to whattomine right now, a 100S/s hashrate rewards a miner with 10.5 coins per day.
This means that a 65,000 hashrate would give 3505 coins per day.
65,000 S/s is suprnova's total hashrate.
3505 coins equal 350 blocks.
Suprnova (as yourself also noticed) mined 620 blocks in 24h.
This is a difference of 270 blocks in 24h.

Question:

If WTM is correct and miners report they get whatever WTM predicts, then where do these 270 blocks=2700 zer per day go?
If WTM is incorrect and suprnova indeed mines 620 blocks, how can miners report that they get what WTM predicts?

Am I wrong somewhere? I could. I am asking everybody to verify my calculations and to give feedback.

I think your math has an error.

If 100 Sols/s = 10.5 zer/day then 65,000 Sols/s would be 6,825 zer/day or 682.5 blocks. 62.5 more than suprnova mined, but only 9% off from the prediction.

This math assumes that the nethash is 75,600 Sols/s. I've noticed the nethash vary bewteen 71Ksols/s to 109Ksol/s which is over 50% swing so a 9% variance in predictive income isn't all that bad in my opinion.

On the matter of other pools, I think it is unhealthy for the network as a whole to be so heavy into one pool but even our second largest pool seems to have reliability issues that suprnova does not. I mined to suprnova for months and in all the time i've mined to it, it was only down once for a few hours. I started mining to forgetop when it came online, but I've lost count how many times it has gone down and have decided to go back to suprnova for a while. Hopefully when the community pool comes online it will prove more reliable.

[ConstantinGR]

After some constructive chat in the telegram group with sailor32, here is the update:

The average suprova hashrate for the last 12h is around 70K.
If you enter this number in whattomine, you get around 3500 coins.
If on the other hand you multiply the 10 coins you get with a 100S/s hashrate by 700, you get 7000 coins.

These two calculations contradict directly.

It looks like when you add a hashrate into whattomine, their algo/formula adds this hash to the global net hash, this way increasing difficulty and decreasing the estimated rewards.

I cannot verify this assumption regarding the wtm estimation algorithm, but if it is true, then this would give a plausible answer to my question.

If anyone has a different point of view or happen to know more regarding wtm algorithm, now would the the time to speak up.

As for pool stability, I agree that suprnova is very stable and I am also aware that forgetop has been suffering from server crashes, which are attributed to DDOS attacks and other malicious attempts.

[DeCrypterManiac]

I was a miner at suprnova then I mined for 24h at forgetop because people here said it pay more but after 24h i had about 40% less.. now switched back to suprnova and after about 12h I already have about the same amount i was mining in 24 on forgetop..

[BLT_NEVER]

Here is an example from log files

We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}

ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid

Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?

If the protocol is different it goes right away as an error on the first submit.

I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:

$ ./optiminer-equihash -a  equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)

It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.

The pool always get warnings when zcash solution is submited:

 Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}

And also there is no hashrate.

Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.

Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.

Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.

The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6

My best guess would be that there is NOMP and zerod validate the block difficulty.

OPTI - genuine curiosity has got the better of me, hope you can straighten me out.

Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:

Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)

Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)

Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.

Best be time to lawyer up!

[avilolo0101]

dammm weak hands here.

[sailor32]

Here is an example from log files

We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}

ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid

Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?

If the protocol is different it goes right away as an error on the first submit.

I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:

$ ./optiminer-equihash -a  equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)

It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.

The pool always get warnings when zcash solution is submited:

 Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}

And also there is no hashrate.

Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.

Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.

Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.

The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6

My best guess would be that there is NOMP and zerod validate the block difficulty.

OPTI - genuine curiosity has got the better of me, hope you can straighten me out.

Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:

Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)

Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)

Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.

Best be time to lawyer up!

So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as  in shares) was going to the dev sever? Especially considering your very low sample size.

Maybe you should explain it again, I don't see a problem here.

[BLT_NEVER]

Here is an example from log files

We thought a block was found but it was rejected by the daemon, share data: {"job":"d3a2","ip":"::ffff:x.x.x.x","port":2053,"worker":"t1xxxxxxxxxeL","height":236147,"difficulty":0.2,"shareDiff":"4596.03419805","blockDiff":1351.176112912,"blockDiffActual":1351.176112912,"blockHash":"0000007212f19755fb017650d29e3823cf44a2b5aca1cf90baa36f3152951c0f","error":{"unknown":"check coin daemon logs"}}

ERROR: CheckEquihashSolution(): invalid solution
ERROR: CheckBlockHeader(): Equihash solution invalid

Have you considered that the user might just have used the wrong hash algorithm param when connecting to the pool?

If the protocol is different it goes right away as an error on the first submit.

I have tested all the pools listed on the first page. They all report shares mined with a wrong algorithm as correct back to the miner:

$ ./optiminer-equihash -a  equihash200_9 -s zer-eu.forgetop.com:2053 -u <...> -p x
[2018-01-17 01:42:59.055] [default] [info] Optiminer/Equihash 2.1.2 (C) Optiminer 2017
[2018-01-17 01:42:59.055] [default] [info] Connecting to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.149] [default] [info] Using 2 verifier threads.
[2018-01-17 01:42:59.149] [default] [info] Using highly optimized kernel code for Fiji devices.
[2018-01-17 01:42:59.149] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Fiji.bin
[2018-01-17 01:42:59.150] [default] [info] Autodetected '--intensity 5' for device 0.
[2018-01-17 01:42:59.192] [default] [info] Extranonce is '60000043'.
[2018-01-17 01:42:59.233] [default] [info] Mining target is 0050000000000000000000000000000000000000000000000000000000000000
[2018-01-17 01:42:59.234] [default] [info] Got new work.
[2018-01-17 01:42:59.260] [default] [info] [GPU0] Device info: {"id": "0/0" "name": "Fiji" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.314] [default] [info] Connected to zer-eu.forgetop.com:2053.
[2018-01-17 01:42:59.464] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.464] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.465] [default] [info] Autodetected '--intensity 5' for device 1.
[2018-01-17 01:42:59.570] [default] [info] [GPU1] Device info: {"id": "0/1" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:42:59.773] [default] [info] Using highly optimized kernel code for Ellesmere devices.
[2018-01-17 01:42:59.773] [default] [info] Reading bianry kernel from bin-223600/Equihash200_9-Ellesmere.bin
[2018-01-17 01:42:59.773] [default] [info] Autodetected '--intensity 5' for device 2.
[2018-01-17 01:42:59.879] [default] [info] [GPU2] Device info: {"id": "0/2" "name": "Ellesmere" "vendor": "AMD" "driver": "2482.3"}
[2018-01-17 01:43:01.015] [default] [info] [GPU2] Share accepted! (1 / 1)
[2018-01-17 01:43:02.549] [default] [info] [GPU0] Share accepted! (2 / 2)
[2018-01-17 01:43:03.061] [default] [info] [GPU2] Share accepted! (3 / 3)

It seems the pools internally filter those incorrect shares which is good. But they should be reported back to the miner as invalid.

The pool always get warnings when zcash solution is submited:

 Share rejected: {"job":"ccd0","ip":"::ffff:x.x.x.x","worker":"xxxxx.xxx","difficulty":0.01,"error":"incorrect size of solution"}

And also there is no hashrate.

Unfortunately this is not the case with the problem. Not a single warning is presented in the log files.

Those ppl have good steady hasrate, everything is OK, just when it comes to finding block it got rejected from zcashd.

Just checked, the solution verification has stayed the same in optiminer since version 2.0. You are chasing a red herring here.

The problem also does not seem to be new: https://github.com/zerocurrency/zero/issues/6

My best guess would be that there is NOMP and zerod validate the block difficulty.

OPTI - genuine curiosity has got the better of me, hope you can straighten me out.

Monitored all 1.1 traffic over the course of 90 minutes (on a crap - 1sol - GPU). A little confused by the traffic patterns! Miner fires up and connects to Devfee server (88.99.30.25 / Proxy.optiminer.pl / static.25.30.99.88.clients.your-server.de) blah blah blah - expected.
But over the course of 90 minutes:

Sent packets to forgetop pool = 136 (132978 bytes)
Sent packets to you = 5 (1052 bytes)

Received packets from forgetop pool = 221 (29891)
Received packets from you = 89 (23264)

Seems like a fairly large payload for a heartbeat - it is a heartbeat yes? Odd direction considering the client shuts down on port block. No, it is not is it? Firewall shows client sending out heartbeat at a reasonable size of 60, and you respond with a payload of 250-300. Those packets are work – and they account for 35-40%. I can watch the miner state 'Got New Work' and BOOOOOOM - in real time - a tic in received packet count. Sometimes from you, sometimes from Forge.

Best be time to lawyer up!

So according to your 90 minute, low share test run, the optimizer getwork from dev server is consuming 28% of the download bandwidth (89/(221+ 89)), but only 3.5% (5/ (136+5)) of the upload bandwidth. Wouldn't this suggest that the dev fee is close to what is advertised, since only 3.5% of the data submitted (as  in shares) was going to the dev sever? Especially considering your very low sample size.

Maybe you should explain it again, I don't see a problem here.

Valid points although I think sample size is irrelevant - the client is consistent in its ping to the devfee server, that server is consistent in its reply. And each reply can be visually correlated with a Got New Work line item in the client. Without having access to the underlying src, it is more than plausible to assume that close to 1/3rd of hashing power is being diverted.

What is more telling since I blocked all comm with devfee - my chart has flattened out a bit while my avg HR has remained near consistent. This is what needs a bigger sample size - I'll report back in 24.

All rigs doing ZER work btw...
I