Bitcoin Forum
December 11, 2016, 12:16:30 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 [260] 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4828256 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 09:26:33 AM
 #5181

Con, Luke,

this is from another thread to sort out issues with a throttling BFL Single I have in my 5-unit setup:
[...]
While I am at it, I figured out a SW issue that could be quite relevant for all multi-Single setups driven by cgminer: while I removed the throttling device from the setup for further inspection, the average hashrate of the remaining 4 climbed up noticeably. To double check, I repeatedly run it long enough to exclude variation and this is what I get:
1) running all 5 devices the hashrate for all of them starts at 828 and after running a day the throttling settles at 705 all-time-average, while the properly working ones settle at 790
2) running the 4 proper ones alone, all start at 828 and after the day they are still at ~825

In other words, the throttling one is not just reducing its own hashing power but also those of the proper ones. In my 5-units setup the estimated loss is ~250MH/s.

This could be caused by the communication between PC and Single being frozen during the throttling. From the SW design view there should theoretically be no inter-dependencies, since every device is handled by its own threads. But in practice if the device throttles while communicating to the host and thereby stalls, the related thread will eat its scheduling quantum busy looping the serial port.

Luckily ckolivas is not only cgminer developer but also a Linux scheduler guru, so I'll sort this SW issue out in his thread. Meanwhile I will separate the throttling device from my setup and run it from a different host.

Tl;dr: if you have a multi-BFL Singles setup with one or more throttling units (front LED is blinking now and then) you should consider operating the throttling ones from a different host for a better overall hashrate.

In short, what I am observing is: the one throttling device reproducibly reduces the all-time-average hashrate of the non-throttling devices reported by cgminer (Linux, 2.3.5). I am not sure whether this is just a measurement error or if my assumption with the stalling communication thread causing lags sounds reasonable.

Con, you're da Linux scheduler guru. Any ideas? Since you have no Singles at hand (and even more no reliably throttling ones), I'd try to implement and test potential fixes myself if you had some ideas. Or do you have a throttling one, Luke?


Thanks, zefir

1481458590
Hero Member
*
Offline Offline

Posts: 1481458590

View Profile Personal Message (Offline)

Ignore
1481458590
Reply with quote  #2

1481458590
Report to moderator
1481458590
Hero Member
*
Offline Offline

Posts: 1481458590

View Profile Personal Message (Offline)

Ignore
1481458590
Reply with quote  #2

1481458590
Report to moderator
1481458590
Hero Member
*
Offline Offline

Posts: 1481458590

View Profile Personal Message (Offline)

Ignore
1481458590
Reply with quote  #2

1481458590
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481458590
Hero Member
*
Offline Offline

Posts: 1481458590

View Profile Personal Message (Offline)

Ignore
1481458590
Reply with quote  #2

1481458590
Report to moderator
1481458590
Hero Member
*
Offline Offline

Posts: 1481458590

View Profile Personal Message (Offline)

Ignore
1481458590
Reply with quote  #2

1481458590
Report to moderator
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
April 29, 2012, 09:32:02 AM
 #5182

Any1 can tell me haw to use zteX board? i`m getting error -3 in the beggining. i got 15y board.
In my limited ztex knowledge (nelisky wrote that and I don't have one)
The 15y board supported was added with 2.3.6
(It was in 2.3.5 also but best not to use 2.3.5)

But not in 2.3.4 or earlier

Hm, as of a week ago there was no code base that actually works on the 1.15y IIUC. Nelisky just had committed some preparatory changes for that, but not the actual thing yet.
I'm not sure if this has changed in the meantime, but from what I know (and I'm not really involved deeply here), it could be possible that 2.3.6 simply doesn't support the 1.15y yet. Ask nelisky for details.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
April 29, 2012, 09:33:49 AM
 #5183

Sorry if this is a dumb question ckolivas:

Is there any advantage to having cgminer listen on multiple large pools for LP's even if you have no intention if mining there? For example:

Pool 0 - The real desired pool
Pool 1 -  Large pool number one
Pool 2 - Large pool number two
Pool 3 - Large pool number three
That is not a dumb question at all and in fact you are right in thinking there may be an advantage, but it is complicated.

The reason comes down to what happens at longpoll time. A longpoll occurs when the block on the network has changed. This is the time you are most likely to submit stale shares because you are working on the old block still when the new block is already spreading throughout the network. Furthermore, once the longpoll hits, you have to throw out all work and ask your pool(s) for more work so it is the time you are most likely to have a drop in hashrate while waiting for the new work (this is why the older releases of cgminer used to say waiting for fresh work).

Now because cgminer checks longpolls from *any* pool you are connected to now, it can tell when the block changes on the network often faster than your primary pool finds out because you may be connected to the pool which discovered the block as well. So cgminer then knows to stop working on anything from that old block in anticipation that it will be wasted work. However until your primary pool discovers that the block has changed, you cannot actually get useful work from it. The beauty of longpoll, though, is that it is actually giving cgminer work as well, so you will be getting work from the backup pools to fill in the trough period until your primary pool finds out the block has changed. For this to be useful, though, you do actually have to be happy for the backup pools to get some of your shares over time, and therefore enough shares have to accumulate to eventually give you a payout from them. If you enable the --failover-only option, you lose this benefit because not only will cgminer stop working on the old block before your primary pool discovers the block has changed, but you won't even accept any work your primary pool gives you until then, so it will dip in hashrate for longer.

Note that some pool operators don't really like this behavior because it increases pool load during LPs (and thus stales or other pool users) without actually using the pool much. From what I know some pools even ban you if you do this (submit less than some threshold of shares for a given amount of requested work / long polls).

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
April 29, 2012, 11:23:08 AM
 #5184

Note that some pool operators don't really like this behavior because it increases pool load during LPs (and thus stales or other pool users) without actually using the pool much. From what I know some pools even ban you if you do this (submit less than some threshold of shares for a given amount of requested work / long polls).
Right, I didn't say it was good practice, sanctioned, moral, appropriate or anything else of the sort. Just casting a purely objective observation about what it did.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 29, 2012, 11:49:55 AM
 #5185

...
Note that some pool operators don't really like this behavior because it increases pool load during LPs (and thus stales or other pool users) without actually using the pool much. From what I know some pools even ban you if you do this (submit less than some threshold of shares for a given amount of requested work / long polls).
How would a 'large pool' differentiate that from simply being a 'backup' pool?
Would that really mean that no one should use 'large pools' as backups coz they will ban you or reject your shares ...

Actually I get unexpected middle of the round share's rejected by DeepBit that is my backup ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
os2sam
Legendary
*
Online Online

Activity: 1918


Think for yourself


View Profile
April 29, 2012, 12:44:02 PM
 #5186

I have two asus 5770's running on stock Ubuntu 11.04.  aticonfig can read the gpu temps just fine, but these stats don't appear in cgminer.  I've tried numerous versions of cgminer, AMD sdk's, all with the same results.  Sad

Looks like you may not have ADL support, temps don't show up and your using default clocks it looks like.
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
os2sam
Legendary
*
Online Online

Activity: 1918


Think for yourself


View Profile
April 29, 2012, 12:59:54 PM
 #5187

Code:
[2012-04-29 13:59:37] LONGPOLL from pool 3 detected new block
 [2012-04-29 13:59:39] LONGPOLL from pool 0 requested work restart

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...


I'd donate a BTC or two for a new management strategy that acted on that info.
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
April 29, 2012, 01:08:47 PM
 #5188

Code:
[2012-04-29 13:59:37] LONGPOLL from pool 3 detected new block
 [2012-04-29 13:59:39] LONGPOLL from pool 0 requested work restart

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...


I'd donate a BTC or two for a new management strategy that acted on that info.
Sam
It wouldn't be hard to do now, but realistically for hopping to be worthwhile you need to only do it on prop pools for the maximum benefit, know their hashrate and do it for the magic percentage of duration. Then you have to factor in for different payschemes and how long to stay there and where to hop back to and so on... I had no intention of developing and maintaining such a database, which would be very fluid and change day by day. On the other hand if all you wanted was one that would hop to the pool that found the latest block each time, and you plugged in what pools you wanted it to work on, that would be very easy to do.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
os2sam
Legendary
*
Online Online

Activity: 1918


Think for yourself


View Profile
April 29, 2012, 01:19:43 PM
 #5189

Code:
[2012-04-29 13:59:37] LONGPOLL from pool 3 detected new block
 [2012-04-29 13:59:39] LONGPOLL from pool 0 requested work restart

You now have a way of knowing which pool is LIKELY (though not surely) to have found that block if you have most of the major pools in your set up. This means you now have a way to *cough* choose who to hop to, if you're so inclined...


I'd donate a BTC or two for a new management strategy that acted on that info.
Sam
It wouldn't be hard to do now, but realistically for hopping to be worthwhile you need to only do it on prop pools for the maximum benefit, know their hashrate and do it for the magic percentage of duration. Then you have to factor in for different payschemes and how long to stay there and where to hop back to and so on... I had no intention of developing and maintaining such a database, which would be very fluid and change day by day.

 On the other hand if all you wanted was one that would hop to the pool that found the latest block each time, and you plugged in what pools you wanted it to work on, that would be very easy to do.

That's exactly what came to my mind.  I have no desire to enter the nefarious world of complex pool hopping.  But if my miner always switched the the pool that last found a block, or seems to have, I would always have the confidence I was mining on a active and properly functioning pool.

Several pools have been having problems in recent times where remote servers loose connection to the database and my miner is hashing away happily on a pool that is actually down but doesn't know it.  So when I travel for work I always leave my miner on the pool that has never had this problem, to my knowledge.
Thanks for the thoughts,
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 29, 2012, 02:27:12 PM
 #5190

Some amazing results tonight with Xiangfu's Icarus mining farm running on a single cgminer instance.

It's 1 cgminer with 91 Icarus hashing away at ~33.75GH/s BUT still only using 3% of the CPU in a 32 bit ubuntu linux!

Here's the main API output reformatted to fit here:
Code:
Date: 07:11:39 29-Apr-2012 UTC-07:00
Computer: cgminer 2.3.6       
Elapsed  MHS av    Found Blocks  Getworks  Accepted  Rejected  Hardware Errors       Utility 
19m 22s  33270.28  0             15091     9132      25        0                     471.46/m

  Discarded  Stale   Get Failures  Local Work  Remote Failures  Network Blocks  Total MH
  2740       0       1             18262       0                3               38665911.5942

Date: 07:11:39 29-Apr-2012 UTC-07:00
Computer: cgminer 2.3.6       
GPU Count  PGA Count  CPU Count  Pool Count  ADL  ADL in use  Strategy  Log Interval  Device Code  OS
0          91         0          3           N    N           Failover  5             ICA          Linux   


Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
bombo999
Member
**
Offline Offline

Activity: 107


View Profile
April 29, 2012, 03:34:39 PM
 #5191

Is there a windows binary with bitforce support turned on?
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
April 29, 2012, 06:04:42 PM
 #5192

Is there a windows binary with bitforce support turned on?
Pretty sure it should be in all BitFORCE-capable versions (since like 2.2.0); if not, I know it is for BFGMiner.

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 07:15:59 PM
 #5193

In short, what I am observing is: the one throttling device reproducibly reduces the all-time-average hashrate of the non-throttling devices reported by cgminer (Linux, 2.3.5). I am not sure whether this is just a measurement error or if my assumption with the stalling communication thread causing lags sounds reasonable.

Con, you're da Linux scheduler guru. Any ideas? Since you have no Singles at hand (and even more no reliably throttling ones), I'd try to implement and test potential fixes myself if you had some ideas. Or do you have a throttling one, Luke?

Zefir, I cannot reproduce your observations on cgminer 2.3.4, 2.3.5, or 2.3.6 (under Windows 7 64-bit; I realize you are running on Linux so my observations may not be relevant here).

I have created 2 separate clusters of Singles, and have modified 1 unit in each cluster (by swapping in a too-weak fan) such that it throttles after 5-10 minutes of operation. That is, after 5-10 minutes the front LED blinks, the hashrate drops, temperature drops, it recovers, rinse, lather, repeat.

What I have observed after 24 hours of operation is that ALL of the non-throttling Singles in the cluster average 811-813Mhps (the peak sustained rate of each of my Singles as reported by cgminer is 826Mhps). This rate is unaffected by the presence (or absence) of a throttling unit in the same cluster.

My throttling ones average anywhere from 710-760Mhps. The key thing is that whether they throttle or not, it does not affect the hashrates of the others in the same cluster. Again, this has been my experience with cgminer 2.3.4, 2.3.5, and 2.3.6 under Windows 7 64-bit.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
jddebug
Sr. Member
****
Online Online

Activity: 424



View Profile
April 29, 2012, 07:48:44 PM
 #5194

In short, what I am observing is: the one throttling device reproducibly reduces the all-time-average hashrate of the non-throttling devices reported by cgminer (Linux, 2.3.5). I am not sure whether this is just a measurement error or if my assumption with the stalling communication thread causing lags sounds reasonable.

Con, you're da Linux scheduler guru. Any ideas? Since you have no Singles at hand (and even more no reliably throttling ones), I'd try to implement and test potential fixes myself if you had some ideas. Or do you have a throttling one, Luke?

Zefir, I cannot reproduce your observations on cgminer 2.3.4, 2.3.5, or 2.3.6 (under Windows 7 64-bit; I realize you are running on Linux so my observations may not be relevant here).

I have created 2 separate clusters of Singles, and have modified 1 unit in each cluster (by swapping in a too-weak fan) such that it throttles after 5-10 minutes of operation. That is, after 5-10 minutes the front LED blinks, the hashrate drops, temperature drops, it recovers, rinse, lather, repeat.

What I have observed after 24 hours of operation is that ALL of the non-throttling Singles in the cluster average 811-813Mhps (the peak sustained rate of each of my Singles as reported by cgminer is 826Mhps). This rate is unaffected by the presence (or absence) of a throttling unit in the same cluster.

My throttling ones average anywhere from 710-760Mhps. The key thing is that whether they throttle or not, it does not affect the hashrates of the others in the same cluster. Again, this has been my experience with cgminer 2.3.4, 2.3.5, and 2.3.6 under Windows 7 64-bit.

Epoch,

Damn cool that you would take the time and effort to test that. I wanted to but didn't have time right now.

Thanks for verifying whether the problem was reproducible.

Tip sent.
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 08:24:52 PM
 #5195

[...]
My throttling ones average anywhere from 710-760Mhps. The key thing is that whether they throttle or not, it does not affect the hashrates of the others in the same cluster. Again, this has been my experience with cgminer 2.3.4, 2.3.5, and 2.3.6 under Windows 7 64-bit.

Thanks Epoch for taking your time!

Yes, I'm running my setup from a Linux machine and did most of the measurements with cgminer-2.3.5. Plus, the same process is driving 3 GPUs worth 1.7GH/s that did not suffer while dealing with the throttling Single. I'm building an OpenWRT router to control the proper working units and leave the throttling one attached to the GPU rig.

Lucky you, you had to force your BFL to throttle Smiley

Thanks again. Sent you a coin to at least compensate you for the loss of hashing power during measurement.

Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 08:29:12 PM
 #5196

Epoch,

Damn cool that you would take the time and effort to test that. I wanted to but didn't have time right now.

Thanks for verifying whether the problem was reproducible.

Tip sent.
jjdebug: Completely unnecessary, but much appreciated! For better or worse, I've become quite familiar with Single behavior under temperature throttling due to my obsession with finding a 'quiet' solution to the Singles' stock loud fans.  Wink

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 08:45:51 PM
 #5197

Thanks Epoch for taking your time!

Yes, I'm running my setup from a Linux machine and did most of the measurements with cgminer-2.3.5. Plus, the same process is driving 3 GPUs worth 1.7GH/s that did not suffer while dealing with the throttling Single. I'm building an OpenWRT router to control the proper working units and leave the throttling one attached to the GPU rig.

Lucky you, you had to force your BFL to throttle Smiley

Thanks again. Sent you a coin to at least compensate you for the loss of hashing power during measurement.
Much appreciated, Zefir! Although I'm sure the temporary loss of hashing power was more than compensated for by gaining a better understanding of the Singles' behavior.

Yes, lucky me ... none of my Singles throttle with the stock fans. Wink  I do have some marginal ones now, since I've swapped in slower fans. Apparently, with BFL's EasyMiner software, users will be able to adjust the clocks and that should help the throttling situation. Although that won't help Linux users such as yourself.  Sad

On the topic of cgminer, I've noticed that 'hot removal' is not handled well. If you remove a Single from a hashing cluster, cgminer quits. It doesn't crash or lock up, but it quits. My workaround is calling cgminer in a batch file with a loop. If it quits, the batch file will just call it again. Not a big deal, but it does interrupt mining for half a minute or so while the next instance initializes.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 09:08:30 PM
 #5198

Much appreciated, Zefir! Although I'm sure the temporary loss of hashing power was more than compensated for by gaining a better understanding of the Singles' behavior.

Yes, lucky me ... none of my Singles throttle with the stock fans. Wink  I do have some marginal ones now, since I've swapped in slower fans. Apparently, with BFL's EasyMiner software, we will be able to adjust the clocks and that should help the throttling situation. Let's hope.

On the topic of cgminer, I've noticed that 'hot removal' is not handled well. If you remove a Single from a hashing cluster, cgminer quits. It doesn't crash or lock up, but it quits. My workaround is calling cgminer in a batch file with a loop. If it quits, the batch file will just call it again. Not a big deal, but it does interrupt mining for half a minute or so while the next instance initializes.

You're always friendly and respectful, just my reference on how people should behave on this forum to make a better community.

As for the Singles in your bedroom: water-cooled ones ahead in the pipeline. Time for you to silently raffle away your old loud ones for 150% resale value Wink

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).

What I noticed as problematic (but this might be a Linux specific thing) is, I added cgminer to the autostart service and it usually worked fine with the GPU setup and assured that system is automatically restarted when a card hangs. With the 5 BFLs attached I see every now and then that only two or three of them are detected immediately after reboot. Re-starting cgminer activates them all again. Kind of bad if you plan to leave your miner unattended for two weeks Sad


Edit: sorry you talked about hot-removal, not hot-plugging. With Linux you do not stop cgminer completely. You just stop the threads dedicated to that BFL. If it was the last/only one, then cgminer stops, but otherwise it just continues with one unit less (though statistics are displayed further, no indication that device is gone). Plugging the unit back will not make it operating again automatically.

JBDive
Full Member
***
Offline Offline

Activity: 238


View Profile
April 29, 2012, 09:25:34 PM
 #5199

So I'm more or less a noob at all the ins and outs with cards, drivers and SDK's and have tried to follow more or less what is said here and to stick with the basics when setting up and running various miners. I went ahead and updated my drivers today while leaving the SDK at 2.4 and I'm seeing what I think is small decrease in performance. I also updated from 2.3.1 to 2.3.6 and if anything I find it slower but it could be the drivers.

Anyway that's not really my comment or question. I'm more interested in knowing where the I (intensity) setting comes into play. My command line has been all default except for I 9 forever, mainly because somebody else suggested the setting. Since I was playing with things today I thought I would try other intensity levels to see what happens and the difference was HUGE in terms of CPU use. I found that just about any setting 1-10 resulted in the same 50% CPU use I had been seeing and accepting as normal to only 1-5% CPU use by cgminier using I 7. Now what would CPU cycles be higher at 5 or 6 than 7, as well as 8,9,10 I can understand if it's a rising scale? I'm seeing maybe 7Mh/s less with 2.3.6 and Intensity 7 but my CPU is idling while GPU is maybe a touch hotter but overall machine heat is way down due to lower CPU use.

CARD: 5770
GPU/Mem: 975/350
OS: Win7X64
SDK: 2.4
Catalyst: 12.4
Epoch
Legendary
*
Offline Offline

Activity: 917



View Profile
April 29, 2012, 09:38:44 PM
 #5200

Topic: true, there is no hot-plug support for FPGAs implemented. I understood that it's not safe since auto-detecting routines between different board types collide, i.e. if you scan on serial port X for a single and have actually an Icarus attached, you'd hang in a loop (or vice-versa, not sure).
Hmm, I would have thought the autodetect routines for FPGAs are fine in cgminer. My command line for 2 Singles looks something like this:

Code:
cgminer -o <pool> -u <user> -p <pass> --disable-gpu -S COM6 -S COM7

Notice there is nothing in that command line to tell cgminer that I have a Single, an Icarus, or Ztex. But cgminer detects and starts the Singles on COM6 and COM7 fine.

BTC: 1DJVUnLuPA2bERTkyeir8bKn1eSoRCrYvx
NMC: NFcfHSBBnq622pAr1Xoh9KtnBPA5CUn6id
Pages: « 1 ... 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 [260] 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!