Bitcoin Forum
December 07, 2016, 04:39:28 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 ... 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251275 times)
wildemagic
Member
**
Offline Offline

Activity: 112



View Profile
July 20, 2012, 06:01:07 AM
 #1401

IIRC, somewhere back in this long thread there is a command line switch or other work-around to rectify that.

Its in the cgminer fpgareadme file.

Use the --icarus timing option.

Use the short timing and watch the results, then input them as part of your command line.

Default icarus bitstream operates on 2x190mhz fpgas and yields 380mh/s for a default command line of  --icarus-timing 2.66=113 ( i think)

A 200x2 icarus bitstream (the 200mhz beta) uses  --icarus-timing 2.5000=107

So once you run --carus-short and get the ms timing and max nonce range details, use these as your command line option with --icarus-timing.

kind regards

.,-._|\     Offgrid 1.7kW Solar and 3G wireless internet powering my mining rig.
/ .Oz. \
\_,--.x/     [219.5btc of successful trades total] with : rastapool, miernik, flatronw & OneFixt
       o
1481128768
Hero Member
*
Offline Offline

Posts: 1481128768

View Profile Personal Message (Offline)

Ignore
1481128768
Reply with quote  #2

1481128768
Report to moderator
1481128768
Hero Member
*
Offline Offline

Posts: 1481128768

View Profile Personal Message (Offline)

Ignore
1481128768
Reply with quote  #2

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

Posts: 1481128768

View Profile Personal Message (Offline)

Ignore
1481128768
Reply with quote  #2

1481128768
Report to moderator
LazyOtto
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 20, 2012, 06:03:02 AM
 #1402

Thank you, wildemagic.
wildemagic
Member
**
Offline Offline

Activity: 112



View Profile
July 20, 2012, 06:05:18 AM
 #1403

Thank you, wildemagic.

Happy to help, if your having trouble deciphering the results, paste them here.

kind regards

.,-._|\     Offgrid 1.7kW Solar and 3G wireless internet powering my mining rig.
/ .Oz. \
\_,--.x/     [219.5btc of successful trades total] with : rastapool, miernik, flatronw & OneFixt
       o
Keninishna
Hero Member
*****
Offline Offline

Activity: 551



View Profile WWW
July 20, 2012, 06:26:34 AM
 #1404

Yohan, are there instructions for setting up the stacking kits? I'm just not understanding how the sticks screw together.  Huh
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
July 20, 2012, 07:01:45 AM
 #1405

Yohan, are there instructions for setting up the stacking kits? I'm just not understanding how the sticks screw together.  Huh

No formal instructions but I will try and get that into the user manual which is still in progress.

All you need to do is to remove the screws from the 4 feet. On the bottom board you are going to reuse the feet with the stacking pillar so the stacking pillar screws into the foot instead of the normal screw. Sometimes you may have to hold a foot with grips or pliars to allow you to tighten in the stacking pillar enough. The next board you do something similar except this time you screw into the first set of stacking pillars rather than a foot that the first board does. Apart from a screwdrive to remove screws and maybe a grip to hold feet you should be able to hand tighten everything else.
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 20, 2012, 07:29:34 AM
 #1406

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 20, 2012, 08:10:40 AM
 #1407

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli
Yeah those MH/s values are wrong of course Smiley
(--icarus-timing fixes that)
The correct MH/s for U: 2.60/m would be 186MH/s
i.e. ignore the MH/s numbers on your screen.

the --icarus-timing (assuming 2.60/186 is correct) would be ~5.376
But to be sure you would use something like --icarus-timing 5.376=200

Of course you can get close to the correct value instead of 5.376 using --icarus-timing short

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

Activity: 1376

nec sine labore


View Profile
July 20, 2012, 08:16:46 AM
 #1408

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli
Yeah those MH/s values are wrong of course Smiley
(--icarus-timing fixes that)
The correct MH/s for U: 2.60/m would be 186MH/s
i.e. ignore the MH/s numbers on your screen.

the --icarus-timing (assuming 2.60/186 is correct) would be ~5.376
But to be sure you would use something like --icarus-timing 5.376=200

Of course you can get close to the correct value instead of 5.376 using --icarus-timing short

kano,

I've found that cgminer 2.4.3 works as well without using --icarus-timing at all, I'm just throwing away a bigger part of each getwork and I don't see the correct hashing speed (which is not an issue for me).

By the way, the used bitstream should be hashing at 190MH/s but there are boards with higher U: and other boards with a lower one, so a single --icarus-timing option would be correct just for some boards.

spiccioli.
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
July 20, 2012, 08:24:04 AM
 #1409


[...]
Can somebody explain me that?

The effect was correctly explained, i.e. what cgminer reports as hashrate needs to be halved to get the correct value for the CM1 operating with the twin_test.bit bitstream, while the U factor is correct.

Alas, the root cause is not related to the timing settings that are floating around, it is more a result of how cgminer and the Icarus driver work and the fact that one FPGA of each pair is not operable. If you don't care the details, skip to the tl;dr line.

Cgminer Work Processing
To understand the numbers, it is important to understand how the work is processed between pools/bitcoind and the worker: work is fetched from pool(s) and provided to the related driver in chunks of a whole nonce ranges (2^32 hashes). The working unit (being it CPU, GPU, or FPGA) calculates the hashes and reports back valid shares and how much hashes have been processed.

Using Icarus driver for CM1
You need to know the Icarus API to understand the numbers. The API to the Icarus provides no status queries: there is no command to ask the board if it is present or how far it is in processing the nonce range. The only function supported is: you sent it work and it reports you the nonce generating a share - thats it.

As a result of this limited functionality, two workarounds are used in cgminer:
  • To detect whether an Icarus is attached to a serial line, you feed it with work containing a 'golden nonce', that is known to be found very soon (say after some milliseconds) in the range. If an attached device reports what you expect, you found an Icarus, otherwise you see a warning that an unexpected nonce (or nothing) was reported.
  • Being unable to query the process in the nonce range requires some timeouts, in case there is work containing zero valid shares. For that you need to know how long the Icarus is busy crunching the work package, which is easily calculated by (2^32 / hashrate). If after that time you did not hear from your board, you just give it something else to work on. If the timeout value is too long, you risk the FPGA idling around, if it is too short you are aborting nonce ranges and feeding more work than required, which impairs efficiency due to serial line communication delays.

Icarus processes the work by equally distributing it to the two FPGAs with each one generating 2^31 hashes (0-0x7fffffff and 0x80000000-0xffffffff). The Cairnsmore1 has been planned as a dual Icarus board, but for the known design mistake the second FPGA of each pair is deactivated for the original bitstream. Therefore running CM1 in Icarus mode gives you two times half the processing power - or just one Icarus equivalent.

Hashrate
The hashrate is calculated as (hashes reported by driver / elapsed time). cgminer fully relies on what the related driver reports and has no means to verify that the work has really been completed - one can easily write a driver that reports 10TH for a device. It is a tribute to the established MHps measure, but a not exactly precise and controllable one.

When a CM1 FPGA-pair is fed with work, it only operates the first half of it, but reports that the whole range was done. As a result, the reported MHps value is exactly doubled. A side effect of this fact is that twice as many getworks are required. It is possible to modify the reported hashes in a dedicated CM1 driver to correct the hashrate displayed, but given that the Icarus bitstream is only an interim solution, it is easier to add some brain-work and just halve it.

Utilization Factor U
This is the real performance factor, since it reports the average accepted shares by the pool per minute. It is what you get as income and calculated by cgminer independent of the underlying driver. For a CM1 this should be somewhere ~2.5/m per FPGA, a board should provide you 5/m.

Icarus Timings
With CM1 operating with the twin_test bitstream, there is no need to adjust the timings as the clocks are the same as with Icarus. This is only required when the clocks change (like it was for the shipping_test bitstream).


Tl;dr
When operating CM1 in Icarus mode (twin_test.bit)
  • the reported hashrate must be halved and should be around 380 MHps per board
  • the reported U is correct and should be somewhere around 5/min per board
  • no timing parameters are required


HTH

Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 20, 2012, 09:26:45 AM
 #1410

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli

Think that might be a keypoint to stability issues, I have noticed a lot with the worst problems with stability use windows.
Guess I really need to get my arse into gear and get cgminer working on linux.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
dietwice
Jr. Member
*
Offline Offline

Activity: 58


View Profile
July 20, 2012, 09:34:02 AM
 #1411

Thanks, zefir.
Now it is much more clear.

One more question:

Quote
The Cairnsmore1 has been planned as a dual Icarus board, but for the known design mistake the second FPGA of each pair is deactivated for the original bitstream. Therefore running CM1 in Icarus mode gives you two times half the processing power - or just one Icarus equivalent.

The only CM1 operating modes I found are Test mode and Icarus.

Is there any workaround to make CM1 use the full power? Some 3rd party bitstream or not documented DIP switches position or else?
Or maybe the Controller 1.4 would fix that?

Thanks

Donations appreciated at 1DZ6PVjnV8zRdvtgKSqzpAYhifxP1XKhwM
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 20, 2012, 09:42:22 AM
 #1412

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli
Yeah those MH/s values are wrong of course Smiley
(--icarus-timing fixes that)
The correct MH/s for U: 2.60/m would be 186MH/s
i.e. ignore the MH/s numbers on your screen.

the --icarus-timing (assuming 2.60/186 is correct) would be ~5.376
But to be sure you would use something like --icarus-timing 5.376=200

Of course you can get close to the correct value instead of 5.376 using --icarus-timing short

kano,

I've found that cgminer 2.4.3 works as well without using --icarus-timing at all, I'm just throwing away a bigger part of each getwork and I don't see the correct hashing speed (which is not an issue for me).

By the way, the used bitstream should be hashing at 190MH/s but there are boards with higher U: and other boards with a lower one, so a single --icarus-timing option would be correct just for some boards.

spiccioli.

U: is not an accurate measurement of board performance - that is why I said that --icarus-timing short would be required.
All boards should hash at the same rate unless there are hardware production variation issues.
U: is random.
The U: value will only start to converge on the expected value after a few days of hashing.
... and note I said: 'converge' not 'equal'

However ... I'll now reply to zefir ...

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

Activity: 1376

nec sine labore


View Profile
July 20, 2012, 09:42:35 AM
 #1413

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli

Think that might be a keypoint to stability issues, I have noticed a lot with the worst problems with stability use windows.
Guess I really need to get my arse into gear and get cgminer working on linux.

Lethos,

I think there are problems with usb drivers on windows, Yohan found out that inserting a usb key sometimes makes one or more boards to disappear.

In my case, though, the stuck FPGA does not hash anymore, its A: value hasn't been changing for two days now, but there are no signs that the usb connections is gone, since the other FPGA on the same boards is still hashing nicely.

So either the controlling FPGA "lost" that single FPGA or bitstream inside that FPGA locked up for some reason.

Anyway, you can look here for a 32 bit cgminer 2.4.3 compiled for linux with just icarus support available (this is the one I'm using), you need to trust my build though.

https://bitcointalk.org/index.php?topic=78239.msg993287;topicseen#msg993287

spiccioli
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
July 20, 2012, 09:49:19 AM
 #1414

Thanks, zefir.
Now it is much more clear.

One more question:

Quote
The Cairnsmore1 has been planned as a dual Icarus board, but for the known design mistake the second FPGA of each pair is deactivated for the original bitstream. Therefore running CM1 in Icarus mode gives you two times half the processing power - or just one Icarus equivalent.

The only CM1 operating modes I found are Test mode and Icarus.

Is there any workaround to make CM1 use the full power? Some 3rd party bitstream or not documented DIP switches position or else?
Or maybe the Controller 1.4 would fix that?

Thanks
From the info I collected so far, it seems that right now we are restricted to these two. User Glasswalker was the one trying to 'fix' the original Icarus bitstream to handle the swapped RX/TX lines, but he run into problems getting it stable and had to reduce the clock => that is the shipping_test.bit one. The twin_test.bit seems to be ngzhang's original one that does well with only one FPGA per pair enabled.

Many of us are trying to get EldenTyrell's TriCoreMining working on CM1, to my knowledge nobody was successful so far. You might want to watch the related thread.

Other than that I read somewhere that Glasswalker is still working on some CM1 bitstream, but is right now busy and stressed after he got hacked and robbed 12k+$.

I discussed once with Yohan and he told me that everyone who is able and willing to work on a bitstream can get all required information. Anyone Huh

norulezapply
Sr. Member
****
Offline Offline

Activity: 475


View Profile
July 20, 2012, 10:29:11 AM
 #1415

Yohan, are there instructions for setting up the stacking kits? I'm just not understanding how the sticks screw together.  Huh
Seriously? =D They just screw into eachother man. There aren't that many different combinations..

If my post helped, I'll happily accept a few bitmills!   15rGg6A1JFZV3b7TTbtpAaiYGdUD1e1oAm
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 20, 2012, 10:58:55 AM
 #1416


[...]
Can somebody explain me that?

The effect was correctly explained, i.e. what cgminer reports as hashrate needs to be halved to get the correct value for the CM1 operating with the twin_test.bit bitstream, while the U factor is correct.

Alas, the root cause is not related to the timing settings that are floating around, it is more a result of how cgminer and the Icarus driver work and the fact that one FPGA of each pair is not operable. If you don't care the details, skip to the tl;dr line.
Heh - well then someone should read the FPGA-README in cgminer that I wrote quite a while ago:
Code:
The Icarus code currently only works with a dual FPGA device that supports the same commands as
Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
correct hash time nanoseconds value
So yes I stated this when I wrote the code that it required a pair of FPGA (hashing half each)

If these boards are only hashing half the range on a single FPGA then the MH/s value will of course report double what it really is.
The code itself simply doubles the count of hashes completed each time since it knows EXACTLY how many hashes were done and how long it took and assuming there are 2 FPGA (as I said above) then double ((nonce & 0x7fffffff) + 1) is of course correct - NOT an estimate AT ALL.

Quote
Cgminer Work Processing
To understand the numbers, it is important to understand how the work is processed between pools/bitcoind and the worker: work is fetched from pool(s) and provided to the related driver in chunks of a whole nonce ranges (2^32 hashes). The working unit (being it CPU, GPU, or FPGA) calculates the hashes and reports back valid shares and how much hashes have been processed.
Close ... Icarus simply reports back a nonce value (as stated above) and nothing else
(also in the case of GPUs the miner breaks the work up into tiny bits (seriously tiny) and feeds them to the GPU)
Quote
Using Icarus driver for CM1
You need to know the Icarus API to understand the numbers. The API to the Icarus provides no status queries: there is no command to ask the board if it is present or how far it is in processing the nonce range. The only function supported is: you sent it work and it reports you the nonce generating a share - thats it.

As a result of this limited functionality, two workarounds are used in cgminer:
  • To detect whether an Icarus is attached to a serial line, you feed it with work containing a 'golden nonce', that is known to be found very soon (say after some milliseconds) in the range. If an attached device reports what you expect, you found an Icarus, otherwise you see a warning that an unexpected nonce (or nothing) was reported.
  • Being unable to query the process in the nonce range requires some timeouts, in case there is work containing zero valid shares. For that you need to know how long the Icarus is busy crunching the work package, which is easily calculated by (2^32 / hashrate). If after that time you did not hear from your board, you just give it something else to work on. If the timeout value is too long, you risk the FPGA idling around, if it is too short you are aborting nonce ranges and feeding more work than required, which impairs efficiency due to serial line communication delays.
Underestimating the abort time is not a big issue.
The serial I/O per nonce range is approx 5ms or ~0.1% so if you are aborting at 50% of the range it's still only an extra ~0.1% per share.

Quote
...
Hashrate
The hashrate is calculated as (hashes reported by driver / elapsed time). cgminer fully relies on what the related driver reports and has no means to verify that the work has really been completed - one can easily write a driver that reports 10TH for a device. It is a tribute to the established MHps measure, but a not exactly precise and controllable one.
Read the FPGA-README ...

Quote
When a CM1 FPGA-pair is fed with work, it only operates the first half of it, but reports that the whole range was done. As a result, the reported MHps value is exactly doubled. A side effect of this fact is that twice as many getworks are required. It is possible to modify the reported hashes in a dedicated CM1 driver to correct the hashrate displayed, but given that the Icarus bitstream is only an interim solution, it is easier to add some brain-work and just halve it.

Utilization Factor U
This is the real performance factor, since it reports the average accepted shares by the pool per minute. It is what you get as income and calculated by cgminer independent of the underlying driver. For a CM1 this should be somewhere ~2.5/m per FPGA, a board should provide you 5/m.
Unless the FPGA's perform worse than the Icarus, they should get ~2.65/m and the board ~5.3/m
Of course, as I stated before, it can take days to start to converge to that value.

Quote
Icarus Timings
With CM1 operating with the twin_test bitstream, there is no need to adjust the timings as the clocks are the same as with Icarus. This is only required when the clocks change (like it was for the shipping_test bitstream).
However, unless they really are the same (and all the numbers quoted so far by everyone are incorrectly low) you should run --icarus-timing long to confirm that the hardware is indeed the same speed and the Hs value will tell you if it is - again all the numbers reported so far say it is less.
The Icarus Hs value is 0.0000000026316 (2.6316ns)
Quote
Tl;dr
When operating CM1 in Icarus mode (twin_test.bit)
  • the reported hashrate must be halved and should be around 380 MHps per board
  • the reported U is correct and should be somewhere around 5/min per board
  • no timing parameters are required

HTH
Halved: yes (since it does seem half the FPGA are idle doing nothing and U: shows that)
U: again - don't pay too much attention to U: unless it been running for at LEAST a few days ...
As long as these things are hashing at the same speed as an Icarus, then there is no need for timing parameters, however if they do hash slower, then setting the parameter will increase performance, but only ever so slightly
If they do hash more than 384MH/s (or really more than 192MH/s per FPGA) , then using the default Icarus parameters will slow it down.

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

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 20, 2012, 01:11:34 PM
 #1417

Can you share how you managed to get it stable for that long, since many are not yet.
What settings and that do you use in CGminer?

Hi Lethos,

nothing fancy, I just start cgminer telling it what ttyUSB?? port (I'm on linux) to use, I'm not using the icarus-timing option.


spiccioli

Think that might be a keypoint to stability issues, I have noticed a lot with the worst problems with stability use windows.
Guess I really need to get my arse into gear and get cgminer working on linux.

Lethos,

I think there are problems with usb drivers on windows, Yohan found out that inserting a usb key sometimes makes one or more boards to disappear.

In my case, though, the stuck FPGA does not hash anymore, its A: value hasn't been changing for two days now, but there are no signs that the usb connections is gone, since the other FPGA on the same boards is still hashing nicely.

So either the controlling FPGA "lost" that single FPGA or bitstream inside that FPGA locked up for some reason.

Anyway, you can look here for a 32 bit cgminer 2.4.3 compiled for linux with just icarus support available (this is the one I'm using), you need to trust my build though.

https://bitcointalk.org/index.php?topic=78239.msg993287;topicseen#msg993287

spiccioli


I will actually give it a go. Thanks.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
July 20, 2012, 01:17:34 PM
 #1418

Thanks, zefir.
Now it is much more clear.

One more question:

Quote
The Cairnsmore1 has been planned as a dual Icarus board, but for the known design mistake the second FPGA of each pair is deactivated for the original bitstream. Therefore running CM1 in Icarus mode gives you two times half the processing power - or just one Icarus equivalent.

The only CM1 operating modes I found are Test mode and Icarus.

Is there any workaround to make CM1 use the full power? Some 3rd party bitstream or not documented DIP switches position or else?
Or maybe the Controller 1.4 would fix that?

Thanks
From the info I collected so far, it seems that right now we are restricted to these two. User Glasswalker was the one trying to 'fix' the original Icarus bitstream to handle the swapped RX/TX lines, but he run into problems getting it stable and had to reduce the clock => that is the shipping_test.bit one. The twin_test.bit seems to be ngzhang's original one that does well with only one FPGA per pair enabled.

Many of us are trying to get EldenTyrell's TriCoreMining working on CM1, to my knowledge nobody was successful so far. You might want to watch the related thread.

Other than that I read somewhere that Glasswalker is still working on some CM1 bitstream, but is right now busy and stressed after he got hacked and robbed 12k+$.

I discussed once with Yohan and he told me that everyone who is able and willing to work on a bitstream can get all required information. Anyone Huh

I'm glad multiple people are trying to get a bitstream together. It's not easy and I am also one of them, how ever I'm still in the learning stages of figuring the hardware itself. Until I do, and know what I'm working with it makes it harder to software design for it.

I can certain see some potential ways to improve the bitstream, but I do have my concerns that if I can't get it to work stable like others can, I could be adding too many variables and won't know what to blame if I add another (my own bitstream). So If I move my running of the CM1's over to linux, If it solves my issues of stability, then I'll be happy to start building a bitstream.
Stability is key, It's no fun seeing it only up for 1-2 hours, I can't watch it like a hawk, else I'd get no work done.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
spiccioli
Legendary
*
Offline Offline

Activity: 1376

nec sine labore


View Profile
July 20, 2012, 03:30:16 PM
 #1419

Double failure Sad

after one week, this afternoon I found

Code:
cgminer version 2.4.3 - Started: [2012-07-13 07:26:50]
--------------------------------------------------------------------------------
 (5s):0.0 (avg):7341.2 Mh/s | Q:1462192  A:535635  R:580  HW:0  E:37%  U:50.2/m
 TQ: 20  ST: 21  SS: 18  DW: 19736  NB: 1148  LW: 1731  GF: 982  RF: 11
 Connected to http://pool.abcpool.co with LP as user ......
 Block: 0000014fd06b0138ceffc572e94b9597...  Started: [17:10:25]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | OFF  /366.7Mh/s | A:27822 R:34 HW:0 U: 2.61/m
 ICA 1:                | OFF  /366.9Mh/s | A:25564 R:25 HW:0 U: 2.40/m
 ICA 2:                | OFF  /367.0Mh/s | A:27594 R:33 HW:0 U: 2.59/m
 ICA 3:                | OFF  /366.9Mh/s | A:26397 R:31 HW:0 U: 2.47/m
 ICA 4:                | OFF  /366.9Mh/s | A:27691 R:23 HW:0 U: 2.59/m
 ICA 5:                | OFF  /366.9Mh/s | A:27226 R:23 HW:0 U: 2.55/m
 ICA 6:                | OFF  /366.6Mh/s | A:27374 R:24 HW:0 U: 2.56/m
 ICA 7:                | OFF  /366.4Mh/s | A:19404 R:25 HW:0 U: 1.82/m
 ICA 8:                | 380.0/367.3Mh/s | A:27337 R:34 HW:0 U: 2.56/m
 ICA 9:                | 380.0/367.2Mh/s | A:23528 R:27 HW:0 U: 2.20/m
 ICA 10:                | 380.0/367.3Mh/s | A:27353 R:32 HW:0 U: 2.56/m
 ICA 11:                | 380.0/367.1Mh/s | A:27529 R:23 HW:0 U: 2.58/m
 ICA 12:                | 380.0/367.3Mh/s | A:27557 R:32 HW:0 U: 2.58/m
 ICA 13:                | 380.0/367.3Mh/s | A:27555 R:32 HW:0 U: 2.58/m
 ICA 14:                | 380.0/367.1Mh/s | A:27685 R:32 HW:0 U: 2.59/m
 ICA 15:                | 380.0/367.2Mh/s | A:27517 R:26 HW:0 U: 2.58/m
 ICA 16:                | 380.0/367.3Mh/s | A:27500 R:28 HW:0 U: 2.58/m
 ICA 17:                | 380.0/367.3Mh/s | A:27658 R:33 HW:0 U: 2.59/m
 ICA 18:                | 380.0/367.2Mh/s | A:27792 R:30 HW:0 U: 2.60/m
 ICA 19:                | 380.0/367.3Mh/s | A:27552 R:33 HW:0 U: 2.58/m
--------------------------------------------------------------------------------

 [2012-07-20 16:17:02] ICA 4 failure, disabling!
 [2012-07-20 16:17:02] ICA 5 failure, disabling!
 [2012-07-20 16:17:02] ICA 6 failure, disabling!
 [2012-07-20 16:17:02] ICA 7 failure, disabling!
 [2012-07-20 16:36:52] LONGPOLL from pool 0 detected new block
 [2012-07-20 16:38:25] LONGPOLL from pool 0 detected new block
 [2012-07-20 16:40:08] LONGPOLL from pool 0 detected new block
 [2012-07-20 16:43:18] LONGPOLL from pool 0 detected new block
 [2012-07-20 16:45:26] LONGPOLL from pool 0 detected new block
 [2012-07-20 16:55:44] LONGPOLL from pool 0 detected new block

half of my boards disconnected and reconnected as new usb ports, cgminer stopped sending more work to my pool even if it is still working as it detects long polls.

This is dmesg output.

Code:
[636683.527463] usb 1-3: USB disconnect, device number 2
[636683.527480] usb 1-3.1: USB disconnect, device number 4
[636683.527969] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[636683.528056] ftdi_sio 1-3.1:1.0: device disconnected
[636683.531516] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[636683.531571] ftdi_sio 1-3.1:1.1: device disconnected
[636683.537769] ftdi_sio ttyUSB2: FTDI USB Serial Device converter now disconnected from ttyUSB2
[636683.537810] ftdi_sio 1-3.1:1.2: device disconnected
[636683.541175] ftdi_sio ttyUSB3: FTDI USB Serial Device converter now disconnected from ttyUSB3
[636683.541216] ftdi_sio 1-3.1:1.3: device disconnected
[636683.541585] usb 1-3.2: USB disconnect, device number 5
[636683.541957] ftdi_sio ttyUSB4: FTDI USB Serial Device converter now disconnected from ttyUSB4
[636683.542003] ftdi_sio 1-3.2:1.0: device disconnected
[636683.543191] ftdi_sio ttyUSB5: FTDI USB Serial Device converter now disconnected from ttyUSB5
[636683.543241] ftdi_sio 1-3.2:1.1: device disconnected
[636683.546774] ftdi_sio ttyUSB6: FTDI USB Serial Device converter now disconnected from ttyUSB6
[636683.546815] ftdi_sio 1-3.2:1.2: device disconnected
[636683.549974] ftdi_sio ttyUSB7: FTDI USB Serial Device converter now disconnected from ttyUSB7
[636683.550008] ftdi_sio 1-3.2:1.3: device disconnected
[636683.550311] usb 1-3.3: USB disconnect, device number 6
[636683.550616] ftdi_sio ttyUSB8: FTDI USB Serial Device converter now disconnected from ttyUSB8
[636683.550655] ftdi_sio 1-3.3:1.0: device disconnected
[636683.552739] ftdi_sio ttyUSB9: FTDI USB Serial Device converter now disconnected from ttyUSB9
[636683.552782] ftdi_sio 1-3.3:1.1: device disconnected
[636683.556542] ftdi_sio ttyUSB10: FTDI USB Serial Device converter now disconnected from ttyUSB10
[636683.556577] ftdi_sio 1-3.3:1.2: device disconnected
[636683.559003] ftdi_sio ttyUSB11: FTDI USB Serial Device converter now disconnected from ttyUSB11
[636683.559037] ftdi_sio 1-3.3:1.3: device disconnected
[636683.559342] usb 1-3.4: USB disconnect, device number 7
[636683.559647] ftdi_sio ttyUSB12: FTDI USB Serial Device converter now disconnected from ttyUSB12
[636683.559688] ftdi_sio 1-3.4:1.0: device disconnected
[636683.562317] ftdi_sio ttyUSB13: FTDI USB Serial Device converter now disconnected from ttyUSB13
[636683.562362] ftdi_sio 1-3.4:1.1: device disconnected
[636683.565950] ftdi_sio ttyUSB14: FTDI USB Serial Device converter now disconnected from ttyUSB14
[636683.565985] ftdi_sio 1-3.4:1.2: device disconnected
[636683.569579] ftdi_sio ttyUSB15: FTDI USB Serial Device converter now disconnected from ttyUSB15
[636683.569614] ftdi_sio 1-3.4:1.3: device disconnected
[636683.808058] usb 1-3: new high-speed USB device number 15 using ehci_hcd
[636698.920070] usb 1-3: device descriptor read/64, error -110
[636714.136074] usb 1-3: device descriptor read/64, error -110
[636714.352074] usb 1-3: new high-speed USB device number 16 using ehci_hcd
[636729.464051] usb 1-3: device descriptor read/64, error -110
[636744.680055] usb 1-3: device descriptor read/64, error -110
[636744.896057] usb 1-3: new high-speed USB device number 17 using ehci_hcd
[636755.304068] usb 1-3: device not accepting address 17, error -110
[636755.416075] usb 1-3: new high-speed USB device number 18 using ehci_hcd
[636765.824088] usb 1-3: device not accepting address 18, error -110
[636765.824235] hub 1-0:1.0: unable to enumerate USB device on port 3
[636766.080066] usb 3-1: new full-speed USB device number 2 using uhci_hcd
[636766.225103] usb 3-1: not running at top speed; connect to a high speed hub
[636766.250260] hub 3-1:1.0: USB hub found
[636766.252447] hub 3-1:1.0: 4 ports detected
[636766.537118] usb 3-1.1: new full-speed USB device number 3 using uhci_hcd
[636766.639088] usb 3-1.1: not running at top speed; connect to a high speed hub
[636766.675515] ftdi_sio 3-1.1:1.0: FTDI USB Serial Device converter detected
[636766.675636] usb 3-1.1: Detected FT4232H
[636766.675648] usb 3-1.1: Number of endpoints 2
[636766.675660] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.675672] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.675684] usb 3-1.1: Setting MaxPacketSize 64
[636766.677277] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
[636766.681010] ftdi_sio 3-1.1:1.1: FTDI USB Serial Device converter detected
[636766.681143] usb 3-1.1: Detected FT4232H
[636766.681155] usb 3-1.1: Number of endpoints 2
[636766.681167] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.681179] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.681191] usb 3-1.1: Setting MaxPacketSize 64
[636766.683866] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB1
[636766.687509] ftdi_sio 3-1.1:1.2: FTDI USB Serial Device converter detected
[636766.687627] usb 3-1.1: Detected FT4232H
[636766.687639] usb 3-1.1: Number of endpoints 2
[636766.687651] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.687663] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.687675] usb 3-1.1: Setting MaxPacketSize 64
[636766.689301] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB4
[636766.692684] ftdi_sio 3-1.1:1.3: FTDI USB Serial Device converter detected
[636766.692783] usb 3-1.1: Detected FT4232H
[636766.692793] usb 3-1.1: Number of endpoints 2
[636766.692803] usb 3-1.1: Endpoint 1 MaxPacketSize 64
[636766.692812] usb 3-1.1: Endpoint 2 MaxPacketSize 64
[636766.692821] usb 3-1.1: Setting MaxPacketSize 64
[636766.694253] usb 3-1.1: FTDI USB Serial Device converter now attached to ttyUSB5
[636766.769118] usb 3-1.2: new full-speed USB device number 4 using uhci_hcd
[636766.872093] usb 3-1.2: not running at top speed; connect to a high speed hub
[636766.910520] ftdi_sio 3-1.2:1.0: FTDI USB Serial Device converter detected
[636766.910646] usb 3-1.2: Detected FT4232H
[636766.910658] usb 3-1.2: Number of endpoints 2
[636766.910670] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.910682] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.910693] usb 3-1.2: Setting MaxPacketSize 64
[636766.913543] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB8
[636766.916687] ftdi_sio 3-1.2:1.1: FTDI USB Serial Device converter detected
[636766.916811] usb 3-1.2: Detected FT4232H
[636766.916823] usb 3-1.2: Number of endpoints 2
[636766.916835] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.916847] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.916858] usb 3-1.2: Setting MaxPacketSize 64
[636766.918279] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB9
[636766.921514] ftdi_sio 3-1.2:1.2: FTDI USB Serial Device converter detected
[636766.921634] usb 3-1.2: Detected FT4232H
[636766.921646] usb 3-1.2: Number of endpoints 2
[636766.921658] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.921670] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.921681] usb 3-1.2: Setting MaxPacketSize 64
[636766.923932] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB12
[636766.927514] ftdi_sio 3-1.2:1.3: FTDI USB Serial Device converter detected
[636766.927637] usb 3-1.2: Detected FT4232H
[636766.927649] usb 3-1.2: Number of endpoints 2
[636766.927661] usb 3-1.2: Endpoint 1 MaxPacketSize 64
[636766.927673] usb 3-1.2: Endpoint 2 MaxPacketSize 64
[636766.927684] usb 3-1.2: Setting MaxPacketSize 64
[636766.929279] usb 3-1.2: FTDI USB Serial Device converter now attached to ttyUSB13
[636767.005107] usb 3-1.3: new full-speed USB device number 5 using uhci_hcd
[636767.107088] usb 3-1.3: not running at top speed; connect to a high speed hub
[636767.145527] ftdi_sio 3-1.3:1.0: FTDI USB Serial Device converter detected
[636767.145649] usb 3-1.3: Detected FT4232H
[636767.145662] usb 3-1.3: Number of endpoints 2
[636767.145674] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.145686] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.145697] usb 3-1.3: Setting MaxPacketSize 64
[636767.147857] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB40
[636767.151504] ftdi_sio 3-1.3:1.1: FTDI USB Serial Device converter detected
[636767.151635] usb 3-1.3: Detected FT4232H
[636767.151647] usb 3-1.3: Number of endpoints 2
[636767.151659] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.151671] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.151682] usb 3-1.3: Setting MaxPacketSize 64
[636767.153281] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB41
[636767.156697] ftdi_sio 3-1.3:1.2: FTDI USB Serial Device converter detected
[636767.156820] usb 3-1.3: Detected FT4232H
[636767.156831] usb 3-1.3: Number of endpoints 2
[636767.156843] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.156855] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.156866] usb 3-1.3: Setting MaxPacketSize 64
[636767.159105] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB42
[636767.162427] ftdi_sio 3-1.3:1.3: FTDI USB Serial Device converter detected
[636767.162534] usb 3-1.3: Detected FT4232H
[636767.162543] usb 3-1.3: Number of endpoints 2
[636767.162553] usb 3-1.3: Endpoint 1 MaxPacketSize 64
[636767.162563] usb 3-1.3: Endpoint 2 MaxPacketSize 64
[636767.162572] usb 3-1.3: Setting MaxPacketSize 64
[636767.164807] usb 3-1.3: FTDI USB Serial Device converter now attached to ttyUSB43

spiccioli
Isokivi
Hero Member
*****
Offline Offline

Activity: 924


Items flashing here available at btctrinkets.com


View Profile WWW
July 20, 2012, 03:39:41 PM
 #1420

Im glad to hear that a lot of people are currently working on a bitstream and would like to propose a bounty on one. Since im fairly sure a lot others are willing to pledge and would like to discuss the terms of such a bounty I have started a separate thread for it, dont want to clog this one up more than is necessary.

https://bitcointalk.org/index.php?topic=94317.msg1042972#msg1042972

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
Pages: « 1 ... 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 [71] 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 ... 129 »
  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!