Author

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

full member
Activity: 158
Merit: 100
up and running with all devices

did not get the --nfu-bits working in cgminer.conf
so i give it in commandline

Now i have to have a look whats about the hashpower compare to bfgminer
and how long it will run    Grin

thanks for help
full member
Activity: 158
Merit: 100
Hi

ok i will do like i did for the BiFury and redfury.

I will install the winusb-driver with zadig to point to the nanofurys and will than have all devices in the 4.0.1 Cgminer
Then we can see if it crashes again, if so i will send you the debug information! D'accord ?

stay tuned
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Ok i will try out your link these evening at home.

Yes i can move the NF1 devices to cgminer but the crashing of it  will be the same and i do not have access to my home-rig any given time (so that will cost a lot of hashpower for me).

Debugging cgminer and having it stable and than moving the NF1 to it would be my preferable way

Unless the crashing is because the software is fighting over the device in which case it will go away.

I tried Version 3.8.5/3.9/3.12.3 ----> these version did not complain about NF1-Devices (but maybee fighting anyway for that devices)

the charm of the NF1 devices (you do not need a spezial driver for it for BFGMiner) they will be install as a USB-Hid devices by windows 7 and BFGMiner just grab them.
That is not charm, everything uses the WinUSB driver on windows on cgminer - you install one driver for everything and just associate it with your device if you ever get a different type of device. Saying a driver happens to work for a piece of software is not really something special...

And coincidentally, I happen to have all the devices you're describing.

Code:
  0: NF1  0:                         | 2.577G/2.565Gh/s | A:  16140 R:    0 HW:     0 WU:   35.9/m
  3: NF1  1:                         | 2.111G/2.099Gh/s | A:   8070 R:    0 HW:     0 WU:   29.4/m
  4: BXF  0:  44.8C                  | 5.036G/5.010Gh/s | A:  52596 R:    0 HW:     0 WU:   70.2/m
  8: BF1  0:                         | 2.368G/2.368Gh/s | A:  15375 R:    0 HW:  1640 WU:   33.1/m
And they all work fine on my rig.

Once the drivers are set up on cgminer, you can plug and unplug as many of those same devices as you like and cgminer will hotplug and unplug them without any further intervention.
full member
Activity: 158
Merit: 100
Ok i will try out your link these evening at home.

Yes i can move the NF1 devices to cgminer but the crashing of it  will be the same and i do not have access to my home-rig any given time (so that will cost a lot of hashpower for me).

Debugging cgminer and having it stable and than moving the NF1 to it would be my preferable way

Unless the crashing is because the software is fighting over the device in which case it will go away.

I tried Version 3.8.5/3.9/3.12.3 ----> these version did not complain about NF1-Devices (but maybee fighting anyway for that devices)

the charm of the NF1 devices (you do not need a spezial driver for it for BFGMiner) they will be install as a USB-Hid devices by windows 7 and BFGMiner just grab them.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Guys, if you get a crash, debugging information will help everyone long term since that's how I'll actually get to fix the bugs. This is not a closed source proprietary piece of hidden software, it is a community project  despite the fact there are only a very small number of developers, and we need information from the users as much as they need our code. While I'm forever developing code for new features and drivers, I am seriously interested in stability over anything else. My rigs run for months without a crash and that's how I want it to be for the other users, but I don't have all hardware combinations on all operating systems (nor do I even want that). I've debugged a LOT of issues courtesy of debug traces, logins into other people's machines and bug reports and so on that would never have been fixed otherwise.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Ok i will try out your link these evening at home.

Yes i can move the NF1 devices to cgminer but the crashing of it  will be the same and i do not have access to my home-rig any given time (so that will cost a lot of hashpower for me).

Debugging cgminer and having it stable and than moving the NF1 to it would be my preferable way

Unless the crashing is because the software is fighting over the device in which case it will go away.
full member
Activity: 158
Merit: 100
But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)
Every single USB device on cgminer uses exactly the same USB driver. Crashes should never happen, and any debugging would be most appreciated as per:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If you're not interested in helping the developers debug issues with the software you're depending on for free, feel free to read how to use the --usb command (as Kano has suggested) from the readme, to choose only the devices you want it to work on.

Sury i like to help..........but the problem is: Most of the times cgminer crashes when i'am on work (the rig is at home) or in the night when i'am sleeping so i could only see the windows hint (cgminer applikation has an error and has to be closed)


So just tell me how i can help !

stay tuned
Well I already gave you a link to the instructions on how to help... but by far the easiest thing for you to do is just mine with everything on cgminer as the NF1 devices as they're called by cgminer are fully supported, and you set them up exactly as you set up every other USB device you've used so far on cgminer so it's about 10 seconds' work.

Ok i will try out your link these evening at home.

Yes i can move the NF1 devices to cgminer but the crashing of it  will be the same and i do not have access to my home-rig any given time (so that will cost a lot of hashpower for me).

Debugging cgminer and having it stable and than moving the NF1 to it would be my preferable way
sr. member
Activity: 252
Merit: 250
Sentinel
Good morning


is there any way to tell cgminer (newest version) not to use some devices?

Story:

I'am using some NFY-Devices with BFGMiner. (stable for now more than 4 month)
But i did not get my BiFury and Redfury running with BFGMiner so i use CGMiner for these.

The last weeks CGMiner is starting crashing constantly every 6-10 hours. (with usblib errors on alternating devices)
So i downloaded the 4.0.1 Version and it is more stable (crash every 18-24 hours)

But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)

So any hint are very welcome

I ran into a similar problem (3x BlueFury v2 and 1x BiFury).
The RAM usage of cgminer (any version) keeps creeping up on me and at some point (some 400-500MB usage) it will eventually crash.

My solution that worked for me so far :
Installed CGwatcher and set it up simply to auto-restart cgminer every 6 hours and in case it quits/crashes otherwise or drops below a certain threshhold (i.e. a USB device dropped offline).

Except for one single occasion in ~2 months, the system ran without issues ever since (after otherwise crashing almost daily, typically overnight or when I was a work Tongue )
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)
Every single USB device on cgminer uses exactly the same USB driver. Crashes should never happen, and any debugging would be most appreciated as per:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If you're not interested in helping the developers debug issues with the software you're depending on for free, feel free to read how to use the --usb command (as Kano has suggested) from the readme, to choose only the devices you want it to work on.

Sury i like to help..........but the problem is: Most of the times cgminer crashes when i'am on work (the rig is at home) or in the night when i'am sleeping so i could only see the windows hint (cgminer applikation has an error and has to be closed)


So just tell me how i can help !

stay tuned
Well I already gave you a link to the instructions on how to help... but by far the easiest thing for you to do is just mine with everything on cgminer as the NF1 devices as they're called by cgminer are fully supported, and you set them up exactly as you set up every other USB device you've used so far on cgminer so it's about 10 seconds' work.
full member
Activity: 158
Merit: 100
But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)
Every single USB device on cgminer uses exactly the same USB driver. Crashes should never happen, and any debugging would be most appreciated as per:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If you're not interested in helping the developers debug issues with the software you're depending on for free, feel free to read how to use the --usb command (as Kano has suggested) from the readme, to choose only the devices you want it to work on.

Sury i like to help..........but the problem is: Most of the times cgminer crashes when i'am on work (the rig is at home) or in the night when i'am sleeping so i could only see the windows hint (cgminer applikation has an error and has to be closed)


So just tell me how i can help !

stay tuned
full member
Activity: 158
Merit: 100
Good morning

is there any way to tell cgminer (newest version) not to use some devices?

...

So any hint are very welcome
What does ./cgminer -n say?

You may be able to ignore them with --usb

failed to open USB DEV4 - DEV13 err -12

Thanks for helping!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)
Every single USB device on cgminer uses exactly the same USB driver. Crashes should never happen, and any debugging would be most appreciated as per:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If you're not interested in helping the developers debug issues with the software you're depending on for free, feel free to read how to use the --usb command (as Kano has suggested) from the readme, to choose only the devices you want it to work on.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Good morning

is there any way to tell cgminer (newest version) not to use some devices?

...

So any hint are very welcome
What does ./cgminer -n say?

You may be able to ignore them with --usb
full member
Activity: 158
Merit: 100
Good morning


is there any way to tell cgminer (newest version) not to use some devices?

Story:

I'am using some NFY-Devices with BFGMiner. (stable for now more than 4 month)
But i did not get my BiFury and Redfury running with BFGMiner so i use CGMiner for these.

The last weeks CGMiner is starting crashing constantly every 6-10 hours. (with usblib errors on alternating devices)
So i downloaded the 4.0.1 Version and it is more stable (crash every 18-24 hours)

But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)

So any hint are very welcome
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Kinda hard writing code for 333MH and 50TH setups at the same time.

Well that piqued my curiosity...
Icedrill still don't have the controllers they require to run all the Sierras they're getting from hashfast. This means a LOT of devices are being attached to less controllers(PCs running cgminer), and to make matters worse, the hashfast devices don't actually ntime roll internally in their firmware the way the documentation claims, which means cgminer has to actually generate every single work item for these devices, which is usually ~2300 at a time. We found the i3 in one laptop could reliably run about 50TH of Sierras. Note that this is thousands of time more work than a pool receiving and processing 50TH of shares.

...gotta love the efficiency of well written c code.
member
Activity: 117
Merit: 10
Kinda hard writing code for 333MH and 50TH setups at the same time.

Well that piqued my curiosity...
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" Smiley.
Seriously, that's a bad idea in general.
It means anyone with any access (local or remote) to your miner can change anything they like ... including who it mines for.
That's what KFC put in their miners originally, no idea if they ever fixed it.

Also, 192.168/16 will also work
legendary
Activity: 952
Merit: 1000
Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" Smiley.
W:192.168.0.0/16 would allow anyone on the 192.168.x.x range.
full member
Activity: 128
Merit: 100
Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" Smiley.
sr. member
Activity: 295
Merit: 250
I changed the queue size to auto adjust every time it hits zero now since it shouldn't - and there are devices with massive hashrates that need a huge queue to keep busy. Unfortunately that seems to be fighting with you trying to set it to zero, but that shouldn't actually drop the hashrate unless you're running out of cpu. So yeah it's not ideal. Kinda hard writing code for 333MH and 50TH setups at the same time. Lemme think about it. This might need a new command line option.
Awesome, thanks for the update.  I'm not worried about the restart, so long as you're aware of it and it isn't a symptom of something else being broken.  Exit/restart works fine for me.

For the other, could I set the work queue to 1 as a workaround? Or would the system still try to raise it?

As for CPU, that's possible, I guess.  I'm running on a decade-or-so old Pentium dual-core box.  I'll see if I can set up some kind of CPU monitoring.
Jump to: