wildemagic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 06:01:07 AM |
|
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
|
|
|
LazyOtto
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 06:03:02 AM |
|
Thank you, wildemagic.
|
|
|
|
wildemagic
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 112
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 06:05:18 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 06:26:34 AM |
|
Yohan, are there instructions for setting up the stacking kits? I'm just not understanding how the sticks screw together. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif)
|
|
|
|
yohan (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 07:01:45 AM Last edit: July 20, 2012, 07:50:34 AM by yohan |
|
Yohan, are there instructions for setting up the stacking kits? I'm just not understanding how the sticks screw together. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) 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
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 07:29:34 AM |
|
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
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 08:10:40 AM |
|
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](https://bitcointalk.org/Smileys/default/smiley.gif) (--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=200Of course you can get close to the correct value instead of 5.376 using --icarus-timing short
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 08:16:46 AM |
|
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](https://bitcointalk.org/Smileys/default/smiley.gif) (--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=200Of 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
Activity: 919
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 08:24:04 AM |
|
[...] 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 ProcessingTo 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 CM1You 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. HashrateThe 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 UThis 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 TimingsWith 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;drWhen 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 09:26:45 AM |
|
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.
|
|
|
|
dietwice
Newbie
Offline
Activity: 58
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 09:34:02 AM |
|
Thanks, zefir. Now it is much more clear. One more question: 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
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 09:42:22 AM |
|
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](https://bitcointalk.org/Smileys/default/smiley.gif) (--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=200Of 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 ...
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 09:42:35 AM |
|
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
Activity: 919
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 09:49:19 AM |
|
Thanks, zefir. Now it is much more clear. One more question: 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](https://bitcointalk.org/Smileys/default/huh.gif)
|
|
|
|
norulezapply
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 10:29:11 AM |
|
Yohan, are there instructions for setting up the stacking kits? I'm just not understanding how the sticks screw together. ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) Seriously? =D They just screw into eachother man. There aren't that many different combinations..
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 10:58:55 AM |
|
[...] 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: 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. 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) Using Icarus driver for CM1You 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. ... 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 ... 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. 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) Tl;drWhen 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.
|
|
|
|
Lethos
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 01:11:34 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 01:17:34 PM |
|
Thanks, zefir. Now it is much more clear. One more question: 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](https://bitcointalk.org/Smileys/default/huh.gif) 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.
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 03:30:16 PM |
|
Double failure ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) after one week, this afternoon I found 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. [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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2012, 03:39:41 PM |
|
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.
|
|
|
|