Topic: [ANN] New Primecoin Pool + GPU Miner - page 7. (Read 19672 times)

Mad props for your choice of wire protocol and communication framework.

That is exactly what I want to suggest too. 

Cannot connect to the pool 

Are you able to connect to the pool?

You should implement a solo with the same fee as the pool miner, just as a back up for situations like this.

its down again, up... and down, and up, and down... and up and so on...

GPU 1: max bits used 341/352
N=11 SIZE=4096 STRIPES=420 WIDTH=20 PCOUNT=40960 TARGET=10
GPU 2: has 32 CUs
GPU 2: hash primorial = 30030 (14 bits)
GPU 2: sieve primorial = 435656388001 (58 bits)
GPU 2: sieve size = 550556388001 (7 bits)
GPU 2: max bits used 341/352
Connecting to frontend: 54.187.143.168:6666 ...

is this pool alive?

sorry for your loss Game Over!

I'm doing a complete fresh resync now with which i can work tomorrow.

Until then.

To protect against buffer overflows, input validation is required. Any field, form entry, or any other method that input is received could be a potential point of vulnerability for a buffer overflow. This not only includes a form field, but HTTP headers that are consumed, XML interfaces, or any other type of input accepted. Broaden your mind and think of all the possible locations that input are accepted in your software application. There are a lot. The more you think about it the more area's that need to be tested for.
Some of the more simply things that a developer should perform are to set limits to the input's allowed size. Even though someone could have a name with 100 characters in it, limit the size of the field. You need to know exactly the size of the potential data that is coming up. This could be as simple as setting the HTML size tag in the input type field, or using some javascript to check the field and validate the input. But be warned this is not enough. A malicious user won't conform to using a browser that will automatically set the input size and use javascript to validate input. A malicious user could and will use something else. A malicious user will write his own code, use netcat, or some other form of a browser to get around these simple checks. The input must be validated within the web application's code itself.
To recap html form checking, try to do the following.
Limit HTML input tags with the html size tag
URL Encode all input, to protect against special characters
Use JavaScript to perform the initial input validation
Most important, the underlying code must verify and sanitize the input provided

10240 file descriptors available

thanks eXtremal.

pool works again.

EDIT: not... getting strange errors now: *** buffer overflow detected ***

I think this is it for today, been up for almost 40h now... need to sleep. It will be dealt with tomorrow.

ulimit -n ?

i have any strange value
[GPU 0] A=98% 7970
[GPU 1] A=98% 7970
[GPU 2] A=97% 7970
[GPU 3] A=64% 7950

processor AMD Athlon 2 x2 2core, but cpu load 30-35%

so 2 hours more need to w8?

I think i found the issue:

2014-05-07 19:29:17 Using at most 200 connections (1024 file descriptors available)

1024 file descriptors is way too little, thats why it's failing to access the block files.

However i need to make a complete resynch again because the blockchain is corrupted again, and the backups don't work...

EDIT: Managed to get the backup working now i only need to find a way to increase the file descriptors in linux...

truly is pure gold, hoping for a fix! do you even know how to start dealing with it?

Good luck fixing the bug. I hope the pool is back up soon.

In the meantime, I'm trying to set up some machines to start on your pool when it goes live again.
Unfortunately I can't test now the pool is down but I think I have a problem on one machine. It reports:

Found 2 devices
Using device 0 as GPU 0
Using device 1 as GPU 1
N=11 SIZE=4096 STRIPES=420 WIDTH=20 PCOUNT=40960 TARGET=10
GPU 0: has 32 CUs
GPU 0: hash primorial = 30030 (14 bits)
GPU 0: sieve primorial = 435656388001 (39 bits)
GPU 0: sieve size = 55050240 (26 bits)
GPU 0: max bits used 341/352
N=11 SIZE=4096 STRIPES=420 WIDTH=20 PCOUNT=40960 TARGET=10
GPU 1: has 32 CUs
GPU 1: hash primorial = 30030 (14 bits)
GPU 1: sieve primorial = 435656388001 (39 bits)
GPU 1: sieve size = 55050240 (26 bits)
GPU 1: max bits used 341/352
Failed to ADL_Adapter_ID_Get. Error -1Failed to ADL_Adapter_ID_Get. Error -1Conn
ecting to frontend: 54.187.143.168:6666 ...

My main concern is the: Failed to ADL_Adapter_ID_Get. Error -1
Will this rig work when the pool goes live?

I think you simply was lucky to find 9th or 10th chain :-)

And it is strange that claymore didnt collaborate with any other pool than ypool

any eta for fix?

Well its turned into pool wars and developer "loopholes?" Whatever it is, it is not good for the coin. Guess Miners have to make the call if it is that centralized? is it worth your effort in the long run?