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

[nars28]

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.

[Bazzaar]

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

[fluxy12]

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.

[geck]

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

[vmozara]

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!

[fluxy12]

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

[geck]

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.

[fenomenyaa]

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...

[alucard20724]

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.

[KL0nLutiy1]

@kerney666 very good job  
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?

[dickmo]

          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

[kerney666]

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 .

[kerney666]

@kerney666 very good job  
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.

[joseph32]

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

[wyzdic]

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. 

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

[vmozara]

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.

[kerney666]

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!

[wyzdic]

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.

Yes, me too.

[kerney666]

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.

Yes, me too.

For vmozara's problem, I'm 97% certain this issue would be solved with a staggered init. These Celerons are just too weak for a parallel init for > 2-3 GPUs or something. I'll add some more options now to control the behavior at startup, then send you a PM. Need to wait for todxx to provide a new build, but it would be nice to connect and do a few verification runs instead of just pushing a new version out there not knowing if it actually solves the problem.

@wyzdic, are you having the same issue as vmozara? It feels like we might have a different problem, do you get a random nr of gpus going or always the first six? Furthermore, I've heard about people that have issues in general getting > 6 Vegas going under Linux, are you on Win or some Linux version?

[kerney666]

          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

Well, that is annoying, hmm. Would it be possible for you to check if this is a regression bug in this new version, i.e. since you run lyra2z, if you download and run an older version of the miner on the 18.30 driver, do you still get the same seg fault?