Bitcoin Forum
December 07, 2016, 06:36:05 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 [352] 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4821702 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.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
September 11, 2012, 11:28:00 PM
 #7021

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Where as each mining device could be asychronous. The device gets work from the queue when its idle, submits it when it's done. The device calls the shots... calls the routine to get work, calls the routine to submit work.
@ckolivas could better answer this, but I think that a thread per mining device is not such a bad thing: a benefit is that in case of a GPU crashing, if the driver goes nuts it often doesn't bring all cards down but only one GPU.
With an event-based system, a single process will access all devices : a blocked syscall would freeze the entire process.
Usually I prefer event-based systems for handling asynchronous tasks, but here threads might well be the better option.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
1481135765
Hero Member
*
Offline Offline

Posts: 1481135765

View Profile Personal Message (Offline)

Ignore
1481135765
Reply with quote  #2

1481135765
Report to moderator
1481135765
Hero Member
*
Offline Offline

Posts: 1481135765

View Profile Personal Message (Offline)

Ignore
1481135765
Reply with quote  #2

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

Activity: 1358



View Profile WWW
September 11, 2012, 11:31:21 PM
 #7022

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Great. I expected that it is related to the protocol proposal. I was surprised because actually it *is* event driven :-)

Quote from: eleuthria
That would be 75,600,000,000,000,000 TH/s (pretty sure I calculated that right).  Also known as future proof Smiley.
Quote

:-)

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 11, 2012, 11:55:16 PM
 #7023

Hello ckolivas,

any chance to add native support for Stratum mining protocol?

http://mining.bitcoin.cz/stratum-mining

There're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code.

The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs.

Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better.

Let me know what you think about it!
Until ckolivas returns and gives his opinion, which may be completely different to mine ...
As an aside ... I will repeat comments I've made (here and elsewhere) about this generic idea, and add to them:

Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.

This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.

I'm certainly not saying yes or no about implementing getmemorypool (which is where your idea actually comes from) however, noting the implications of it, I've wondered if anyone has considered them in detail (I've also had a quick click on the web link and the very first item has an issue in my opinion - the pool deciding when the miner should be given work ...)

I will also make comment on performance:
There are a bunch on simple improvements to the getwork protocol that could easily extend the life of the current protocol.
Simplest one would be reference information so that a share returned only requires 3 things: reference, nonce, time
and the getwork would only need to send: reference, version, prevblk, merkle, time, diff
There is a LOT of blank space in the getwork data - so comparing sizes is rather meaningless unless the blanks were removed ...
LP sux due to it's design (was Tycho drunk that night he designed it?) - and there are other options already available.

The roll-n-time hack only exists coz the bitcoin devs are wimps and can't do a hard fork (since they can't even smoothly do a soft fork) and fix the MSDOS restriction of the nonce size.
A nonce size increase would mean that the timing of when the miner would talk to the pool (or the local "Stratum" program) would only be at a frequency decided necessary to include new transactions or maybe also via notification due to a large fee transaction.
The simple problem is that with any such protocol using the current nonce size, the miner MUST talk to the work source (be it part of the same program, a local "Stratum" program, or a pool) every ~4billion hashes - which is not a big number when the miner could EASILY have multiple TerraHash/second - i.e. plug in a few if BFL's so called soon to come 1TH/s devices
I seriously don't understand why anyone coming up with these similar 'Stratum' ideas doesn't spot the obvious problem there, that is directly caused by the nonce size.
Moving to using an extra-nonce in the coinbase transaction is again only needed since the block header nonce is too small - yet there is PLENTY of space to increase it's size in the sha256 empty space ... to 128 bits without any issue.
The miner would never run out of work, before it needs to consider a work change, with a 128bit nonce (well maybe not for a few years at least Smiley
Using the 'extra-nonce' idea also means that the mining software is spending a LOT of unnecessary effort talking to the work source (and the work source is doing way more work than necessary) that a larger nonce size would remove.

Just to put that into context:
a 1TH/s device can of course hash 1,000,000,000,000 hashes a second.
However, since the nonce size is 2^32, that means it will need to interact with the work source 232.8 times a second (without using roll-n-time)

Does anyone not one see that ANY change is a VERY short term solution ignoring fixing the size of the internal nonce?

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
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
September 12, 2012, 12:02:59 AM
 #7024

Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.

This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.

I don't think you understand the protocol entirely.  The pool is still doing ALL of the bitcoind work.  It is creating the merkle branch list (picking the transactions and building the block essentially).  All it's doing is allowing the miner to adjust a piece of the coinbase transaction, which creates a new merkleroot, thus allowing it to continue hashing without interacting with the pool server once it runs out of nonce space or ntime rolling.


Just to put that into context:
a 1TH/s device can of course hash 1,000,000,000,000 hashes a second.
However, since the nonce size is 2^32, that means it will need to interact with the work source 232.8 times a second (without using roll-n-time)

Does anyone not one see that ANY change is a VERY short term solution ignoring fixing the size of the internal nonce?

That's why we're suggesting a new protocol which adds extremely light overhead.  The miner only needs to perform 1 extra hash per power of 2 transactions being included in the block.  There is no interacting with the work source if the miner supports it natively.  It can prepare the next piece of work in advance with CPU (on average this would be between 7 and 10 hashes, and it will likely never go beyond 12-14 (2^12 - 2^14 transactions in one block).

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 12:03:52 AM
 #7025

And while you're at it, change the mining API to event-driven Smiley

What do you mean exactly?

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Where as each mining device could be asychronous. The device gets work from the queue when its idle, submits it when it's done. The device calls the shots... calls the routine to get work, calls the routine to submit work.
I've already discussed this with ckolivas in the past.

cgminer C code being executed on a CPU is ... quite ... fast.

The delay is simply the verification of the share and the determination of the next getwork data (which is not a network getwork, cgminer already has the next piece of work necessary in most cases, and in the other cases it is not avoidable - getwork send and receive is already asynchronous)

The performance gain would be small and possibly not even noticeable at the scale of data reported by cgminer ... though on a slow old crappy CPU, that may or may not be the case.
To put that into context, if you have spent 10's of thousands of dollars on hashing hardware, get a normal CPU to run cgminer Tongue

My timing code already shows you information about that delay in the API stats command ...

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
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 12:10:17 AM
 #7026

Just to put that into context:
a 1TH/s device can of course hash 1,000,000,000,000 hashes a second.
However, since the nonce size is 2^32, that means it will need to interact with the work source 232.8 times a second (without using roll-n-time)

Does anyone not one see that ANY change is a VERY short term solution ignoring fixing the size of the internal nonce?

That's why we're suggestion a new protocol which adds extremely light overhead.  The miner only needs to perform 1 extra hash per power of 2 transactions being included in the block.  There is no interacting with the work source if the miner supports it natively.  It can prepare the next piece of work in advance with CPU (on average this would be between 7 and 10 hashes, and it will likely never go beyond 12-14 (2^12 - 2^14 transactions in one block).
... yes the work source will need to do this work load.

Be the work source remote, local, or even included in the code.

My point is that the solution seems to be short term ... it's resource requirements do not seem to be many orders of magnitude smaller than the resources available.

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
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
September 12, 2012, 12:10:46 AM
 #7027

I've already discussed this with ckolivas in the past.

cgminer C code being executed on a CPU is ... quite ... fast.

The delay is simply the verification of the share and the determination of the next getwork data (which is not a network getwork, cgminer already has the next piece of work necessary in most cases, and in the other cases it is not avoidable - getwork send and receive is already asynchronous)

The performance gain would be small and possibly not even noticeable at the scale of data reported by cgminer ... though on a slow old crappy CPU, that may or may not be the case.
To put that into context, if you have spent 10's of thousands of dollars on hashing hardware, get a normal CPU to run cgminer Tongue

My timing code already shows you information about that delay in the API stats command ...

Not an issue of speed, but of aproach.
Delays are messy. Seen the number of loops and sleeps in cgminer? Blurgh.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 12:12:55 AM
 #7028

I've already discussed this with ckolivas in the past.

cgminer C code being executed on a CPU is ... quite ... fast.

The delay is simply the verification of the share and the determination of the next getwork data (which is not a network getwork, cgminer already has the next piece of work necessary in most cases, and in the other cases it is not avoidable - getwork send and receive is already asynchronous)

The performance gain would be small and possibly not even noticeable at the scale of data reported by cgminer ... though on a slow old crappy CPU, that may or may not be the case.
To put that into context, if you have spent 10's of thousands of dollars on hashing hardware, get a normal CPU to run cgminer Tongue

My timing code already shows you information about that delay in the API stats command ...

Not an issue of speed, but of aproach.
Delays are messy. Seen the number of loops and sleeps in cgminer? Blurgh.
I don't see how those delays are removed by removing code that is running and instead having it wait ... Smiley

If on the other hand you are referring specifically to the BFL code - then discuss that with him when he returns.

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
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 01:41:11 AM
 #7029

Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.

This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.

I don't think you understand the protocol entirely.  The pool is still doing ALL of the bitcoind work.  It is creating the merkle branch list (picking the transactions and building the block essentially).  All it's doing is allowing the miner to adjust a piece of the coinbase transaction, which creates a new merkleroot, thus allowing it to continue hashing without interacting with the pool server once it runs out of nonce space or ntime rolling.
Ah OK, so you are dramatically increasing the amount of data sent - whenever there is a need to send it - the diagonal line of the merkle tree?

As I mentioned - wouldn't the amount of getworks still not be insignificant?
You want miners to change their work whenever a txn change is appropriate (new transactions or high fee transactions)
Otherwise the result of this will be to slow down transaction confirm times - transactions will increase their chance of missing going into the current block?

So it's either increase transaction times, or dramatically increase the amount of data sent in fewer getworks?

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
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
September 12, 2012, 01:45:16 AM
 #7030

Ah OK, so you are dramatically increasing the amount of data sent - whenever there is a need to send it - the diagonal line of the merkle tree?

As I mentioned - wouldn't the amount of getworks still not be insignificant?
You want miners to change their work whenever a txn change is appropriate (new transactions or high fee transactions)
Otherwise the result of this will be to slow down transaction confirm times - transactions will increase their chance of missing going into the current block?

So it's either increase transaction times, or dramatically increase the amount of data sent in fewer gerworks?

By default, my pool sends new work once every 60 seconds.  That is not significantly different than how often many miners get new work (especially when nTime rolling is involved).

They payload of new work is ~1 KB.  It's sent over an always-open asynchronous TCP connection.  No HTTP overhead, no opening new connections either.  This is roughly equivalent to a single getwork today.  That 1 KB is enough to include ~1,000 transactions (which only requires 10 merklebranches to be sent), and provides enough work 18 Exahash/s.  Add an extra 65 bytes to the work push to double that to 1,025-2,047 transactions.  Another 65 for 2,048-4,096.  As you can see, this means that even at astronomical network size where a block would contain hundreds of thousands of transactions, the payload for the mining protocol will never exceed 2 KB.

Work submissions take only a few bytes.  The new protocol drastically reduces bandwith to the point that a 56k modem provides enough bandwidth to run a mining farm more than 1 billion times the size of the current network.

Additionally, the 18 Exahash uses a local ExtraNonce adjustment size of 4 bytes.  That can be increased to 8 bytes quite easily (the protocol defines the ExtraNonce size as variable, and provided by the pool server).  If the ExtraNonce size was increased to 8 bytes, you can run 4.2 billion times more work per push, and the only increase in bandwidth is it will require 8 more bytes to submit a share to the server.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
September 12, 2012, 01:49:05 AM
 #7031

You still don't fully understand it. Actually pool send much less amount of data than with getwork. You should really read "real world example" from the Stratum documentation page. If you're miner developer, you'll be surely familiar with the howto.

The new protocol really don't change any transaction confirmation times. Nothing changes in this area. Protocol just optimize the overhead on every level and give the miner great oportunity to iterate not only over ntime and nonce, but also over extranonce. And with cost of only one double-sha256 hash per new coinbase. Isn't that great? :-)


Ah OK, so you are dramatically increasing the amount of data sent - whenever there is a need to send it - the diagonal line of the merkle tree?

As I mentioned - wouldn't the amount of getworks still not be insignificant?
You want miners to change their work whenever a txn change is appropriate (new transactions or high fee transactions)
Otherwise the result of this will be to slow down transaction confirm times - transactions will increase their chance of missing going into the current block?

So it's either increase transaction times, or dramatically increase the amount of data sent in fewer getworks?

TCPC
Jr. Member
*
Offline Offline

Activity: 30


View Profile WWW
September 12, 2012, 02:16:31 AM
 #7032

I'm having a problem trying out scrypt on cgminer.  I seem to have got my settings OK for the most part other than a little performance tweaking, but the main problem I ran into was this. 
CGMiner is reporting that my 5830 card is currently hashing at 150 Kh/s but on litecoinpool.org it was only reporting about 10 Kh/s.  It doesn't seem to be an issue with rejects or HW errors as I am getting very few rejects and no HW errors. 
So I thought maybe it was something with litecoin pool.  So I setup a local P2Pool server and pointed the rig to that, but I am still getting a very similar issue.  P2Pool is only reporting me hashing at 25509H/s.  I read through a lot of the posts in this thread and the CGMiner Scrypt thread, but could not find anyone having a similar issue.  Anyone have any ideas what my problem might be?

Bitcoin:      14dK33sP9W2MJ1G5rVEyE9M81ee31ptzix
Namecoin:  NG4dVFDU8qguuRbtuC9Dvz6KkcupdWQcjW
PPcoin:      PPxXyTso7DxykNjq6gy8VVQidATwsGUp2i
Litecoin:     LP2f38SdV3BZ2EZNDYrvFdHVEG43vhwBwt
Ixcoin:       xvU6ZXJ2fJeCGh4kxZQxCSgZGp2UsRgpre
ydenys
Member
**
Offline Offline

Activity: 96


View Profile
September 12, 2012, 02:35:39 AM
 #7033


blabla


I can think of 3 "solutions" to your cannot be managed/must be managed card combo. So here goes in increasing order of difficulty.

1. Get rid the faulty card. Maybe replace it with something that still works.
2. run 2 instances of CGMiner; one with "-d 1" and the other with "-d 0 -d 2 --auto-fan --auto-gpu  --your-other-options"
3. Adjust the bios defaults on your cards so they default to what you want them to run at. Don't specify any GPU or fan speeds when you start CGMiner so they all run at their modified defaults and let the driver control the fans.

Good luck.

Just to say 'thank you'.

Running 2 instances of cgminer (the one with healthy cards is a step higher priority and amended core/memory/fan, the faulty one on default on its own, low aggression). Restart-safe, even no pause needed in autoexe and no fiddling with cards’ bioses to oc healthy cards. Pretty sure the ‘faulty’ card will be chugging till armageddon/appearance of dreaded ASICs Smiley
Jack1Rip1BurnIt
Sr. Member
****
Offline Offline

Activity: 350


Trust me, these default swaps will limit the risks


View Profile
September 12, 2012, 07:33:39 AM
 #7034

The "download all files here" link is not working on the first page. Ready to give CGMiner a try but no download Huh

Successful trades with bels, misterbigg, ChrisNelson, shackleford, geniusboy91, and Isokivi.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 10:34:32 AM
 #7035

The "download all files here" link is not working on the first page. Ready to give CGMiner a try but no download Huh
ckolivas is absent as per his post back here:
https://bitcointalk.org/index.php?topic=28402.msg1156587#msg1156587

Yes it seems his web site is dead at the moment.
I've put his release files in my git downloads:
https://github.com/kanoi/cgminer/downloads

The release files are:
cgminer-2.7.5-win32.7z — cgminer2.7.5 ckolivas release file: windows 32bit (mingw)
cgminer-2.7.5-x86_64-built.tar.bz2 — cgminer2.7.5 ckolivas release file: linux x86_64 binary release

ckolivas web site is working again Smiley

I haven't put the source file since his git is working.

ALSO Smiley

I've added more changes to my git master and added them to the pull to ckolivas git:
https://github.com/ckolivas/cgminer/pull/310

22 commits (plus a version number commit so anyone running it will see 2.7.5g if they compile the current code that is there right now)

I fixed the (minor) issue that the HW: code was still submitting the bad shares - if anyone noticed that (I know a few did)

I've also modified the pool URL syntax (at someone's request) - to allow each pool to individually specify it's own proxy of any of the proxy types supported by CURL (http, http1.0, socks4, socks5, socks4a, socks5h)

... and a bunch of other changes.

Of course these are just a pull request to ckolivas, so they may or may not end up in cgminer ... but hopefully they all will.

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
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 01:50:40 PM
 #7036

It there a Plan to implemet queue and Threats in the API?
At the moment the socket queue is 100 but a single thread.
What are you doing with the API that needs more than that? Smiley

Ok i miswrote it.
I dont wont Threat and queue for the API. I want to Set These options over the API like Intensity.

If i Mine with a normal Pool the Standard Setting for these Parameters are ok.

If i Switch to p2pool over the API in an Script, i want to change the Queue And threats too.
Ah OK - Queue, ScanTime and Expiry are certainly no issue to add.
(It currently shows ScanTime, but doesn't let you change it - easy enough to do that)
I'll add them to my list of stuff to be done some time in the future ... or you can prompt me to do it sooner ... Smiley
...
OK, my current git source has these 3 now also ... if you compile it, it will now say 2.7.5h
The change: viewing and setting queue, scantime and expiry via the API
... any prompting? Smiley

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
tnkflx
Sr. Member
****
Offline Offline

Activity: 346


View Profile
September 12, 2012, 07:14:37 PM
 #7037

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?

| Operating electrum.be & us.electrum.be |
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 10:51:00 PM
 #7038

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?
When I get one to work out how to access them Smiley
Someone offered to send me one ... soon I hope Smiley

I will then make a standalone CM driver that deals with some/all of the extra CM only stuff.

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
tnkflx
Sr. Member
****
Offline Offline

Activity: 346


View Profile
September 13, 2012, 06:28:15 AM
 #7039

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?
When I get one to work out how to access them Smiley
Someone offered to send me one ... soon I hope Smiley

I will then make a standalone CM driver that deals with some/all of the extra CM only stuff.

My offer for remote access still stands Smiley

| Operating electrum.be & us.electrum.be |
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
September 13, 2012, 06:48:41 AM
 #7040

Currently testing 2.7.5h with 3 Icarus & 2 Cairnsmore1...

Also, the CM1s appear to have temperature sensors, can they be read out in some way?
When I get one to work out how to access them Smiley
Someone offered to send me one ... soon I hope Smiley

I will then make a standalone CM driver that deals with some/all of the extra CM only stuff.

My offer for remote access still stands Smiley
For basic support - useful - for ongoing proper support - not much use.
I've already done the basic support, for free, without having a CM1.

CM1's mine (with the Icarus style bitstreams) and can even get the right timing for the different configurations and different FPGA setups (single or pairs - but the code will allow up to 8 )
Oddly - I did all that without even having access to a CM1 - it was all rather logical how it should work so I wrote the code to make it work.
I think it was the idea of Lancelot that made me want to do it - but I don't have one of them either Tongue
But even Lancelot mines with the Icarus code.

'When' I get a CM1 I'll then go to the trouble (as I said above) of writing a specific driver for it based on the Icarus code (they will most likely share code) ... until then, it works, it mines, it's good enough.
(and no I'm not looking for ways to spend my free time on something like that without a CM1 Tongue)

... that's the polite version Smiley

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
Pages: « 1 ... 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 [352] 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 ... 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!