[ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 149.

kerney666

member

Activity: 658

Merit: 86

Quote from: joseph32 on October 30, 2018, 12:08:38 PM

Done a quick test from release until now, so its about half a day. But haven't optimized anything yet.

Until now: Great job, thank you!

Vega64 LC
Adrenaline 18.6.1, Latest Win10
GPU 1700/1050, Memory 1140/960
Just the standard --cn_config 16+14
Less Power than SRB which is nice, but much more Speed: 2380-2400 per card

Oh my, that's the current official record I think! I haven't run my Vega64 LC at higher memclk than 1105 though, I should probably try it!

vmozara

member

Activity: 190

Merit: 59

Quote from: kerney666 on October 30, 2018, 11:59:16 AM

Quote from: vmozara on October 30, 2018, 10:21:24 AM

Guys,

I need help.

My mining rigs are riserless motherboards with 7x vega.

These boards have Celeron 3885 CPU that appears to be very slow.

When the miner starts, it in parallel initializes each card and connects to the pool. But once the shares start coming, the CPU is busy with something (probably verifying the found shares?) and never completes initialization of some cards. Sometimes 3 cards start, sometimes 6 cards start, sometimes all 7. But I have to manually stop and start the miner many times until I get lucky and initialize all 7 cards.

Is it possible to introduce some delay between card initialization and mining start, or disable CPU share verification?

Thanks!

Will be back at my desk shortly and will provide better feedback. Meanwhile, can you describe the behavior those times you’re lucky and all cards initialize ok, does mining work fine after that in those cases?

I think we need to add an option of doing a staggered initialization and a delay, that no card starts mining before the full init process has completed.

The miner is actually missing on-cpu verification, we didn’t have time to add it, so that’s not the issue at least

.

Whenever the vards initialize or not, the miner works super nice from what I have seen so far. I am busy all day optimizing my rigs for this miner. If some cards don't initialize, miner still works, just displays 0h/s for that card, and CPU usage is high, so he is probably stuck trying to initialize the cards or something.
Then, i just quit the miner and try few times and eventually all cards initialize.

wyzdic

newbie

Activity: 46

Merit: 0

Quote from: kerney666 on October 30, 2018, 11:59:16 AM

Quote from: vmozara on October 30, 2018, 10:21:24 AM

Guys,

I need help.

My mining rigs are riserless motherboards with 7x vega.

These boards have Celeron 3885 CPU that appears to be very slow.

When the miner starts, it in parallel initializes each card and connects to the pool. But once the shares start coming, the CPU is busy with something (probably verifying the found shares?) and never completes initialization of some cards. Sometimes 3 cards start, sometimes 6 cards start, sometimes all 7. But I have to manually stop and start the miner many times until I get lucky and initialize all 7 cards.

Is it possible to introduce some delay between card initialization and mining start, or disable CPU share verification?

Thanks!

Will be back at my desk shortly and will provide better feedback. Meanwhile, can you describe the behavior those times you’re lucky and all cards initialize ok, does mining work fine after that in those cases?

I think we need to add an option of doing a staggered initialization and a delay, that no card starts mining before the full init process has completed.

The miner is actually missing on-cpu verification, we didn’t have time to add it, so that’s not the issue at least

.

I have 8 vegas and celeron 847, No matter how many times restart, can only start 6 cards. Cry

Code:

[2018-10-31 00:23:07] Successfully initialized GPU 0: Vega with 56 CU (PCIe 16:00.0) (CN 16+14)
[2018-10-31 00:23:08] Successfully initialized GPU 1: Vega with 56 CU (PCIe 10:00.0) (CN 16+14)
[2018-10-31 00:23:09] Successfully initialized GPU 2: Vega with 56 CU (PCIe 03:00.0) (CN 16+14)
[2018-10-31 00:23:10] Successfully initialized GPU 3: Vega with 56 CU (PCIe 19:00.0) (CN 16+14)
[2018-10-31 00:23:11] Successfully initialized GPU 4: Vega with 56 CU (PCIe 07:00.0) (CN 16+14)
[2018-10-31 00:23:11] Successfully initialized GPU 5: Vega with 56 CU (PCIe 22:00.0) (CN 16+14)

[2018-10-31 00:23:42] Stats GPU 0 - cnv8: 1.664kh/s, avg 1.387kh/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 1 - cnv8: 1.680kh/s, avg 1.423kh/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 2 - cnv8: 1.661kh/s, avg 1.468kh/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 3 - cnv8: 1.641kh/s, avg 1.508kh/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 4 - cnv8: 1.606kh/s, avg 1.484kh/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 5 - cnv8: 1.667kh/s, avg 1.588kh/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 6 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats GPU 7 - cnv8:   0.0 h/s, avg   0.0 h/s, pool   0.0 h/s 0/0
[2018-10-31 00:23:42] Stats Total - cnv8: 9.918kh/s, avg 8.859kh/s, pool   0.0 h/s

joseph32

member

Activity: 412

Merit: 21

Done a quick test from release until now, so its about half a day. But haven't optimized anything yet.

Until now: Great job, thank you!

Vega64 LC
Adrenaline 18.6.1, Latest Win10
GPU 1700/1050, Memory 1140/960
Just the standard --cn_config 16+14
Less Power than SRB which is nice, but much more Speed: 2380-2400 per card

kerney666

member

Activity: 658

Merit: 86

Quote from: KL0nLutiy1 on October 30, 2018, 11:13:11 AM

@kerney666 very good job Shocked

Just tested under Hive OS (drivers 18.10) on rx 480 4gb (elpida) 1250/950 1950/950 hashrate is 990 - 1000 depend on the card.
Do you plan to add other CN variants like arto, stellite and others? If yes could you add algo switching like SRBminer?

This was a big investment time-wise, we had to build all the support for CN stratum mining etc, so it’d be very unwise for us to not add more variants

. We might also add an algo switching scheme, but haven’t decided yet.

kerney666

member

Activity: 658

Merit: 86

Quote from: vmozara on October 30, 2018, 10:21:24 AM

Guys,

I need help.

My mining rigs are riserless motherboards with 7x vega.

These boards have Celeron 3885 CPU that appears to be very slow.

When the miner starts, it in parallel initializes each card and connects to the pool. But once the shares start coming, the CPU is busy with something (probably verifying the found shares?) and never completes initialization of some cards. Sometimes 3 cards start, sometimes 6 cards start, sometimes all 7. But I have to manually stop and start the miner many times until I get lucky and initialize all 7 cards.

Is it possible to introduce some delay between card initialization and mining start, or disable CPU share verification?

Thanks!

Will be back at my desk shortly and will provide better feedback. Meanwhile, can you describe the behavior those times you’re lucky and all cards initialize ok, does mining work fine after that in those cases?

I think we need to add an option of doing a staggered initialization and a delay, that no card starts mining before the full init process has completed.

The miner is actually missing on-cpu verification, we didn’t have time to add it, so that’s not the issue at least

.

dickmo

newbie

Activity: 6

Merit: 0

Team Red Miner version 0.3.4
[2018-10-30 15:25:55] Pool gin.f2pool.com successfully subscribed.
[2018-10-30 15:25:55] Pool gin.f2pool.com authorization succeeded.
[2018-10-30 15:25:55] Pool gin.f2pool.com set difficulty to 15.999756
[2018-10-30 15:25:55] Pool gin.f2pool.com received new job. (job_id: aKXuutTIJS)
[2018-10-30 15:25:55] Successfully initialized GPU 0: Vega with 56 CU (PCIe 10:00.0)
[2018-10-30 15:25:55] Successfully initialized GPU 1: Vega with 56 CU (PCIe 0d:00.0)
[2018-10-30 15:25:55] Dev pool connected and ready.
[2018-10-30 15:25:55] Successfully initialized GPU 2: Vega with 56 CU (PCIe 09:00.0)
Segmentation fault

i just upgrade amd-gpupro driver from 18.10 to 18.30 on hiveos(ubuntu 16.04.5),then start like above

KL0nLutiy1

newbie

Activity: 88

Merit: 0

@kerney666 very good job Shocked

Just tested under Hive OS (drivers 18.10) on rx 480 4gb (elpida) 1250/950 1950/950 hashrate is 990 - 1000 depend on the card.
Do you plan to add other CN variants like arto, stellite and others? If yes could you add algo switching like SRBminer?

alucard20724

sr. member

Activity: 703

Merit: 272

Quote from: geck on October 30, 2018, 10:52:52 AM

Quote from: fluxy12 on October 30, 2018, 10:23:58 AM

Quote from: geck on October 30, 2018, 10:21:00 AM

hi,

im not able to get it to work with my vega64 or 8x vega56.
on both rigs i get the same error message “Failed to initialize device number 0.”

ive tried using -d 1, but then the error becomes device 1 is out of range.

any ideas on what to try next?

edit forgot to mention im on win 10 and 18.6.1 drivers

Have you tried this ?

--platform=1

hi,
yes, i have tried that. Did not work either.

turn off hbcc... it's probably recognizing it has gfx901.

fenomenyaa

jr. member

Activity: 127

Merit: 2

Quote from: vmozara on October 30, 2018, 10:21:24 AM

Guys,

I need help.

My mining rigs are riserless motherboards with 7x vega.

These boards have Celeron 3885 CPU that appears to be very slow.

When the miner starts, it in parallel initializes each card and connects to the pool. But once the shares start coming, the CPU is busy with something (probably verifying the found shares?) and never completes initialization of some cards. Sometimes 3 cards start, sometimes 6 cards start, sometimes all 7. But I have to manually stop and start the miner many times until I get lucky and initialize all 7 cards.

Is it possible to introduce some delay between card initialization and mining start, or disable CPU share verification?

Thanks!

Same problem here,2-3 cards starts even a g4560 cpu with polaris series. No problem with vegas...

geck

member

Activity: 145

Merit: 10

Quote from: fluxy12 on October 30, 2018, 10:23:58 AM

Quote from: geck on October 30, 2018, 10:21:00 AM

hi,

im not able to get it to work with my vega64 or 8x vega56.
on both rigs i get the same error message “Failed to initialize device number 0.”

ive tried using -d 1, but then the error becomes device 1 is out of range.

any ideas on what to try next?

edit forgot to mention im on win 10 and 18.6.1 drivers

Have you tried this ?

--platform=1

hi,
yes, i have tried that. Did not work either.

fluxy12

jr. member

Activity: 145

Merit: 1

Quote from: geck on October 30, 2018, 10:21:00 AM

hi,

im not able to get it to work with my vega64 or 8x vega56.
on both rigs i get the same error message “Failed to initialize device number 0.”

ive tried using -d 1, but then the error becomes device 1 is out of range.

any ideas on what to try next?

edit forgot to mention im on win 10 and 18.6.1 drivers

Have you tried this ?

--platform=1

vmozara

member

Activity: 190

Merit: 59

Guys,

I need help.

My mining rigs are riserless motherboards with 7x vega.

These boards have Celeron 3885 CPU that appears to be very slow.

When the miner starts, it in parallel initializes each card and connects to the pool. But once the shares start coming, the CPU is busy with something (probably verifying the found shares?) and never completes initialization of some cards. Sometimes 3 cards start, sometimes 6 cards start, sometimes all 7. But I have to manually stop and start the miner many times until I get lucky and initialize all 7 cards.

Is it possible to introduce some delay between card initialization and mining start, or disable CPU share verification?

Thanks!

geck

member

Activity: 145

Merit: 10

hi,

im not able to get it to work with my vega64 or 8x vega56.
on both rigs i get the same error message “Failed to initialize device number 0.”

ive tried using -d 1, but then the error becomes device 1 is out of range.

any ideas on what to try next?

edit forgot to mention im on win 10 and 18.6.1 drivers

fluxy12

jr. member

Activity: 145

Merit: 1

Quote from: todxx on October 30, 2018, 04:28:15 AM

Quote from: fluxy12 on October 30, 2018, 03:16:01 AM

Hello tested on windows 10 with 6*RX580, it doesn't launch unfortunatly. i tryed without Antivirus and without OC.

I got the message "failed to list OpenCL devices".

Can it be a driver problem ? i have blockchain drivers.

Thank you

Hi flux,
As rubine mentioned, it's likely that you have more than one opencl platform, and the miner uses the first platform by default.
If adding the --platform=1 option that rubine suggested doesn't work, could you run clinfo on the command line and post the output?

Thank you it works now with this tip.

Bazzaar

jr. member

Activity: 75

Merit: 1

Fantastic jobs guys!
You have completely eliminated the drop in profitability that the fork from CN/1 to CN/2 introduced.
4x Vegas making 8000+ h/s @ 840W

Cheers!

Baz

nars28

newbie

Activity: 25

Merit: 0

Mining directly to exchange does not work as you have to specify payment id. Miner can't login to nanopool using:
-u address.payment-id.user

However it works using:
-u address.user

Can you fix login to pool with payment-id included so i can mine directly to exchange?

Thank you.

todxx

member

Activity: 176

Merit: 76

Quote from: dragonmike on October 30, 2018, 05:27:53 AM

I tested this last night on two rigs (RX570's and Vega 56's).
Great work indeed. It's hands down the fastest and least power-consuming CN miner around.

For everyone's benefit, I got most hashrate using --cn_config=7+7 on the 570's and 16+14 on the Vegas so far, for virtually no increase in power draw. Net net a gain of about 4% hashrate at 7% less power than SRBminer.

Well done.

EDIT: looking forward to you releasing the same sort of improvements on the other CN variants (heavy/heaven/fast etc) and other algos that are grossly unoptimised for AMD hardware (looking at you x16r)! Wink

Thanks for helping with the early testing dragonmike! It really helps to have some outside validation of our numbers as a bit of a sanity check before a release

As for CN variants and other new algos, we will be adding more, but it may be a little while. This last push to get CNv8 from the drawing board and into production has taken over a month of full time work on both our parts and we both need a bit of a breather after this one. That said, adding CN variants now that we have the general CN infrastructure in place should be much easier. We've also done some very initial work on x16r and it looks like there's plenty of room for improvement, but at this point we can't make any promises on what we'll be able to release and when.

Quote from: dragonmike on October 30, 2018, 06:27:15 AM

what clocks?

EDIT: sidenote... for the lulz I increased clock speeds on the Vega56's to 1590... Hashrate went up to 2150 h/s! Grin

But power went up quite massively as well (over 225W per GPU).

Haha, I just spent a couple hours pushing my Vega FE too. I managed to hit just over 2400h/s running at 1610MHz core and 1195MHz mem clocks! Grin

The card was pulling about 300W alone so not very useful, but I love seeing that 2400h/s readout!

Quote from: stolarzz on October 30, 2018, 06:19:49 AM

Quote

Have you tried using --cn_config=7+7 ?

Yup there is no change at all. All my AMD's are 4GB and never get more than 820kh with cryptonight Sad

Do you know what type of memory is on your card?
I have some MSI RX470 mining edition cards that have Micron memory and so far I can only get them to about 850h/s with the best straps I could find.

Quote from: vmozara on October 30, 2018, 07:00:32 AM

this looks promising.

Especially in a sea of viruses and trojan miners that we had here. I wish i had any lefover merit to give to you

I tested at my home PC and now i will proceed to update my rigs. It seems your dev fee is high but it is well deserved.

Test at home PC: Adrenalin 18.10.2, win 10 1809, vega 64 custom cooling, power table 85% from vega guide (unfortunate vega), core 1550/900 mem 1150/900

All consumption below is entire system consumption from the wall

JCE miner: 2080H/s @ 300W
SRBminer: 2130H/s @ 300W
TeamRedMiner: 2300H/s @ 285W

Shocked

I will provide here results from optimized Vega rigs later on.

Is there any special driver version you recommend for Vega?

Thanks!

Thanks vmozara! Nice to see someone else out there pushing the higher 2300+ hashrates

As for the driver version, we have done most of our testing on 18.6.1, so I would consider that the safest bet. I believe kerney saw some issues with Vegas running the old blockchain drivers, so I would avoid those for Vegas.

Quote from: N2DCRYPT on October 30, 2018, 07:06:04 AM

Posting to confirm that the advertised hashrates and power draws for this miner are legitimate. Quite an impressive release from kerney666 and todxx; personally, I've had issues switching over rigs to v8 because of the increased power draw, and this miner has alleviated those problems, while giving increased hashrate!

My Vega 64s are currently working at about 2100 H/s and Vega 56's are running 2000 H/s with lower power draw and higher hashrates than I was running on SRBMiner.

Thanks for helping with the early testing N2DCRYPT! We really appreciate you taking the time to kick the tires before the release!
Also I'm glad we could help get your rigs back into their old power profiles

Quote from: dafuzz_rsa on October 30, 2018, 07:06:22 AM

Absolutely amazing results. Well done!
Looking forward to seeing what else you guys have to offer

Thanks dafuzz_rsa! We're looking forward to cranking out some new algos after we take a little bit of a breather

N2DCRYPT

jr. member

Activity: 148

Merit: 5

Quote from: vmozara on October 30, 2018, 07:00:32 AM

Is there any special driver version you recommend for Vega?

Vmozara, the Adrenalin 18.6.1 drivers should work well; and that's what I'm running on all of mine--anything older than that tends to have problems with v8.

dafuzz_rsa

newbie

Activity: 40

Merit: 0

Absolutely amazing results. Well done!
Looking forward to seeing what else you guys have to offer

Topic: [ANN] TeamRedMiner v0.10.10 - Ironfish/Kaspa/ZIL/Kawpow/Etchash and More - page 149. (Read 211432 times)