steamboat
|
|
August 06, 2012, 05:07:54 PM |
|
Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?
I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate
|
|
|
|
|
|
Every time a block is mined, a certain amount of BTC (called the
subsidy) is created out of thin air and given to the miner. The
subsidy halves every four years and will reach 0 in about 130 years.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
steamboat
|
|
August 06, 2012, 05:08:40 PM |
|
Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood. Has anyone tested these yet?
|
|
|
|
ebereon
|
|
August 06, 2012, 05:09:36 PM |
|
Which --icarus-timing option do I have to use with cgminer and the shortfin_icarus_cm1_test_150 bitstream to get a correct MH/s readout?
I think no one use this bitstream, but if you want to know the timing, just use short or long and read it yourself. Note it and then use it. I would deffinitively use the latest bitstreams like "shortfin_dcmwd2_test_150.bit". eb
|
|
|
|
ebereon
|
|
August 06, 2012, 05:12:20 PM |
|
Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood. Has anyone tested these yet? Yes, that's the latest bitstreams and i use them, works very good.
|
|
|
|
gyverlb
|
|
August 06, 2012, 06:53:22 PM |
|
Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood. Has anyone tested these yet? Currently running with the 190MHz bitstream on 2 boards with cgminer 2.5.0. The FPGA1 is regularly idle : orange light on and utility is low for one of the FPGA pairs : ICA 0: | 379.8/373.8Mh/s | A:1912 R:19 HW:0 U: 5.10/m ICA 1: | 380.5/377.0Mh/s | A:1078 R:10 HW:0 U: 2.88/m ICA 2: | 379.8/374.6Mh/s | A:1945 R:21 HW:0 U: 5.19/m ICA 3: | 379.9/375.2Mh/s | A:1629 R:19 HW:0 U: 4.35/m
0 and 2 seem fine, 1 and 3 are lagging behind and the ICA1 board clearly idles most of the time on FPGA 1.
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 06, 2012, 07:30:00 PM |
|
Today, after looking at abcpool lagging I decided to test ozcoin as per ebereon message where he says that on ozcoin he had higher U: per boards. These are my boards after 4 hours: cgminer version 2.6.1 - Started: [2012-08-06 17:06:34] -------------------------------------------------------------------------------- (5s):7112.6 (avg):7433.5 Mh/s | Q:7095 A:22829 R:95 HW:0 E:322% U:94.0/m TQ: 22 ST: 22 SS: 69 DW: 831 NB: 20 LW: 35096 GF: 11 RF: 1 Connected to http://eu.ozco.in with LP as user Block: 000005cace1e77dd8a3dba11e7ceb0b8... Started: [20:59:19] -------------------------------------------------------------------------------- [P]ool management [S]ettings [D]isplay options [Q]uit ICA 0: | 379.9/378.1Mh/s | A: 629 R: 2 HW: 2 U: 2.59/m ICA 1: | 322.4/369.7Mh/s | A: 552 R: 6 HW:64 U: 2.27/m ICA 2: | 379.7/365.3Mh/s | A:1233 R: 3 HW:76 U: 5.08/m ICA 3: | 379.7/374.8Mh/s | A:1281 R: 3 HW:23 U: 5.28/m ICA 4: | 370.3/362.5Mh/s | A:1153 R: 5 HW: 5 U: 4.75/m ICA 5: | 363.2/362.7Mh/s | A:1144 R: 2 HW: 0 U: 4.71/m ICA 6: | 379.9/377.7Mh/s | A:1315 R: 3 HW: 3 U: 5.42/m ICA 7: | 379.6/376.7Mh/s | A:1335 R: 5 HW:15 U: 5.50/m ICA 8: | 379.8/377.2Mh/s | A:1250 R: 7 HW: 6 U: 5.15/m ICA 9: | 369.7/372.9Mh/s | A:1146 R: 7 HW:50 U: 4.72/m ICA 10: | 379.7/377.1Mh/s | A:1220 R: 6 HW: 5 U: 5.03/m ICA 11: | 379.8/378.0Mh/s | A:1306 R: 6 HW: 0 U: 5.38/m ICA 12: | 355.8/355.9Mh/s | A:1090 R: 2 HW: 2 U: 4.49/m ICA 13: | 351.4/355.5Mh/s | A:1153 R: 3 HW: 7 U: 4.75/m ICA 14: | 379.8/377.5Mh/s | A:1268 R: 9 HW: 8 U: 5.22/m ICA 15: | 379.8/377.8Mh/s | A:1313 R: 3 HW: 1 U: 5.41/m ICA 16: | 379.7/362.2Mh/s | A:1207 R: 9 HW:87 U: 4.97/m ICA 17: | 379.7/377.3Mh/s | A:1295 R:10 HW: 6 U: 5.33/m ICA 18: | 379.9/378.4Mh/s | A: 629 R: 2 HW: 0 U: 2.59/m ICA 19: | 379.8/378.1Mh/s | A:1313 R: 2 HW: 4 U: 5.41/m
Apart from a higher U: I've found that the number of hardware errors seems lower... today it's more cold here than every other day of the last week, but the HW: parameter is a lot lower. I think that ozcoin lets the miner roll the time, see E: at 322%, so I've come to the conclusion that a good deal of HW: errors come from FPGAs hashing during the time that the miner is sending new work and so hashing mostly invalid data (trash in trash out ) This could be a reason for not having HW: increased by FPGAs since that number is not a real indicator of hardware problems when used with a FPGA. On the other hand, while do FPGAs keep hashing when a new getwork is sent to them? And, even more important, of the 87 errors of ICA16, how many of them are real errors and not errors due to hashing of a new, incomplete, getwork? spiccioli.
|
|
|
|
steamboat
|
|
August 06, 2012, 07:44:14 PM |
|
Today, after looking at abcpool lagging I decided to test ozcoin as per ebereon message where he says that on ozcoin he had higher U: per boards. These are my boards after 4 hours: cgminer version 2.6.1 - Started: [2012-08-06 17:06:34] -------------------------------------------------------------------------------- (5s):7112.6 (avg):7433.5 Mh/s | Q:7095 A:22829 R:95 HW:0 E:322% U:94.0/m TQ: 22 ST: 22 SS: 69 DW: 831 NB: 20 LW: 35096 GF: 11 RF: 1 Connected to http://eu.ozco.in with LP as user Block: 000005cace1e77dd8a3dba11e7ceb0b8... Started: [20:59:19] -------------------------------------------------------------------------------- [P]ool management [S]ettings [D]isplay options [Q]uit ICA 0: | 379.9/378.1Mh/s | A: 629 R: 2 HW: 2 U: 2.59/m ICA 1: | 322.4/369.7Mh/s | A: 552 R: 6 HW:64 U: 2.27/m ICA 2: | 379.7/365.3Mh/s | A:1233 R: 3 HW:76 U: 5.08/m ICA 3: | 379.7/374.8Mh/s | A:1281 R: 3 HW:23 U: 5.28/m ICA 4: | 370.3/362.5Mh/s | A:1153 R: 5 HW: 5 U: 4.75/m ICA 5: | 363.2/362.7Mh/s | A:1144 R: 2 HW: 0 U: 4.71/m ICA 6: | 379.9/377.7Mh/s | A:1315 R: 3 HW: 3 U: 5.42/m ICA 7: | 379.6/376.7Mh/s | A:1335 R: 5 HW:15 U: 5.50/m ICA 8: | 379.8/377.2Mh/s | A:1250 R: 7 HW: 6 U: 5.15/m ICA 9: | 369.7/372.9Mh/s | A:1146 R: 7 HW:50 U: 4.72/m ICA 10: | 379.7/377.1Mh/s | A:1220 R: 6 HW: 5 U: 5.03/m ICA 11: | 379.8/378.0Mh/s | A:1306 R: 6 HW: 0 U: 5.38/m ICA 12: | 355.8/355.9Mh/s | A:1090 R: 2 HW: 2 U: 4.49/m ICA 13: | 351.4/355.5Mh/s | A:1153 R: 3 HW: 7 U: 4.75/m ICA 14: | 379.8/377.5Mh/s | A:1268 R: 9 HW: 8 U: 5.22/m ICA 15: | 379.8/377.8Mh/s | A:1313 R: 3 HW: 1 U: 5.41/m ICA 16: | 379.7/362.2Mh/s | A:1207 R: 9 HW:87 U: 4.97/m ICA 17: | 379.7/377.3Mh/s | A:1295 R:10 HW: 6 U: 5.33/m ICA 18: | 379.9/378.4Mh/s | A: 629 R: 2 HW: 0 U: 2.59/m ICA 19: | 379.8/378.1Mh/s | A:1313 R: 2 HW: 4 U: 5.41/m
Apart from a higher U: I've found that the number of hardware errors seems lower... today it's more cold here than every other day of the last week, but the HW: parameter is a lot lower. I think that ozcoin lets the miner roll the time, see E: at 322%, so I've come to the conclusion that a good deal of HW: errors come from FPGAs hashing during the time that the miner is sending new work and so hashing mostly invalid data (trash in trash out ) This could be a reason for not having HW: increased by FPGAs since that number is not a real indicator of hardware problems when used with a FPGA. On the other hand, while do FPGAs keep hashing when a new getwork is sent to them? And, even more important, of the 87 errors of ICA16, how many of them are real errors and not errors due to hashing of a new, incomplete, getwork? spiccioli. are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 06, 2012, 08:01:42 PM |
|
are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows
linux, steamboat. It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window. In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units. spiccioli. EDIT: see this for example: https://bitcointalk.org/index.php?topic=28402.msg879120;topicseen#msg879120
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
August 06, 2012, 08:03:42 PM |
|
are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows
linux, steamboat. It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window. In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units. spiccioli. With BFGMiner, you could just scroll the unit list with the Up/Down arrow keys...
|
|
|
|
ShadesOfMarble
Donator
Hero Member
Offline
Activity: 543
Merit: 500
|
|
August 06, 2012, 08:28:57 PM |
|
I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate
For me it's not... Reported hashrate is 700 MH/s whereas U clearly indicated that the "real" performance is only 600 MH/s. Which is what one would expect from the 150 Mhz bitstream. I'm currently unable to test any other bitstreams because the board is running in a remote location and I don't want to install VirtualBox risking to kill my network connection.
|
|
|
|
kano
Legendary
Offline
Activity: 4452
Merit: 1798
Linux since 1997 RedHat 4
|
|
August 06, 2012, 09:26:34 PM |
|
I don't use any timing options w/ the latest iteration of cgminer, and as long as none of the chips fail it's pretty accurate
For me it's not... Reported hashrate is 700 MH/s whereas U clearly indicated that the "real" performance is only 600 MH/s. Which is what one would expect from the 150 Mhz bitstream. I'm currently unable to test any other bitstreams because the board is running in a remote location and I don't want to install VirtualBox risking to kill my network connection. As I mentioned before If the device really does hash at the same speed as an Icarus Rev3, it will show correctly. If it doesn't, then you need to know the timing value for the device (which you can work out with 'long' or 'short') or always run in 'long' or 'short' mode, to get it to show correctly. The number of shares per piece of work is random, including possibly 0 When a piece of work has no shares, cgminer has to decide when to stop working on it before it finishes so it doesn't end up idle The Icarus bitstream doesn't send back a message when it finishes, it just goes idle So the timing determines how long that is and thus how long to wait for an answer and then give up and overwrite it with a new piece of work How many hashes it did up to the point when it aborted the work is thus estimated based on how fast the device hashes. So if the timing value is wrong, it will report the MH/s incorrectly Also, if the timing says it is slower than it really is, it only takes it to be incorrect by ~1% and it will be idle at the end each time a piece of work has no shares - and thus this will reduce the performance and the number of shares it finds However, if the device hashes slower than an Icarus Rev3, then it wont ever be idle, it will just report the MH/s higher than it really is but with no negative affect on the shares Though, if it really is aborting work too early, it will have a small negative affect, but usually less than the screen display accuracy ... FYI: all mining programs that mine on a device with the current Icarus bitstream must perform this 'estimate hash calculation'
|
|
|
|
ShadesOfMarble
Donator
Hero Member
Offline
Activity: 543
Merit: 500
|
|
August 06, 2012, 10:10:37 PM Last edit: August 07, 2012, 01:30:28 AM by ShadesOfMarble |
|
Thanks. I'm running with icarus-timing=long now. Now MHS av and U are pretty close, even after just 15 minutes.
Which of the values "Hs", "W" and "fullnonce" do I have to pass to icarus-timing to get an accurate reading from the beginning? Found it.
|
|
|
|
steamboat
|
|
August 06, 2012, 10:21:27 PM |
|
are you using windows or linux? i can't get cgminer to load more than 8 pairs w/out freezing in windows
linux, steamboat. It seem to me that on windows you have make the buffer of the cmd.exe window bigger, going into its properties and making it, for example, 80x50, so that the full list of your boards can be seen inside the window. In other words, an 80x25 cmd.exe window can only show a few units, you need a bigger window if you have lots of units. spiccioli. EDIT: see this for example: https://bitcointalk.org/index.php?topic=28402.msg879120;topicseen#msg879120it isn't an issue of them working and just not being able to see em, cgminer gives an unexpected error and windows closes it.
|
|
|
|
testconpastas2
|
|
August 06, 2012, 10:25:39 PM |
|
To open cgminer with ports of an already running board. for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer blah blah -S 20 and 21 again.
I thought that's what you meant. Why would you ever want to do this? no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things . and to see if anyone could see any clue in why i'm getting an administrative rights error. maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still busy and show me that error. it seems weird to me that no body has my error it was all. Regards.
|
|
|
|
Keninishna
|
|
August 06, 2012, 11:45:38 PM |
|
To open cgminer with ports of an already running board. for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer blah blah -S 20 and 21 again.
I thought that's what you meant. Why would you ever want to do this? no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things . and to see if anyone could see any clue in why i'm getting an administrative rights error. maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still busy and show me that error. it seems weird to me that no body has my error it was all. Regards. Try a diff usb cable, I would get this error with bad usb cables.
|
|
|
|
testconpastas2
|
|
August 07, 2012, 11:05:47 AM |
|
To open cgminer with ports of an already running board. for instance my ports 20 ,21 are hashing OK and i open a new cmd window and type cgminer blah blah -S 20 and 21 again.
I thought that's what you meant. Why would you ever want to do this? no no i dont wanna do that. it was only a way of "replicate" an error similar to what i get sometimes ( of course doing normal things . and to see if anyone could see any clue in why i'm getting an administrative rights error. maybe when my fpga is frozen doesnt free any resource and cgminer thinks it is still busy and show me that error. it seems weird to me that no body has my error it was all. Regards. Try a diff usb cable, I would get this error with bad usb cables. my biggest bet is on the usb hub because the suspicious cable works when i unpluged all the others usb cables from the usb and make a power cycle. but your suggestion will be consider . Thank you.
|
|
|
|
ShadesOfMarble
Donator
Hero Member
Offline
Activity: 543
Merit: 500
|
|
August 07, 2012, 12:02:42 PM |
|
Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood. Any experiences with pre-S/N-50 boards yet? I cannot test any other bitstream atm because I cannot flip over the dip switch remotely
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 07, 2012, 12:10:16 PM |
|
Speaking of resetting boards, these bitstreams should hopefully detect one of the common causes of FPGAs freezing (the DCM losing lock and not outputting a clock anymore) and automatically recover from it: http://www.makomk.com/~aidan/shortfin-dcmwd-20120803.zip Initial signs are looking good, touch wood. Any experiences with pre-S/N-50 boards yet? I cannot test any other bitstream atm because I cannot flip over the dip switch remotely Shades, board #0008, 12 hours, ozco.in, makomk dcmwd2 (the one which tries to workaround cairnsmore issues with clocks) 140 MH/s bitstream. ICA 0: | 371.7/348.3Mh/s | A:3787 R: 5 HW: 1221 U: 3.90/m ICA 1: | 359.7/347.1Mh/s | A:3846 R: 3 HW: 160 U: 3.96/m
I think there is something wrong in the HW: counter for ICA 0, it seems too much for just 12 hours. spiccioli.
|
|
|
|
ShadesOfMarble
Donator
Hero Member
Offline
Activity: 543
Merit: 500
|
|
August 07, 2012, 12:20:16 PM |
|
@spiccioli have you only tried the 140 mhz bitstream yet? Did you try the non-dcmwd bitstreams before? I'm running the non-dcmwd 150 mhz without problems on my #26 but I'm wondering if the dcmwd-bitstreams allow clocks higher than 150 mhz on pre-50 boards.
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
August 07, 2012, 12:30:55 PM |
|
@spiccioli have you only tried the 140 mhz bitstream yet? Did you try the non-dcmwd bitstreams before? I'm running the non-dcmwd 150 mhz without problems on my #26 but I'm wondering if the dcmwd-bitstreams allow clocks higher than 150 mhz on pre-50 boards.
No, I did not try different bistreams on this board. I was using the old twin_test.bit until yesterday evening. I hope that the dcmwd ones can run higher on pre-50 boards, but I have not tried them yet. spiccioli
|
|
|
|
|