[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[Biffa]

Pool choice can not affect hardware error rate.  It is impossible by definition.

A hardware error is when the *hardware* has an issue. There could potentially be an issue in the mining software that can misreport hardware errors, but that also has nothing to do with the pool.

I think we understand that a hardware error shouldn't be attributable to the pool.

What I would be interested to find out is what difficulty level is being set by VARDIFF on the machines?

My Oct Jupiter (552Gh/s) has a 512 diff, whereas the Nov Jup (654Gh/s) has a 1024 diff. That could have an affect?

I remember cgminer developers talking about the difficulty calculation being relative to the diff, but I could be wrong.

Wiz could you try setting the VARDIFF for >750Gh/s back to 512 see if that helps?

Or those who have moved pools can you check your KnC machines?

It shows in the cgminer status:

Connected to stratum.mining.eligius.st diff 1.02K with stratum as user blablahblah

[kria]

I too have had to take my November Jupiter to another pool. I got over 10% hardware errors and cores enabling/disabling constantly. After my 12hr avg @ Eligius dropped below 600, I switched to BTC Guild and now get 660-690 at the pool with 1.7% hardware errors and no cores goin on and off.

I noticed that my diff @ Eligius alternated between 512 and 1024 while I consistently get 256 @ BTC Guild, if that might have anything to do with it.

[helmax]

is impossible use this pool with jupiter november 10% hw is crazy

@wizkid057 if you want i can make remote for you see

now i am using ghash only  1.3% HW

http://awesomescreenshot.com/0e822tr3dd

pool eligius 10% HW more rejects, less WU and cores disables

http://awesomescreenshot.com/0dd22m3x20

[HellDiverUK]

HW errors are hardware errors, so it's probably a reporting issue.

Didn't I hear about a firmware for the KnC machines that use bfgminer instead of cgminer?

[helmax]

bfgminer i never test
but eligius have other problem
diff alternated between 512 and 1024 all time
is not stable

[kendog77]

bfgminer i never test
but eligius have other problem
diff alternated between 512 and 1024 all time
is not stable

Agreed, the diff alternating between 512 and 1024 multiple times per hour maybe contributing to the problem and can be attributed to the pool. I think the pool vardiff algorithm could use some work...

I understand that the difficulty will bounce around a bit when the miner first connects to the pool while the hashrate stabilizes, but it should not be jumping around after that.

[btcspender]

I too have had to take my November Jupiter to another pool. I got over 10% hardware errors and cores enabling/disabling constantly. After my 12hr avg @ Eligius dropped below 600, I switched to BTC Guild and now get 660-690 at the pool with 1.7% hardware errors and no cores goin on and off.

I noticed that my diff @ Eligius alternated between 512 and 1024 while I consistently get 256 @ BTC Guild, if that might have anything to do with it.

Yep same here. Oct jupiter works flawlessly on eligius but Nov jupiter has 8% hw errors and cores disabling like crazy but when I switch Nov jupiter to ghash pool it works fine errors drop back and no disabled cores

[HellDiverUK]

bfgminer i never test
but eligius have other problem
diff alternated between 512 and 1024 all time
is not stable

Agreed, the diff alternating between 512 and 1024 multiple times per hour maybe contributing to the problem and can be attributed to the pool. I think the pool vardiff algorithm could use some work...

I understand that the difficulty will bounce around a bit when the miner first connects to the pool while the hashrate stabilizes, but it should not be jumping around after that.

I see the difficulty moving here too, with only 32GH - it flips between 32 and 64, which gives me a few stale shares.

[Luke-Jr]

Difficulty changing is not harmful in any way.
Stale shares just come from latency on your internet connection and/or hardware that can't change work on a new block.

[HellDiverUK]

hardware that can't change work on a new block.

It's mostly the Blades that give the issue, so not really surprising. 

[twmz]

I too have had to take my November Jupiter to another pool. I got over 10% hardware errors and cores enabling/disabling constantly. After my 12hr avg @ Eligius dropped below 600, I switched to BTC Guild and now get 660-690 at the pool with 1.7% hardware errors and no cores goin on and off.

I noticed that my diff @ Eligius alternated between 512 and 1024 while I consistently get 256 @ BTC Guild, if that might have anything to do with it.

Yep same here. Oct jupiter works flawlessly on eligius but Nov jupiter has 8% hw errors and cores disabling like crazy but when I switch Nov jupiter to ghash pool it works fine errors drop back and no disabled cores

My November Jupiter is working fine (660 GH/s with 2% HW errors and 0.1% rejects), although I am using the cgminer-tune binary from here and I am using --load-balance to split my hashing between btcguild and eligius.

My only problem is that when the miner initially starts up, there are a few moments of insanity until the first vardiff adjustment makes the share difficulty reasonable.  I wish there was a way to specify a starting difficulty other than '2'.  I'd probably pick something like 64.  Then my Jupiter and BitFury rigs would vardiff up to something like 256/512 and my BFL Singles would vardiff down to 16/32 as appropriate.  I gather that wizkid057 is working on an enhancement to bfgminer, which is fine, but won't help me on devices that have their own mining software (e.g. my BitFury).

[helmax]

Liam (kncminer)
Dec 11 18:02 (CET)

Hello,

Please switch pool, Eligius is encountering lots of problems recently, not only with KNCMiner hardware.
Try BTCGuild, BitMinter or such.

Thanks


Med vänlig hälsning Best regards

Liam Vardy

KnCMiner
www.kncminer.com
Office: +46 8559 253 20

is time eligius put server on europe

[wizkid057]

Hi Miners,

OK, so I need to definitely address recent posts, but I'm not going to go through and individually quote them.

First, as mentioned before, pool choice can no effect hardware errors.  Its not possible.  Hardware errors are when the hardware returns an incorrect result.  I will try and get some more experts in the field to chime in on this because obviously no one believes me on this and the FUD continues.  I don't care about screenshots or other such nonsense, as there are a hundred other things that do effect hardware error rates that also have nothing whatsoever to do with the pool.

As for difficulty adjusting constantly/periodically/etc... this is normal.  It does not effect your hash rate, reject %, etc in any way.  I could go in to detail about this again, but, I will not because I've done so many times in the past. 

In any case, *if* KNC devices are for some reason actually having some issue with Eligius, it is *not* because it is making it get more hardware errors because as explained, that is impossible.  It is most likely some issue with cgminer.  If anyone knowledgeable would care to chime in on how exactly a pool can cause hardware errors, I'm all ears.  (Not to sound like a broken record, but, I won't actually hear anything because its not actually possible.)

As for Eligius "encountering lots of problems recently", that is also nonsense.  Take a look at the pool-wide hash rate graph.  We've been pretty much rock solid for weeks.  Before that there were a few DoS attacks that did not last very long anyway.

I've added more hardware to the back end and have been making improvements constantly to be able to handle the influx of new users smoothly.  Eligius handles well over 100,000 connections continuously submitting without issues and processes over 200,000 diff 1 equivalent shares per second, all while retaining the ability to pay via the coinbase transaction with near-realtime balance/amount updates.  No other pool does this, probably because it is quite a bit of work to perfect.

Overall, most everyone who mines here is happy with the pool.  If there were really some widespread issue with the pool causing problems with certain miners, I'm sure I would know about it and would have reported it here.

I am, however, working on investigating the reports from a small number of KNC users.  I'd be willing to bet that this can be chalked up to some random issue with cgminer, but in the interest of thoughroghness I am in fact investigating in detail.  So far the people I have spoken with on IRC willing to run several tests for me show no issues or discrepancies between Eligius and other pools.

Thanks, and happy mining!

-wk

[helmax]

i think all people use eligius and me ofcourse are happy

but november batch knc not work well here

[twmz]

My November Jupiter is working fine (660 GH/s with 2% HW errors and 0.1% rejects), although I am using the cgminer-tune binary from here and I am using --load-balance to split my hashing between btcguild and eligius.

I have to correct myself.  I did a test where I pointed cgminer-tune at only eligius (not load balanced with btcguild), and in that configuration, I also see the 10% lower WU (and the 10% HW which I agree and understand are not real hardware errors, but are reported as hardware errors for some reason in cgminer).

It seems that by sending a portion of my hashing to btcguild, the problem was being masked.

[wizkid057]

Since my last post I've ssh'd into three different recently shipped KNC jupiters (thank you everyone) and ran many tests.

I tested against Eligius.  I also tested against btcguild and bitminter.  No noticeable deviation in HW error counts.

For more in depth Eligius testing:

I tried Eligius's getwork (disabling stratum redirect), and no increase in HW error counts.

I tried increasing the size of the coinbase transaction the KNC device used for stratum mining (this made old avalon firmwares have problems which is why Eligius limits to 128 outputs now) to 500 outputs.  No change.

I tried locking work difficulty at difficulty 1 to increase load.  No change.

I tried locking work difficulty at 1024, 2048.  No change.


Highest I saw cgminer CPU usage at was about 25%.

So far 3 out of 3 devices I've tested have functioned flawlessly, so, I don't know what is going on here (if anything).

-wk

[davebodger]

Is the payout queue working OK at present?
I have been above my minimum payout for two blocks now (more than 4 hours), but the stats is still saying :-
"Approximately 0.00000000 BTC remaining to enter payout queue. Maintaining your 3 hour hashrate average, this will take at least another a few seconds at current network difficulty of 908350862.44".

1DNqNN7TaauTSnaxigXNx11nntDBxLwS7n

[wizkid057]

Is the payout queue working OK at present?
I have been above my minimum payout for two blocks now (more than 4 hours), but the stats is still saying :-
"Approximately 0.00000000 BTC remaining to enter payout queue. Maintaining your 3 hour hashrate average, this will take at least another a few seconds at current network difficulty of 908350862.44".

1DNqNN7TaauTSnaxigXNx11nntDBxLwS7n

Looks like you had a minimum payout set, and then adjusted it downward.  Its not instantly effective.  I went ahead and pushed it through manually.  Check again in about 10 minutes (caching).

-wk

[davebodger]

Is the payout queue working OK at present?
I have been above my minimum payout for two blocks now (more than 4 hours), but the stats is still saying :-
"Approximately 0.00000000 BTC remaining to enter payout queue. Maintaining your 3 hour hashrate average, this will take at least another a few seconds at current network difficulty of 908350862.44".
1DNqNN7TaauTSnaxigXNx11nntDBxLwS7n

Looks like you had a minimum payout set, and then adjusted it downward.  Its not instantly effective.  I went ahead and pushed it through manually.  Check again in about 10 minutes (caching).

-wk

Thanks very much, I can see it has gone into the queue now.
I did adjust my min.payment downwards but that was back when the difficulty change happened and I am sure I have had a payment go through since then. Strange. Perhaps my memory is playing tricks with me. TVM anyway.

[wizkid057]

Following up my earlier post about KNC...

Still not able to duplicate any issues on any devices I have ssh'd into.  Several folks have run their own tests with varying results which I'm looking into.