OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 436.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: crazyates on November 26, 2012, 10:30:45 PM

Quote from: kano on November 26, 2012, 09:19:25 PM

Please just ignore Luke-Jr.

Quote from: Luke-Jr on November 26, 2012, 10:23:46 PM

P.S. Kano is simply a liar, as usual.

I feel like I've read this thread before. Maybe I'm psychic?!

Either way, it's been rough trying to keep up with all of you on the work being done to stratum and CGMiner, but keep it up!

Stratum and CGMiner is fine.
The minor issues with Stratum are that shares can be lost.

However, that number is already WAY lower than using GetWork or Moron's piece of shit.
Yes it is important to understand that.

I've been going on about the Stratum issue for quite a while.
(ckolivas actually mentioned it to them first, but I didn't know that until shortly after I brought it up)

I'd like to get no Rejects per day.
At the moment with Stratum on OzCoin with a fixed 8 difficulty and ignoring reconnects (that I force each day at midnight) I get 1 reject each day with 1.6GH/s
Yes I'm bitching about getting 1 reject each day Tongue

I want 0

This I guess is part of the reason why slush has ignored my request ... but in the end he's trying to implement a fix on the mistake he's made rather than just simply fixing it and ignoring the so called necessary backwards compatibility Sad

It's not been around long enough to care about backwards compatibility with a mistake.

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: kano on November 26, 2012, 09:19:25 PM

Please just ignore Luke-Jr.

Quote from: Luke-Jr on November 26, 2012, 10:23:46 PM

P.S. Kano is simply a liar, as usual.

I feel like I've read this thread before. Maybe I'm psychic?!

Either way, it's been rough trying to keep up with all of you on the work being done to stratum and CGMiner, but keep it up!

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Askit2 on November 26, 2012, 09:14:24 PM

ok so
96+ 23 = 119
114.8+5.2=119
Was my point. Maybe it's the maths...

You're not supposed to stop at 5.2 seconds. Stratum jobs can be used infinitely, until the block is invalid or the pool expires the job. Unlike getwork, there is no 2³² nonce limit.

Quote from: Askit2 on November 26, 2012, 09:14:24 PM

This left me wondering why you said 120 seconds to start with and only had math to make 119. Possibly to account for round trip delays or the share validation. You didn't really say. So either your math was off, or you left out part of your math.

I subtracted a second for the time between the pool sending the job and you receiving it.

P.S. Kano is simply a liar, as usual.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Askit2 on November 26, 2012, 08:58:56 PM

Quote from: Luke-Jr on November 26, 2012, 08:39:17 PM

Quote from: Askit2 on November 26, 2012, 08:14:54 PM

Quote from: Luke-Jr on November 26, 2012, 07:51:56 PM

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases:

a block was found (which you ruled out)
the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
the user extranonce1 was lost (only possible if you reconnected)

I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either:

was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool

This makes sense, since cgminer is failing to move on to new jobs as they come in.

So a BFL single running 864mhash bitstream in your example would need to work on the work for 114.8 seconds to go over. Interesting to know.
I didn't change scan time for stratum but the settings of scan time at 115 had worked fine on get work.

I will bump it down but since not every 120 seconds has this happening I would assume it is something else. The ping to Eclipse is 76ms right now. It can vary but assuming I got my work at 96 seconds add .5 for significant delays, 5.16s for single to process work I get 101.66 seconds. Leaving me 18.34 seconds to submit.....

Please just ignore Luke-Jr.
Most of what he says is FUD and even if it's not all FUD - having to waste time wading through it all is just that - a waste of time.
His answer will simply be - you must use his miner coz it does it properly ... lulz

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

ok so
96+ 23 = 119
114.8+5.2=119
Was my point. Maybe it's the maths...

Looking at it another way. I have 119 seconds or your 23 seconds should be 24 seconds to hash the work unit, find shares, and return those shares for money.

The 120 seconds is only to add either a second for submission or isn't in existance.

This left me wondering why you said 120 seconds to start with and only had math to make 119. Possibly to account for round trip delays or the share validation. You didn't really say. So either your math was off, or you left out part of your math.

Expiry still at 120
scan time adjusted to 95
Same Unknown Work

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Askit2 on November 26, 2012, 08:58:56 PM

Quote from: Luke-Jr on November 26, 2012, 08:39:17 PM

Quote from: Askit2 on November 26, 2012, 08:14:54 PM

Quote from: Luke-Jr on November 26, 2012, 07:51:56 PM

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases:

a block was found (which you ruled out)
the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
the user extranonce1 was lost (only possible if you reconnected)

I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either:

was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool

This makes sense, since cgminer is failing to move on to new jobs as they come in.

So a BFL single running 864mhash bitstream in your example would need to work on the work for 114.8 seconds to go over. Interesting to know.

No, that 21-23 seconds is real time. No matter what hashrate. 200 Mh/s is the hashrate where if you are any slower, you might still be working on the old work normally.

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: Luke-Jr on November 26, 2012, 08:39:17 PM

Quote from: Askit2 on November 26, 2012, 08:14:54 PM

Quote from: Luke-Jr on November 26, 2012, 07:51:56 PM

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases:

a block was found (which you ruled out)
the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
the user extranonce1 was lost (only possible if you reconnected)

I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either:

was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool

This makes sense, since cgminer is failing to move on to new jobs as they come in.

So a BFL single running 864mhash bitstream in your example would need to work on the work for 114.8 seconds to go over. Interesting to know.
I didn't change scan time for stratum but the settings of scan time at 115 had worked fine on get work.

I will bump it down but since not every 120 seconds has this happening I would assume it is something else. The ping to Eclipse is 76ms right now. It can vary but assuming I got my work at 96 seconds add .5 for significant delays, 5.16s for single to process work I get 101.66 seconds. Leaving me 18.34 seconds to submit.....

mdude77

legendary

Activity: 1540

Merit: 1001

Just adding my 0.0016 BTC worth here..

Since p2pool has gone berserk, I have half my miners pointing at EMC, and half at Oz.

Oz is using stratum.
EMC is using GBT.

After about 12 hours, there were noticeably more rejects on EMC than on Oz. That's with using GBT, not stratum, on Oz.

Not sure if it means anything.

M

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Askit2 on November 26, 2012, 08:14:54 PM

Quote from: Luke-Jr on November 26, 2012, 07:51:56 PM

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

Ok, I missed that somehow. "unknown-work" can only occur if one of these 3 cases:

a block was found (which you ruled out)
the miner submitted it after it expired (120 seconds on EMC; new work is delivered at least every 96 seconds)
the user extranonce1 was lost (only possible if you reconnected)

I'm pretty sure cgminer discards all work/shares in the last case (reconnection), so that means it either:

was working on a job 23 seconds after it had been replaced (this is sufficient for as low as 200 Mh/s)
was working on a job 21 seconds after it had been replaced AND took over 2 seconds to submit it to the pool

This makes sense, since cgminer is failing to move on to new jobs as they come in.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Askit2 on November 26, 2012, 08:14:54 PM

Quote from: Luke-Jr on November 26, 2012, 07:51:56 PM

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

Luke-Jr thank you for yet again pointing out why people who use your miner get less shares Tongue

(and shouldn't be using it)
Yeah processing previous block work after an LP ... right ... ... ...

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: Luke-Jr on November 26, 2012, 07:51:56 PM

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

Top post on the page you are asking on. LOOK UP!

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: P_Shep on November 26, 2012, 08:01:16 PM

That mean you have to go to IHOP.

1) I don't like hopping
2) I don't like pancakes
3) Prayer takes so much time
4) I assume I detected your humor, but if I did not, or if IHOP means something else as well, feel free to tell. Tongue

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Quote from: The00Dustin on November 26, 2012, 08:00:12 PM

Quote from: -ck on November 26, 2012, 07:40:41 PM

Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.

I'm getting "No stack." I assume that makes it obvious I've never done this before...

That means you have to go to IHOP.

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: -ck on November 26, 2012, 07:40:41 PM

Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.

I'm getting "No stack." I assume that makes it obvious I've never done this before...

ETA:

Code:

cat /usr/src/cgminer-2.9.5/Makefile | grep CFLAGS\ =
CFLAGS = -I/usr/src/ati-stream-sdk-v2.1-lnx64/include -g

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: -ck on November 26, 2012, 07:25:28 PM

Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?

You're not supposed to throw out the shares on LPs. Restarting work has no cost except on BFLs (where you have a bug that loses valid shares).

Quote from: Askit2 on November 26, 2012, 07:30:33 PM

So Junior is saying my reject ~9minutes into the block is because CGMiner didn't change to new work fast enough?

That sounds highly unlikely, and unrelated. What kind of a reject?

TheHarbinger

sr. member

Activity: 378

Merit: 250

Why is it so damn hot in here?

I have learned quite a bit since starting with BitCoin, I will try to sum it all up for anyone who doesn't want to read every post in these forums.

Luke Jr. is never wrong.
Inaba is never wrong.
RealSolid is never wrong.

I can only wait in eager anticipation for the day when EMC adds SC mining, with SC mining added to BFG miner. Then we will truly be living in a utopia!

Askit2

hero member

Activity: 981

Merit: 500

DIV - Your "Virtual Life" Secured and Decentralize

Quote from: Inaba on November 26, 2012, 07:32:50 PM

Are you sure it's not an issue of share leakage?

It's a tad hard to discern. It could be work that got misrouted to us1 pool.... Possibly there is an easy way to tell I haven't noticed in the past?
It happens from time to time. I do agree the other issue with stratum (disconncts lose shares) is a larger loss for me.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: The00Dustin on November 26, 2012, 07:36:42 PM

I hate to interrupt all of this stratum discussion, but I am having crashes with GBT. Running Fedora 15 with SDK 2.1 I think. 2.9.4 would exit with something like error code 11 (or 15 maybe?), and 2.9.5 segfaults. I don't need GBT, so I should probably try to remember to try --fix-protocol instead of switching back to 2.8.7, but for now, I'm on 2.8.7 again. I didn't report the issue with 2.9.4, but I suppose I should've.
ETA: con, note that I wouldn't be against GBT being scrapped/removed from cgminer based on anything I've seen, but from a userbase standpoint, that might not be the option. I'm only providing this most basic info in case it is helpful in some way.

Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full

And post the information from that please.

The00Dustin

hero member

Activity: 807

Merit: 500

I hate to interrupt all of this stratum discussion, but I am having crashes with GBT. Running Fedora 15 with SDK 2.1 I think. 2.9.4 would exit with something like error code 11 (or 15 maybe?), and 2.9.5 segfaults. I don't need GBT, so I should probably try to remember to try --fix-protocol instead of switching back to 2.8.7, but for now, I'm on 2.8.7 again. I didn't report the issue with 2.9.4, but I suppose I should've.
ETA: con, note that I wouldn't be against GBT being scrapped/removed from cgminer based on anything I've seen, but from a userbase standpoint, that might not be the option. I'm only providing this most basic info in case it is helpful in some way.

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