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

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: juhakall on June 08, 2013, 10:50:35 AM

Quote from: -ck on June 08, 2013, 04:18:07 AM

Quote from: juhakall on June 08, 2013, 03:33:00 AM

Somehow my Jalapeno hashrate dropped from 5.75GH/s to about 5.55GH/s.
snip

I don't know but when I first got mine it worked at 6GH for a couple of days and then spontaneously "dropped a gear" after a move and reconnect and it's been 5.7GH ever since. I've never been able to regain that .3 either Huh

I let the Jalapeno idle for 10 minutes and changed the USB header it was connected to. Now it's hashing at 5.75GH/s again. Thanks to KNK at BFL forums for suggesting this! But since the Jalapeno already slowed down once, I'm not so confident anymore that it will keep hashing at 5.75GH/s indefinitely without problems.

Good info, please let us know if you need to do this on a regular basis and how often.
Thanks,
Sam

juhakall

sr. member

Activity: 658

Merit: 250

Quote from: -ck on June 08, 2013, 04:18:07 AM

Quote from: juhakall on June 08, 2013, 03:33:00 AM

Somehow my Jalapeno hashrate dropped from 5.75GH/s to about 5.55GH/s.
snip

I don't know but when I first got mine it worked at 6GH for a couple of days and then spontaneously "dropped a gear" after a move and reconnect and it's been 5.7GH ever since. I've never been able to regain that .3 either Huh

I let the Jalapeno idle for 10 minutes and changed the USB header it was connected to. Now it's hashing at 5.75GH/s again. Thanks to KNK at BFL forums for suggesting this! But since the Jalapeno already slowed down once, I'm not so confident anymore that it will keep hashing at 5.75GH/s indefinitely without problems.

CrazyGuy

legendary

Activity: 1973

Merit: 1007

Quote from: kano on June 08, 2013, 05:15:39 AM

Quote from: aSicPuppy on June 08, 2013, 04:40:52 AM

A few people, including myself, have reported timeouts during get details on linux. This is preventing the Jalepeno from being recognized. Increasing BFLSC_TIMEOUT from 200->999 (might not need to be that high) resolved the issue for me.
usbutils.c, non win_32 define

https://forums.butterflylabs.com/jalapeno-single-sc-support/3135-usb-communications-problems-jalapeno.html

999 means that any time anything is sent to it, it will allow a whole second for a reply.

The command you are reporting is the ZTX during initialisation.
On linux that should NOT take 200ms to reply, let alone a whole second.
Setting every command timeout to a whole second is not really a good design decision ...
Also during that timeout everything else is locked from USB access to the same device.

I'd suggest there is a hardware problem somewhere ...

... and I've not seen anyone else report this either ... you got a link to anyone else?

999 ms might not be necessary, but it definately needs to be more than 200 for some. I'll also add that Cgminer 3.2.1 on Windows did not have this issue. The first thing I tried was matching the win32 timeout. Perhaps some jalepenos are slightly defective...

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: pengoau on June 08, 2013, 08:07:44 AM

Thanks (that worked), do you know what worksize i should be using for my gpus? I've been using 128 just wondering if its worthwhile using 256? Guess I can try and then find out, but if anyone would know for sure you would? thanks again

Also if I use --temp-hysteresis 6 does that mean the fan will kick in at 6 degrees earlier?

cgminer is pretty smart. I wouldn't set the worksize, let cgminer pick it.

M

xiquanpan

newbie

Activity: 12

Merit: 0

failed to reinit gpu thread 0

close the cgminer and restart cgminer it's begin ok

pengoau

full member

Activity: 208

Merit: 100

Thanks (that worked), do you know what worksize i should be using for my gpus? I've been using 128 just wondering if its worthwhile using 256? Guess I can try and then find out, but if anyone would know for sure you would? thanks again

Also if I use --temp-hysteresis 6 does that mean the fan will kick in at 6 degrees earlier?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: pengoau on June 08, 2013, 07:51:08 AM

Yeah I'm using cgminer 3.1.1 I didn't upgrade to 3.2 as it has no improvements for gpus... what is the correct format for cgminer 3.1.1? I'd like to persist with 3.1.1 as "if it aint broke don't fix it" so to speak.... would the format be 0:1? or 0,1?

Thanks for your help.

-d 0 -d 1 --remove-disabled

but note that you cannot save device settings to a configuration file with the old format, hence why the new one has a new format. While there are no GPU specific changes in the newer versions, there are other generic bugfixes, and the "breakage" is only with new drivers, so GPU users should actually be the safest ones to upgrade.

pengoau

full member

Activity: 208

Merit: 100

Quote from: -ck on June 08, 2013, 04:41:41 AM

Quote from: pengoau on June 07, 2013, 09:51:35 PM

Quote from: -ck on June 07, 2013, 09:55:04 AM

Quote from: pengoau on June 07, 2013, 09:53:11 AM

Quote from: -ck on June 07, 2013, 05:27:25 AM

Quote from: pengoau on June 07, 2013, 05:23:14 AM

hey guys

I have 3 gpus in my system 1 apu and 2 dedicated gpus, how can i startup cgminer with the third gpu (gpu 2) turned off? I tried setting intensity to 0 but that doesn't work.

Do I specify it via the -d switch? If so what is the syntax?

Thanks

-d 0-1 --remove-disabled

I added that to my bat file and i get "invalid device number"

fyi:
GPU 0 = 6950
GPU 1 = 5770
GPU 2 = APU

Thanks for your help

What is the output of 'cgminer -n' ?

[2013-06-08 11:52:52] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2013-06-08 11:52:52] CL Platform 0 name: AMD Accelerated Parallel Processing
[2013-06-08 11:52:52] CL Platform 0 version: OpenCL 1.2 AMD-APP (938.2)
[2013-06-08 11:52:52] Platform 0 devices: 3
[2013-06-08 11:52:52] 0 Cayman
[2013-06-08 11:52:52] 1 Juniper
[2013-06-08 11:52:52] 2 Scrapper
[2013-06-08 11:52:52] GPU 0 AMD Radeon HD 6900 Series hardware monitoring enabled
[2013-06-08 11:52:52] GPU 1 ATI Radeon HD 5700 Series hardware monitoring enabled
[2013-06-08 11:52:52] GPU 2 AMD Radeon HD 7480D hardware monitoring enabled
[2013-06-08 11:52:52] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2013-06-08 11:52:52] 3 GPU devices max detected
[2013-06-08 11:52:52] USB all: found 8 devices - listing known devices
[2013-06-08 11:52:52] No known USB devices

Also I'm using worksize of 128, would it better for me to use 256? Or is 256 only good for 7XXX series amd gpus?

All looks fine. However, if it says invalid device number I'm betting you're using an older version of cgminer and it's not accepting device in that format. Upgrade.

Yeah I'm using cgminer 3.1.1 I didn't upgrade to 3.2 as it has no improvements for gpus... what is the correct format for cgminer 3.1.1? I'd like to persist with 3.1.1 as "if it aint broke don't fix it" so to speak.... would the format be 0:1? or 0,1?

Thanks for your help.

runlinux

hero member

Activity: 566

Merit: 500

Quote from: kano on June 08, 2013, 05:15:39 AM

Quote from: aSicPuppy on June 08, 2013, 04:40:52 AM

A few people, including myself, have reported timeouts during get details on linux. This is preventing the Jalepeno from being recognized. Increasing BFLSC_TIMEOUT from 200->999 (might not need to be that high) resolved the issue for me.
usbutils.c, non win_32 define

https://forums.butterflylabs.com/jalapeno-single-sc-support/3135-usb-communications-problems-jalapeno.html

999 means that any time anything is sent to it, it will allow a whole second for a reply.

The command you are reporting is the ZTX during initialisation.
On linux that should NOT take 200ms to reply, let alone a whole second.
Setting every command timeout to a whole second is not really a good design decision ...
Also during that timeout everything else is locked from USB access to the same device.

I'd suggest there is a hardware problem somewhere ...

... and I've not seen anyone else report this either ... you got a link to anyone else?

https://bitcointalksearch.org/topic/m.2406454

Screen shot

bitpop

legendary

Activity: 2912

Merit: 1060

I like one. Multiple would fill my inbox.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: bb000 on June 07, 2013, 07:02:39 PM

This thread is hard to follow - so apologies if this is already posted. Maybe there should be a new one per release?

That almost makes sense. I was tempted to make a new thread every major or minor release update (The version numbers are Major:Minor:Micro 3.2.1 being a micro update and 3.2.0 being a minor update). However that would just mean I'd have to monitor and respond on multiple forum threads. Having all the discussion in one place, even if it is only historically organised, means at least everyone knows where to look or ask for help.

As an aside, major version upgrades are reserved for major hardware support changes (eg going to 3 for ASICs), minor version upgrades are for major internal software changes (eg changes to driver design, new features such as stratum etc) and micro version updates are for mostly bugfixes to stabilise a minor release branch.

What do other people think about having multiple forum threads?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Kuma on June 08, 2013, 03:36:23 AM

Quote from: -ck on June 07, 2013, 06:48:45 PM

Quote from: Kuma on June 07, 2013, 02:44:48 PM

Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash).
It looks there are more HW errors, but I'm not 100% sure.

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

OK, thanks for explanation. I'm sending you "Avalon" tip

.

Much appreciated, thanks

jimmy3dita

hero member

Activity: 588

Merit: 500

Dumb question:

With so many ASIC group buy around, is it possible to setup more workers on the same pool, and let them work together (I.e. no fallback mining)?

Harder part:

Is it possible to allocate a different "quota" of that hashpower to more workers, I.e. 70/30 between two workers on the same pool? Can it be managed with millesimal value?

Thanks

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: aSicPuppy on June 08, 2013, 04:40:52 AM

A few people, including myself, have reported timeouts during get details on linux. This is preventing the Jalepeno from being recognized. Increasing BFLSC_TIMEOUT from 200->999 (might not need to be that high) resolved the issue for me.
usbutils.c, non win_32 define

https://forums.butterflylabs.com/jalapeno-single-sc-support/3135-usb-communications-problems-jalapeno.html

999 means that any time anything is sent to it, it will allow a whole second for a reply.

The command you are reporting is the ZTX during initialisation.
On linux that should NOT take 200ms to reply, let alone a whole second.
Setting every command timeout to a whole second is not really a good design decision ...
Also during that timeout everything else is locked from USB access to the same device.

I'd suggest there is a hardware problem somewhere ...

... and I've not seen anyone else report this either ... you got a link to anyone else?

Polyatomic

sr. member

Activity: 257

Merit: 250

cgminer 3.2.1 running Ztex 1.15y board .

after 4 minutes of mining cgminer stops working with : Failed to set fpga with err -9
: Failed readhashdata with err -99

: Failed readhashdata with err -5

Is this related to the board not getting enough power ?. Is it possible to keep the frequency at 200mhz ?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: pengoau on June 07, 2013, 09:51:35 PM

Quote from: -ck on June 07, 2013, 09:55:04 AM

Quote from: pengoau on June 07, 2013, 09:53:11 AM

Quote from: -ck on June 07, 2013, 05:27:25 AM

Quote from: pengoau on June 07, 2013, 05:23:14 AM

hey guys

I have 3 gpus in my system 1 apu and 2 dedicated gpus, how can i startup cgminer with the third gpu (gpu 2) turned off? I tried setting intensity to 0 but that doesn't work.

Do I specify it via the -d switch? If so what is the syntax?

Thanks

-d 0-1 --remove-disabled

I added that to my bat file and i get "invalid device number"

fyi:
GPU 0 = 6950
GPU 1 = 5770
GPU 2 = APU

Thanks for your help

What is the output of 'cgminer -n' ?

[2013-06-08 11:52:52] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2013-06-08 11:52:52] CL Platform 0 name: AMD Accelerated Parallel Processing
[2013-06-08 11:52:52] CL Platform 0 version: OpenCL 1.2 AMD-APP (938.2)
[2013-06-08 11:52:52] Platform 0 devices: 3
[2013-06-08 11:52:52] 0 Cayman
[2013-06-08 11:52:52] 1 Juniper
[2013-06-08 11:52:52] 2 Scrapper
[2013-06-08 11:52:52] GPU 0 AMD Radeon HD 6900 Series hardware monitoring enabled
[2013-06-08 11:52:52] GPU 1 ATI Radeon HD 5700 Series hardware monitoring enabled
[2013-06-08 11:52:52] GPU 2 AMD Radeon HD 7480D hardware monitoring enabled
[2013-06-08 11:52:52] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2013-06-08 11:52:52] 3 GPU devices max detected
[2013-06-08 11:52:52] USB all: found 8 devices - listing known devices
[2013-06-08 11:52:52] No known USB devices

Also I'm using worksize of 128, would it better for me to use 256? Or is 256 only good for 7XXX series amd gpus?

All looks fine. However, if it says invalid device number I'm betting you're using an older version of cgminer and it's not accepting device in that format. Upgrade.

aSicPuppy

newbie

Activity: 4

Merit: 0

A few people, including myself, have reported timeouts during get details on linux. This is preventing the Jalepeno from being recognized. Increasing BFLSC_TIMEOUT from 200->999 (might not need to be that high) resolved the issue for me.
usbutils.c, non win_32 define

https://forums.butterflylabs.com/jalapeno-single-sc-support/3135-usb-communications-problems-jalapeno.html

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: juhakall on June 08, 2013, 03:33:00 AM

Somehow my Jalapeno hashrate dropped from 5.75GH/s to about 5.55GH/s.
snip

I don't know but when I first got mine it worked at 6GH for a couple of days and then spontaneously "dropped a gear" after a move and reconnect and it's been 5.7GH ever since. I've never been able to regain that .3 either Huh

bitpop

legendary

Activity: 2912

Merit: 1060

I want an avalon as a tip :/

Kuma

member

Activity: 107

Merit: 10

Quote from: -ck on June 07, 2013, 06:48:45 PM

Quote from: Kuma on June 07, 2013, 02:44:48 PM

Are there any known Avalon hashrate regressions? I tried latest FW with 3.2.1 cgminer and both Avalons have lower hasrate (the difference from the last FW is around 1Ghash).
It looks there are more HW errors, but I'm not 100% sure.

The old avalon code lied about the hashrate and lied about the hardware errors. It counted hardware errors as hashrate (and since it's a hardware error it can't be valid hashes that it's doing) and didn't count "no matching work" scenarios as hardware errors. So the new code will appear to have a lower hashrate and a higher hw error count, but in fact it's doing more useful work and just not lying about the rates (along with all the other benefits in the new code).

OK, thanks for explanation. I'm sending you "Avalon" tip

.

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