Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 769. (Read 5805728 times)

This is a mistake, it's not CGMINER it MY POOL's fault with all the rejects, NOT CGMINER!

With that said.  I was looking for an easy way out where thus I was requesting the developer changed cgminer to stick to one IP address until there was a problem and requested a new one from the DNS just like poclbm does.

OK I should have made it clearer - post a link to some proper explanation.
Don't post here about it (that's what I said at the end of my post)
Seriously, if I cannot find anyone who can actually answer the question I'll spend time tomorrow looking at the code myself.
This is as bad as the other coin threads - people posting beliefs, not facts.
This is not religion it's computer programming.

thats is what merged mining is. it does not split your hashrate. you'll mine with you total hashrate on both chains simultaneously.

what i dont understand: why is cgminer not able to do that? other miners are.

ok..pool need patched bitcoind (to put 33 bytes namecoin data in the coinbase without a block size change), a proxy and default namecoind... but your end should stay the same (except that you get the same btc value as now AND additional to that namecoins [at least after nmc-block 19200])

EDIT:
highlighted important part

Why do you ignore the most important part of my post:

Yes cgminer CANNOT mine 2 different chains at the same time.
It cannot. It cannot. Got that? It cannot.
If you wish to switch to a different chain, you have to exit cgminer and start it again on the different chain.

Also: lets say you mine 500Mh/s to Bitcoin
Please tell me how it is possible to add hashes to Namecoin, without reducing the hashs sent to Bitcoin?
i.e.

I will continue posting this because it is relevant to cgminer.
cgminer cannot mine 2 chains at the same time.
Until they get the hint that there is no point posting here about namecoin, take notice and stop doing it.

Although i resisted posting this since this is not a merged mining thread here is my 2c.

- If merged mining works (as written in those threads) it doesnt take hashes away from bitcoin.
- It doesnt help nor hurt bitcoin
- It doesnt help nor hurt namecoin

Namecoin would be better off with just namecoin-ppl cpumining namecoins. You have to understand that a higher hashrate doesnt make namecoin better. Since the difficulty adapts itself. And namecoin is currently in a really bad situation since a lot of bitcoiner miners mined the living daylights out of their difficulty for a quick profit.

The ppl that can benefit from it and would want it are miners. They could potentially make more cash with it...

Some references:
https://bitcointalksearch.org/topic/thoughts-and-questions-on-btc-pools-and-merged-mining-44546


Best
//Ghost of Kobra

APP SDK isn't enough for the ADL features. You should be able to build with USE=-adl

Well two things:

1) The reason that cgminer doesnt work with your pool (nmcbit) is that it works as it is supposed to. The whole idea of automatic load balancing is that it should be transparent to the clients. So fix the pool.

2) The reason that the other miners works with your pool is that they are broken and doesnt load balance (they stick to the one of them that they got the first time - ie. no load balancing.)


Best Regards
//Ghost of kobra

I have dev-util/amd-app-sdk-bin though.

That is another solution I have pondered.  However PSJ code quickly uses methods to quickly validate work that can not be accomplished using Memcache or anyother type off remote memory.  With that said miners existed before my clustered pool idea did.

Best regards

Davinci

Not sure why you are angry, but like bitcoins is not a scam merged mining is not a scam.  The work you do on mining is "a make work project" and very little to do with a particular block chain.   Yes, there is tx validation work being done but on any block chain the majority of the work you do is not relevant just the fact that you did it is.  This is an easy to understand version of how it works it's not exactly right but in a general sense it is.

I'm not going to get into an argument with you about fraud because there is none.  

Finally today at my pool you can mine namecoins and get paid bitcoins but when merged mining kicks in you will be mining both.  When it happens the market will decide if it's worth it.

Good luck

Davinci

This is a bug on your end. The solution is to get your pool servers to share their work log.

The only thing 'merged mining' does is take hashes away from Bitcoin and give them to another chain (in this case namecoin) but pretend that it's good for bitcoin.
It isn't good for bitcoin.
It is good for namecoin and bad for bitcoin.
It's a scam because namecoin people won't admit the truth, and thus try to convince others by deception.

I'd wonder how people would react if SolidCoin 2.0 did merged mining ...

Anyway, AGAIN, cgminer cannot mine 2 chains at the same time.
So there is no point looking for other changes to suit you when it will never work in it's current incarnation anyway.

I look at it this way:
Would I want to lower cgminer's extremely high ability to avoid rejects and stales just so I can give away hashes to namecoin?
No, of course not.

Instability Since 2.0.3:

I was running stable with 2.0.0 through 2.0.2, but with 2.0.3, my GPU started dying.  I was hopeful that the auto-fan changes in 2.0.4 would fix this, but they didn't.  As such, I have two questions:

1) Does cgminer 2.0.3+ have additional performance improvements that might require me to lower my OC values some more like an
earlier 1.x version did?

2) Regardless of the answer to (1), would these parameters effectively prevent overheating without manipulating the GPU after startup?:
--temp-target 66 --temp-hysteresis 1 --temp-cutoff 68

I ask (2) because I am thinking maybe (especially if the answer to [1] is no) my GPU doesn't like the constant changes and will be stable this way but still shut off before it even risks heat damage (68 should be a low number, but I haven't seen this GPU functional while the temp was above 70 yet).

EDIT:  I hav beeen stable for an hour using the parameters mentioned in (2).  Also, I am getting the same shares/minute as before and haven't reached the target temp.  It would appear that the instability I was experiencing (including earlier today when it was cooler where the miner is) was due to either a) my GPU overheating before cgminer took action (possibly due to my higher 72 degree temp cutoff combined with the auto-fan) or b) the constant changes from cgminer (which seems less likely given the stability experienced in version prios to 2.0.3).  I'm guessing (a) is the culprit, and it doesn't necessarily imply a problem with cgminer since I didn't lower my --temp-cutoff from 72 during those runs.

Con, regardless of you opinion on NMC vs BTC et al, round robin DNS is a standard thing it would be good to support.  Unfortunately, I know nothing about programming, but here's a thought on a simple solution that might keep cgminer better than the others...  What if cgminer keeps track of which work belongs to which IP so that it can take advantage of that instead of only using one IP or sending work to the wrong server?  I suppose you could actually choose one IP and fail over to others by default and only do this when --load-balance was selected, but then if someone wanted a backup pool as well, they would have to work for it or only work for one server in any round robin pool.  One other thing to keep in mind would be that a slower mining device might be better off not using all of the servers depending on much the load-balancing might negatively affect the shares found vs shares discarded.

It works with CGIMiner the problem is my pool does not because of the round robin.   If you connect to just one server CGIMiner KICKS ASS!

Also you can mine more than one chain at the same time it's not a scam anymore than bitcoin is scam.  You sound like my viewers of my YouTube channel when I told them about bitcoins.

SCAM!

The great thing about merged mining if it works well is that we can have more than one currency and that will not be inflationary anymore than copper is inflationary to gold.  lol

Have a good one.

Your pool is namecoin.
There is no point posting in this thread.
The bitcoin+namecoin mining scam idea will not work with cgminer.
It cannot mine more than one chain at the same time.

Use balanceserver1.nmcbit.com you will get less than 0.10 rejects that's where I will add my code.  Check my stats...
http://www.nmcbit.com/statistics
See the guys with ZERO or less than .10, those are CGIMiners connecting to just one server instead of nmcbit.com.

No wonder I'm getting 80% rejects on your pool, I thought it was just overloaded and my connection was too slow to get work submitted without a faster miner beating me to it.

Suggested fix.

Hi I run a pool that takes a different approach to pool servers.  I use many servers and not just one and round robin them on one domain.  CGIMine is the only miner I know of that does not stick to the one ip when it makes get work requests and submitting its work thus it would get work from one server on the round robin and submit it to another that rejects it.

I am thinking of creating a balance server to fix this issue however if the developer can fix it that would be better.

Currently poclbm works fine it sticks to one server ip unit there is a problem then request a new IP address from the domain name rotating it to another server automatically.
If you are not familiar with round robin domain the way it works is that if you ping nmcbit.com you will get an IP address clear your DNS cache and pint nmcbit.com and you will a different IP.   This is great for web sites not so good for mining if the miner does not use the same IP over and over again until there is a problem.

Using multiple servers gives me the appearance of 100% up time (once I get all the bugs out lol) as I do upgrades.  Last night was prime example where I was able to rotate out pushpool with PoolServerJ with no disruptions to my miners.

This is best fixed on your side because a user could have one username on the pool but many miners using the same username and password from the same IP address, thus preventing my load balance code from detecting if the user came from the same computer.

I had similar problems starting with 2.0.0, however, my shares/minute stayed the same or improved, so I didn't worry about it.  I think (guessing here) it is lower because more work is queued to prevent you from running out of shares and dropped because they sit too long.