Topic: [ANN][XMR] monero.crypto-pool.fr | Large Monero Mining Pool - page 34. (Read 126525 times)

Next week end.
I thing upgrade all code of pool for add new function and make more stability.

And make more convergence with code official.
Stockage of block,payout in DB with upgrade of page HTML.
Just after upgrade data pool efficience is not present .
I make update after for re add pool efficience or similary data .

I think, you like features is in progress .



I wait week end and wait magie of variance and pool regain good efficience "printed".

The pool as 100% of efficience if you look long periode .
One day efficience can 90% and next day 113% .

For periode of one Week efficience is 100% or little better.

To day , I have DDOS of port 8090 (API ) and reduce block see for not make impact of HTTP .
Service HTTP and Stratum is not same server .

For memory ! Mine on host xmr.crpyto-pool.fr and not monero.crypto-pool.fr .

monero.crypto-pool.fr is protect per Arbor and other solution but use only one server.

Yes ,
For information pool is under DDOS continue for more 1 week.
Attacker begins to understand that'm useless .
Change stategy compresse all attack for little moment .

Par ex in the last week Arbor ( the best solution for AntiDDOS as mitiged more 100 DDOS ).


Yes when mitigation is started for DDOS.
Arbor make little false positive and impact only botnet mine on the pool.

Arbor on mitigation delete connexion from host referenced on blacklist ( botnet ).
Not impact regular miner .

The magie of variance, I have best pool efficiency last 3 day whith very hard DDOS .

Efficiency actual is not conséquence of DDOS just one période of badluck.  ( Actualy 100% )

Honest :

The uniq impact of DDOS of the pool.
1.) Disconnection of miner withbotnet.
2.) Number of block I leave in history.
3.) Lost time for me supervise health of server and not code new function.

If one half day of 90% is lower for you, not compute efficience of other pool.


For the DDOS , I can not explain all parameter for protect DDOS.
 

We know this and we'll try our best to go back up like it was before.


There are attacks multiple times a day on our pool and other pools.
It is a big issue that has been here since the start of Monero but since we upgraded our system, we are much less affected by DDoS contrary to other pools.
Yesterday one pool has been shut down because of attacks (I forgot the name).
The attackers are now trying shorter attack (in time) but more intensive.
There are no stratum TCP anti DDoS solutions like it exist with HTTP.
We found a temporal solution and it works. The only drawback is a lower reported hashrate for a short time.
Actually, our solution is a sort of failover. When an attack happen, we move the miners to an other server causing the reported hashrate to be wrong.

The reason why people attack pools is to lower the global hashrate (competition) temporally so they can mine more block in the meantime.
Don't think it is free and easy to do. These kind of specialized DDoS attacks would cost you between 5 to 30 BTC (possibly more) on the darkweb depending of the time and intensity.

If you have some suggestion on how to protect against these attacks, feel free to come and discuss it on IRC #monero-pools

why this  Pool Efficiency: 90%    and  more and more  low  in several  days ！

The pool is under some form of an attack? Late last night total pool hash dropped by half. Am i seeing less hash rate reported due to the attack?

Well 10% difference is little but 30% and above is huge.

On CGminer, there is a stat called Work Utility. It is the average share work that is successfully sent to the pool per minute.
You aim to get the higher WU possible.

More details here :
cgminer and WU (Work Utility)
Utility Rate vs Hash Rate when tweaking CGMiner3.1 (LTC Pool Mining)

I know that Claymore doesn't display the WU but you have to understand that the hashrate on the pool is calculated from the share work it receive. The pool have no idea of the raw-hashrate displayed on the miner software.
The raw-hashrate could be 10 MH/S but if the pool doesn't get any work from the miner, it will display 0 H/S

I know because I've been mining for a long time that every little setting can affect the WU and that you can have a lower hashrate with a higher WU.

In the case or Monero, you should not aim to get the highest raw-hashrate (in the software) but the higher real-hashrate on the pool.
It would be a great improvement if you, the miners, could request Claymore to display more useful stats like the Work Utility instead of continuously seducing you with higher raw-hashrate every update that doesn't change anything or lower your gain.

For me, using Claymore GPU miner, I see 10% difference. That includes Claymore's 5% take. So the actual difference is 5%.

I too can confirm 30% difference in actual (client side) and pool reported hash rate. Using wolf's cpu miner.

My comment is just a theory at this point based on other peoples comments in the Claymore GPU miner thread.  Also I'm not saying either side is doing anything intentionally, just trying to understand why the difference in reported hashrates in the client vs the pool, which seems to be a recent phenomena. 

I have not had a chance to test anything yet though so no data to share...too busy with non mining related things.

I guess Claymore use some tweaks to increase the raw-hashrate while sending more wrong shares.

Do you get this ?

Does it happen all the time for you or recently ?

EDIT: Thx for your help Hilux74.

I get this error with Claymore's CPU miner, how can that have to do with overclocking? My cpu is not over clocked. Also get it with GPU miner on 2 different rigs.

Quote MP from Hilux,
Probleme seem present only new version clamored .

You can send you address for look pb side of pool.
Is badhash ? badhash lower ?

I also have this problem using Claymore's GPU miner.

I used port 7777,8888,9999 all have the same error. I do not have the same problem with other pools.

New server add
All is OK

You have share rejected ?
Is possible you have have lower hashrate because, you send bad hash (overcloking,bug,other).

Jump pool accept you bad hash is not good solution . If pool accept 30% of hashrate pool as bad efficience.

The performance of the pool is not a miracle.
We use a code very different now . Test share with the module coded by Wolf for increase performance and best validation.

You can send your addresse for look at ? You mine with port 7777 ?
Test new port 8888 or 9999

The hashrate on the pool or the global hashrate is an estimate. It is never accurate and it's simply impossible to make it accurate.
The global hashrate could double instantly but you would not see any move in the estimate. The variations that we see already happened some times ago.
The truth is that when you mine Monero or any cryptonote, you cannot estimate your gain, there are too many factors and variables. Forget about the hashrate, the only thing that matter is what you get per day (or 48h).
I invite you to split your hashrate between different pool and see what you get after (at least) 24 hours.
If I say so, it is because it tested it before and other miners also, you'll get the same pay or a little more if the efficiency was higher or a little less if the efficiency was lower.

There is also the possibility that a pool get stuck, that bitmonerod process do not send the updated block to miners and that 100% of your hashrate is wasted. In that case the pool would still display your hashrate. Great but in fact you would mine for nothing. This cannot happen on our pool because we use multiple instances of bitmonerod that monitor the block count and move the miners to an other working instance while restarting.

To finish, remember that the Monero project is in its very early days and that it's still experimental. You cannot compare it to Bitcoin and its clones that have years of development. On Bitcoin, the hashrate is pretty stable and accurate but we don't have this (yet) on Monero. What we call "stratum protocol" on Monero pools is not a real stratum, it's still in beta testing. I would like to improve all these things but I'm not a developer. Monero's devs have a lot to do and the pool code is not their priority. We are reporting bug all the time to the devs but they just don't have the time.

Anyone else notice a LARGE discrepancy between the hash rate that Claymore GPU software reports vs this pool?  I am consistently for at least the last couple weeks showing from 60% to 80% on crypto-pool.fr compared to the miner software.  When I run all my systems I have a client side reported hash of 672+635+1250+1888=4445h/s.  Very rarely on the pool stats do I see above 3500h/s reported and very often it is reporting around 2500h/s!  I also believe that earlier in time there used to be a pretty close match between the client and the pool.  What is at fault the pool or the mining software?

I know the pool doesn't display orphan/stale stats but could that account for up to 40% of my hash?

I've been with this pool pretty much since the beginning so not really interested in pointing my miners elsewhere if the discrepancy between between client and pool is the same at all pools now.

 
I just woke up. I'll ask perl (second admin) about what happened. We had a lot of DDoS attacks that didn't succeed in the last few days (didn't do anything). Last night I think an attack triggered the anti-DDoS protection, when it happen the hashrate goes lower but the pool stay online and still work. If the attack is strong enough though, the server may crash (it didn't happened). If I look at the block page, the attacker gave up after some times.

Everything seems ok now. If extremhash get a bigger hashrate, they are going to be the next target (unless the attacker is on that pool).

We got problems at the pool?

looks like extremehash has 3MH+

just saw "failure" from yam miner, disconnected....headed elsewhere for now

Where did all the hashes go?

Less than a MHash on the pool now.