Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 36. (Read 286370 times)
@Hpman I guess you have a board with S/N >50?
Short feedback from me side, old shortfin_190 and dcmwd2_200 running great without any problems on my board. Waiting for 2xx versions 
. Unfortunaly at the moment I'm still using original cgminer 2.6.1/2.6.1 without zefirs patch, but 'll compile new binary next days. Great work guys, hopefully bounty will shared to all who spend a lot of spare time for that project. Still missing somethings news from enterpoint itself ...
Hpman
. Unfortunaly at the moment I'm still using original cgminer 2.6.1/2.6.1 without zefirs patch, but 'll compile new binary next days. Great work guys, hopefully bounty will shared to all who spend a lot of spare time for that project. Still missing somethings news from enterpoint itself ...Hpman
Hopefully by this you mean that like with a ztex, the miner software can tell it to increase and decrease the MHz clock on the fly
So it is up to software control (and HW: error counts) to decide the optimal MHz
So it is up to software control (and HW: error counts) to decide the optimal MHz
That's correct, I intend to expose a more advanced serial protocol which will allow the mining software to (among other things) adjust the clock rate for the hashing clock. That's a ways off for now though, so initially we're working with the more crude "dip switch coarse clock settings" option...
...
Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)
Anyway, just a quick update. I'll post more once I've been able to test it.
...
Hopefully by this you mean that like with a ztex, the miner software can tell it to increase and decrease the MHz clock on the flyDown the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)
Anyway, just a quick update. I'll post more once I've been able to test it.
...
So it is up to software control (and HW: error counts) to decide the optimal MHz
Yeah I could have done it in fpgaeditor, but I had several other changes that needed doing too, so I used that as a base. I'll try the fpgaeditor option as well, while I'm waiting on this build to run through smartxplorer. I've found even minor changes to the design, tend to bork up the tools even if I'm using smartguide from a previous successful run. But maybe that was just an isolated experience.
And yeah I'm still aware of the software issues. TheSeven mentioned it to me on IRC. I've got a fork of MPBM which has a cairnsmore module in it, and I'll be fixing the hash reporting in that eventually.
Thanks!
And yeah I'm still aware of the software issues. TheSeven mentioned it to me on IRC. I've got a fork of MPBM which has a cairnsmore module in it, and I'll be fixing the hash reporting in that eventually.
Thanks!
Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...
Hmmm. You should've been able to fix that up post-build in FPGA Editor... oh well. Also, you might've been able to get away with using the .ncd from that run as a SmartGuide guide file (or not, I've been having some annoying routing issues with SmartGuide even with totally unchanged designs).Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.
Bear in mind this will still require changes to mining software to avoid weird problems with hash rate reporting. (I had a cunning idea to try and work around this, but it turned out that the Xilinx mapping tool really didn't like it so it's probably best to just change the software, heh.)
Ok, quick update. Unfortunately my last build once again (sigh...) had a bug in the new LVDS clocking. (literally oversight on my part, I put a FALSE where it should have been TRUE for LVDS signal termination... DOH!) anyway, that resulted in continuing stability issues, and caused my latest week long marathon build to be a waste of time... Grumble...
Anyway, this has prompted me to apply another round of code fixes. And I think this one should wrap it up. I've fixed the couple minor bugs that existed, so those problems should be solved. AND I've applied several new fixes as well. Including backporting ALL (that I could find) of makomk's shortfin fixes into the HashVoodoo core now. (With the exception of the DCM watchdog, because it was just to fix the failing DCM, but with the LVDS clock signalling there actually is no DCM at all, so nothing to slap a watchdog on lol).
Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.
So anyway, just posting this up, these changes are already committed, and pushed up to the github, so they are there for everyone to see And I'm doing a first round build on it now.
Also, I should have a new controller coming very soon (as in within the next day or two) to match this build, which will provide the following improvements/fixes:
- Should solve jtag instability and usb flashing capabilities, meaning people without jtag cables *should* be able to install it (but need to confirm this first for safety)
- It now supports dynamic clocking, it will be crude at this point, but it will allow 2 dip switches to be used to select from 4 different hashing clock rates (while leaving the communications clocks alone to keep stable baud rate)
- 180Mhz
- 190Mhz
- 200Mhz
- 210Mhz
This way with a given board, you can tune it within that range to find the optimal hashing rate without having to reflash various bitstreams (easy overclocking) I'm building the bitstreams to close timing to 180Mhz now, so that lowest one will be the "100% in spec", but typically the chips can easily reach a bit beyond their spec (much like CPUs, they are graded in batches based on quality, and some chips may overclock better than others). In some cases I get lucky and exceed timing. So for example, if I'm shooting for 180Mhz, and manages to close timing, that means that no path within the FPGA will exceed a delay of 5.555ns, but if I manage to close timing with 0.55ns of slack, that means that it's actually only got 5ns of delay, which means it's technically fully "in-spec" for 200Mhz clock. And if I exceed timing by a full 1ns, then we're super lucky, and that means it's in-spec for a 219Mhz clock. Now that doesn't take into account power draw of all the components in the chip, noise at those frequencies, and thermal stability. But it means the more "in-spec" we are, the more "universally stable" it should be at a given clock. So the new overclocking options (however crude for now) should help people dial in what's "best" for their given board.
Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)
Anyway, just a quick update. I'll post more once I've been able to test it.
Oh and also my new board arrived, so I now have both my #0001 serial number board, and a newer #04xx (can't remember exact number) board, so this lets me test and validate on "both sides of the coin".
Anyway, this has prompted me to apply another round of code fixes. And I think this one should wrap it up. I've fixed the couple minor bugs that existed, so those problems should be solved. AND I've applied several new fixes as well. Including backporting ALL (that I could find) of makomk's shortfin fixes into the HashVoodoo core now. (With the exception of the DCM watchdog, because it was just to fix the failing DCM, but with the LVDS clock signalling there actually is no DCM at all, so nothing to slap a watchdog on lol).
Anyway, this one has several new fixes, and all of makomk's improvements. Plus I've fixed the nonce range problem (which will cause wrong hashrate to report, and wierd U numbers and such) the chips *should* (provided I didn't bork something up again) hash a full nonce range per chip.
So anyway, just posting this up, these changes are already committed, and pushed up to the github, so they are there for everyone to see
And I'm doing a first round build on it now.Also, I should have a new controller coming very soon (as in within the next day or two) to match this build, which will provide the following improvements/fixes:
- Should solve jtag instability and usb flashing capabilities, meaning people without jtag cables *should* be able to install it (but need to confirm this first for safety)
- It now supports dynamic clocking, it will be crude at this point, but it will allow 2 dip switches to be used to select from 4 different hashing clock rates (while leaving the communications clocks alone to keep stable baud rate)
- 180Mhz
- 190Mhz
- 200Mhz
- 210Mhz
This way with a given board, you can tune it within that range to find the optimal hashing rate without having to reflash various bitstreams (easy overclocking)
I'm building the bitstreams to close timing to 180Mhz now, so that lowest one will be the "100% in spec", but typically the chips can easily reach a bit beyond their spec (much like CPUs, they are graded in batches based on quality, and some chips may overclock better than others). In some cases I get lucky and exceed timing. So for example, if I'm shooting for 180Mhz, and manages to close timing, that means that no path within the FPGA will exceed a delay of 5.555ns, but if I manage to close timing with 0.55ns of slack, that means that it's actually only got 5ns of delay, which means it's technically fully "in-spec" for 200Mhz clock. And if I exceed timing by a full 1ns, then we're super lucky, and that means it's in-spec for a 219Mhz clock. Now that doesn't take into account power draw of all the components in the chip, noise at those frequencies, and thermal stability. But it means the more "in-spec" we are, the more "universally stable" it should be at a given clock. So the new overclocking options (however crude for now) should help people dial in what's "best" for their given board.Down the road this will become an auto-tuned thing in software based on invalid rates to find the optimal share yield per second per chip. (yes technically we can tune each chip independently)
Anyway, just a quick update. I'll post more once I've been able to test it.
Oh and also my new board arrived, so I now have both my #0001 serial number board, and a newer #04xx (can't remember exact number) board, so this lets me test and validate on "both sides of the coin".
I've built cgminer 2.6.4 for linux 32bit with zefir patch and icarus support only.
http://p2pool.soon.it/cgminer/cgminer-2.6.4-zefir
spiccioli
http://p2pool.soon.it/cgminer/cgminer-2.6.4-zefir
spiccioli
It is the second time that I see an unusual high number of HW: problems
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
what s/n boards do you have? I have 45, 72-80 and i haven't seen ANY HW errors. maybe I don't have cgminer configured correctly to show me them?
You need to apply a patch to cgminer to see HW: or use the latest version released a couple of days ago, I think it is 2.6.3
spiccioli
2.6.4a doesn't seem to be counting HW errors.
Kano - is there a plan to get this into the main build?
Sorry,
I was wrong, there is an entry in the Changelog about hardware errors, but it is for modminer, I thought it was for every hashing device.
spiccioli
It is the second time that I see an unusual high number of HW: problems
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
what s/n boards do you have? I have 45, 72-80 and i haven't seen ANY HW errors. maybe I don't have cgminer configured correctly to show me them?
You need to apply a patch to cgminer to see HW: or use the latest version released a couple of days ago, I think it is 2.6.3
spiccioli
2.6.4a doesn't seem to be counting HW errors.
Kano - is there a plan to get this into the main build?
Thank you steamboat, and thank you toxicocean for the detailed description of the flashing process.
I already got twin_test.bit flashed and running (too short to give stats), but tomorrow I'll probably test another one of makomk's bitstreams, following your guide, which differs from my procedure in that I set the DIP switches when the board is already powered up and I connect the USB cable before starting the VM.
I just moved my board some meters away from it's original position, perhaps there's a different level of EM noise from laptop, network switch, external usb/sata hdd, and power cables, which could influence the cm1? I'll see tomorrow after work...
Let's hope that future bitstreams will solve the issues of pre#50 owners.
I already got twin_test.bit flashed and running (too short to give stats), but tomorrow I'll probably test another one of makomk's bitstreams, following your guide, which differs from my procedure in that I set the DIP switches when the board is already powered up and I connect the USB cable before starting the VM.
I just moved my board some meters away from it's original position, perhaps there's a different level of EM noise from laptop, network switch, external usb/sata hdd, and power cables, which could influence the cm1? I'll see tomorrow after work...
Let's hope that future bitstreams will solve the issues of pre#50 owners.
boards which i had thought it was buggy after a power cycle and plug out plug in usb cycle ( and plugin first "buggy" boards) it started to work again .
I ordered new hub switches and new fans but they dont be received till wed/thu , so i will have to wait to test new things.
I'm using w7 64bits and the admin privileges issue ahows up randomly no matter if I'was or not in admin mode , and when it appears allways the board is in "my frozen mode" COM's OK ,orange led...
you get the same error if you try to run a second instance of cgminer over a running board but in "my" case it show up slowly as it was checking something on the board.
Edit: not the same in "my case" before the admin privileges line it shows up the lines
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2
I ordered new hub switches and new fans but they dont be received till wed/thu , so i will have to wait to test new things.
I'm using w7 64bits and the admin privileges issue ahows up randomly no matter if I'was or not in admin mode , and when it appears allways the board is in "my frozen mode" COM's OK ,orange led...
you get the same error if you try to run a second instance of cgminer over a running board but in "my" case it show up slowly as it was checking something on the board.
Edit: not the same in "my case" before the admin privileges line it shows up the lines
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM20: get 00000000, should: 000187a2
[2012-08-04 21:39:32] Icarus Detect: Test failed at \\.\COM21: get 00000000, should: 000187a2
what do you mean a second instance of cgminer over a board?
My windows boxes always mine from the last 2 COM ports of any board, and the first board starts with COM20.
So I have always (6 different win7 boxes here) started with -S "\\.\COM22" -S "\\.\COM23"
is it normal that my board #62-0017 makes a high frequency sound when hashing with glasswalker or makomk bitstreams?
I wonder what I can do to get the good results like e.g. toxicocean. Any tips?
I wonder what I can do to get the good results like e.g. toxicocean. Any tips?
I have the high frequency sound also (but not always, or at least I don't always notice it)
hm, if it helps here's a rundown how I program and run mine (#0005) - I assume the controller version is already v1.3, and the drivers are already installed on your programming/mining pc:
- start the enterpoint virtualbox on my pc (I use Windows 7, 64bit)
- set the correct switches on the cairnsmore for programming (at this point the cm is completely off: not powered, and not connected through USB)
(switches depending on your bitstream, but for the Makomk bitstreams: SW1: 3 off, others on; SW6: 1 off, others on; SW2/SW5: all on; SW3/SW4: 2 off, others on)
- login to the enterpoint virtualbox (root/password)
- power on the cm1 (power only), and wait for about 3 minutes
- connect the cm1 with usb cable to pc
- verify xc3sprog can connect to the cm: xc3sprog -c cm1 -j
- if ok, continue, otherwise start over again from beginning (better to disconnect the cm and reboot the pc at that point to be absolutly sure)
- program the bitstream:
xc3sprog -c cm1 -p0 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
xc3sprog -c cm1 -p1 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
xc3sprog -c cm1 -p2 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
xc3sprog -c cm1 -p3 -Ixc6lx150.bit shortfin_icarus_cm1_test_190_overclock.bit
each command will take some time, haven't checked but I guess around 10 minutes
- if all commands went ok ("Verify: Success!"), power off the cm1, and disconnect USB cable
- set the switches for mining: SW1: 3 on (others stay as they are)
- boot your mining pc/pi/whatever (if you use the programming pc also for mining, reboot it first!)
- power on the cm1 (power only), and wait for about 3 minutes (leds will be blue at the start, and will all turn to orange after some time)
- connect the cm1 with usb cable to pc
- start cgminer (any new version)
Linux: cgminer --quiet --disable-gpu -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -o http://
Windows: cgminer --disable-gpu -S \\.\COM21 -S \\.\COM23 -o http://
(Starting it like that on Linux will give a warning message that 2 of the devices couldn't be opened, but it will start on the other 2,
on Windows you can also specify \\.\COM20 and \\.\COM22 if the 21 and 23 don't work)
- cm1 should now be mining (leds shouldn't be constantly orange anymore) - let it mine for 48 hours to have stable statistics (MH and U values)
some additional info: I don't use any USB hubs, I just connect straight to my pc; except for mining on my Raspberry Pi, for which I use an unpowered USB hub. To make it work I need to boot the Pi first, enable the ftdi driver (execute with root: modprobe ftdi_sio product=0x8350 vendor=0x0403), connect the unpowered hub first, then connect the c1m to the hub, and then mine.
dunno if this helps...
is it normal that my board #62-0017 makes a high frequency sound when hashing with glasswalker or makomk bitstreams?
none of the bitstreams I tested is working stable, the best one was still twin_test, though also having instable hash rates, but it had the longest periods of stability per day, i.e. hashing at it's full possible hash rates between zero and 12h per day.
I wonder what I can do to get the good results like e.g. toxicocean. Any tips? I already tried countless combinations of usb cables and hubs without success... A friends board (sn>300) is hashing OK on my setup, but I don't have access to another pre#50 board to compare it to mine, still I don't believe in my USB setup being the cause of my problems.
I appreciate any helpful hints while waiting for RMA. I would even go so far as using my soldering iron to apply the still unknown capacitor fix myself if this doesn't void the warranty.
ps. shortfin_dcmwd2_test_140.bit has between zero and one "Accepted" per "new block", this evening I'll flash the twin_test.
none of the bitstreams I tested is working stable, the best one was still twin_test, though also having instable hash rates, but it had the longest periods of stability per day, i.e. hashing at it's full possible hash rates between zero and 12h per day.
I wonder what I can do to get the good results like e.g. toxicocean. Any tips? I already tried countless combinations of usb cables and hubs without success... A friends board (sn>300) is hashing OK on my setup, but I don't have access to another pre#50 board to compare it to mine, still I don't believe in my USB setup being the cause of my problems.
I appreciate any helpful hints while waiting for RMA. I would even go so far as using my soldering iron to apply the still unknown capacitor fix myself if this doesn't void the warranty.
ps. shortfin_dcmwd2_test_140.bit has between zero and one "Accepted" per "new block", this evening I'll flash the twin_test.
I noticed that one of mine does this as well, and i'm pretty sure it's one of the ones that's getting a low U value in cgminer. I'm going to update the boards to the dcm200 bitstream today or tomorrow and i'll let you know what i find out.
is it normal that my board #62-0017 makes a high frequency sound when hashing with glasswalker or makomk bitstreams?
none of the bitstreams I tested is working stable, the best one was still twin_test, though also having instable hash rates, but it had the longest periods of stability per day, i.e. hashing at it's full possible hash rates between zero and 12h per day.
I wonder what I can do to get the good results like e.g. toxicocean. Any tips? I already tried countless combinations of usb cables and hubs without success... A friends board (sn>300) is hashing OK on my setup, but I don't have access to another pre#50 board to compare it to mine, still I don't believe in my USB setup being the cause of my problems.
I appreciate any helpful hints while waiting for RMA. I would even go so far as using my soldering iron to apply the still unknown capacitor fix myself if this doesn't void the warranty.
ps. shortfin_dcmwd2_test_140.bit has between zero and one "Accepted" per "new block", this evening I'll flash the twin_test.
none of the bitstreams I tested is working stable, the best one was still twin_test, though also having instable hash rates, but it had the longest periods of stability per day, i.e. hashing at it's full possible hash rates between zero and 12h per day.
I wonder what I can do to get the good results like e.g. toxicocean. Any tips? I already tried countless combinations of usb cables and hubs without success... A friends board (sn>300) is hashing OK on my setup, but I don't have access to another pre#50 board to compare it to mine, still I don't believe in my USB setup being the cause of my problems.
I appreciate any helpful hints while waiting for RMA. I would even go so far as using my soldering iron to apply the still unknown capacitor fix myself if this doesn't void the warranty.
ps. shortfin_dcmwd2_test_140.bit has between zero and one "Accepted" per "new block", this evening I'll flash the twin_test.
I'm currently running the dcmwd2_200 bitstream on my #0005 board (controller v1.3), and it has been running smooth for a good 42 hours now.
Only thing I noticed is that it seems to be a bit slower than the previous shortfin_190 bitstream (dcmwd2_200 runs at around 722 MH/s, shortfin_190 at about 752 MH/s - as reported by a mining pool. Cgminer reports 775 MH/s for the dcmwd2_200 bitstream and 739 MH/s for the shortfin_190)
Yeah, that can happen, and I can't imagine that the 200 MHz version would run terribly well on a low serial number board. Actually measuring the real effective hash rate is a bit of a pain. Unfortunately not all pools report hash rates as accurately as they perhaps could either. Only thing I noticed is that it seems to be a bit slower than the previous shortfin_190 bitstream (dcmwd2_200 runs at around 722 MH/s, shortfin_190 at about 752 MH/s - as reported by a mining pool. Cgminer reports 775 MH/s for the dcmwd2_200 bitstream and 739 MH/s for the shortfin_190)
I'm currently running the dcmwd2_200 bitstream on my #0005 board (controller v1.3), and it has been running smooth for a good 42 hours now.
Only thing I noticed is that it seems to be a bit slower than the previous shortfin_190 bitstream (dcmwd2_200 runs at around 722 MH/s, shortfin_190 at about 752 MH/s - as reported by a mining pool. Cgminer reports 775 MH/s for the dcmwd2_200 bitstream and 739 MH/s for the shortfin_190)
Only thing I noticed is that it seems to be a bit slower than the previous shortfin_190 bitstream (dcmwd2_200 runs at around 722 MH/s, shortfin_190 at about 752 MH/s - as reported by a mining pool. Cgminer reports 775 MH/s for the dcmwd2_200 bitstream and 739 MH/s for the shortfin_190)
It is the second time that I see an unusual high number of HW: problems
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
what s/n boards do you have? I have 45, 72-80 and i haven't seen ANY HW errors. maybe I don't have cgminer configured correctly to show me them?
You need to apply a patch to cgminer to see HW: or use the latest version released a couple of days ago, I think it is 2.6.3
spiccioli
1. Do I need to do this w/ one board plugged in at a time?
2. If I don't, do all boards need to be idle?
what i do is plug only one of the cm1 (which i want to program) in a laptop .uninstall all usb filters ( in the laptop )and install it again for the new board. then that error dissapear
I'm using the same laptop to run them as I do to flash them, so I'm trying to not unplug all the boards to flash, guess i'm going to have to
Minor bitstream revision: http://www.makomk.com/~aidan/shortfin-dcmwd-20120808.zip
If you're already running the previous one, there's probably no point upgrading. The only difference is that with this one you should be able to disable the array clock with switch 3, temp-upload a bitstream, and re-enable the array clock without having to mess around with flashing and power cycling the whole board. Once you've got a bitstream flashed and running it shouldn't make much difference.
If you're already running the previous one, there's probably no point upgrading. The only difference is that with this one you should be able to disable the array clock with switch 3, temp-upload a bitstream, and re-enable the array clock without having to mess around with flashing and power cycling the whole board. Once you've got a bitstream flashed and running it shouldn't make much difference.
Can you do this and permanently flash the bitstream?
It is the second time that I see an unusual high number of HW: problems
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
what s/n boards do you have? I have 45, 72-80 and i haven't seen ANY HW errors. maybe I don't have cgminer configured correctly to show me them?
It is the second time that I see an unusual high number of HW: problems
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
Code:
cgminer version 2.6.1 - Started: [2012-08-07 21:17:00]
--------------------------------------------------------------------------------
(5s):6845.8 (avg):7432.2 Mh/s | Q:27929 A:111001 R:127 HW:0 E:397% U:100.1/m
TQ: 21 ST: 22 SS: 0 DW: 2780 NB: 120 LW: 189336 GF: 17 RF: 0
Connected to http://eu.ozco.in with LP as user ....
Block: 000001ed239005bf46732ab08477af4d... Started: [15:44:09]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 351.4/357.9Mh/s | A:4882 R: 2 HW: 17 U: 4.40/m
ICA 1: | 372.5/358.0Mh/s | A:4968 R: 7 HW:7004 U: 4.48/m
ICA 2: | 311.4/364.7Mh/s | A:5381 R: 6 HW: 405 U: 4.85/m
ICA 3: | 379.5/377.4Mh/s | A:5773 R: 9 HW:3232 U: 5.21/m
ICA 4: | 365.8/364.6Mh/s | A:5245 R: 6 HW: 7 U: 4.73/m
ICA 5: | 358.8/365.0Mh/s | A:5192 R: 7 HW: 5 U: 4.68/m
ICA 6: | 379.6/379.6Mh/s | A:5724 R: 6 HW: 7 U: 5.16/m
ICA 7: | 379.5/378.1Mh/s | A:5987 R: 4 HW: 58 U: 5.40/m
ICA 8: | 379.7/379.3Mh/s | A:5832 R:10 HW: 14 U: 5.26/m
ICA 9: | 379.7/373.4Mh/s | A:5716 R: 7 HW: 263 U: 5.15/m
ICA 10: | 379.7/378.8Mh/s | A:5718 R: 7 HW: 34 U: 5.16/m
ICA 11: | 379.8/379.8Mh/s | A:5895 R: 5 HW: 5 U: 5.32/m
ICA 12: | 344.9/357.8Mh/s | A:5069 R: 2 HW: 7 U: 4.57/m
ICA 13: | 353.9/358.1Mh/s | A:5028 R: 6 HW: 1 U: 4.53/m
ICA 14: | 379.8/379.1Mh/s | A:5807 R: 3 HW: 940 U: 5.24/m
ICA 15: | 379.7/379.3Mh/s | A:5879 R: 6 HW:7012 U: 5.30/m
ICA 16: | 378.2/364.2Mh/s | A:5481 R: 7 HW: 416 U: 4.94/m
ICA 17: | 379.7/379.4Mh/s | A:5785 R:16 HW:6170 U: 5.22/m
ICA 18: | 379.8/378.9Mh/s | A:5725 R: 6 HW: 27 U: 5.16/m
ICA 19: | 379.6/379.4Mh/s | A:5919 R: 5 HW: 14 U: 5.34/m
--------------------------------------------------------------------------------
[2012-08-08 15:45:48] Accepted 0abab2ce.894d460e ICA 5 pool 0
[2012-08-08 15:45:48] Accepted 6e2644f1.38b5ddd0 ICA 8 pool 0
[2012-08-08 15:45:49] Accepted 95fe325d.d3a35568 ICA 8 pool 0
[2012-08-08 15:45:49] Accepted be904261.547a05bb ICA 7 pool 0
[2012-08-08 15:45:49] Accepted ded736b7.4a9579ab ICA 8 pool 0
[2012-08-08 15:45:49] Accepted a7b9c5c6.c2379ef4 ICA 0 pool 0
[2012-08-08 15:45:50] Accepted f25f84ec.c96549cf ICA 9 pool 0
[2012-08-08 15:45:50] Accepted d76c4fb3.395aa784 ICA 15 pool 0
[2012-08-08 15:45:52] Accepted b1806040.3c4f3497 ICA 17 pool 0
[2012-08-08 15:45:52] Accepted c6752272.c4cb99e6 ICA 6 pool 0
[2012-08-08 15:45:53] Accepted ed9a9ad2.f41377c9 ICA 14 pool 0
[2012-08-08 15:45:54] Accepted cf152c4e.ca339738 ICA 14 pool 0
[2012-08-08 15:45:55] Accepted c23deda9.ae9fd167 ICA 14 pool 0
[2012-08-08 15:45:56] Accepted 1d203a55.33002845 ICA 13 pool 0
[2012-08-08 15:45:56] Accepted fa14b15b.57442b0a ICA 19 pool 0
[2012-08-08 15:45:56] Accepted e22bd3f1.c609b40f ICA 17 pool 0
[2012-08-08 15:45:57] Accepted c66a3ebb.80e9d0fe ICA 11 pool 0
[2012-08-08 15:45:58] Accepted 07a80eb6.3a611af5 ICA 6 pool 0
ICA 1/3/15/17 have a HW: value which is wrong.
All of these boards are running makomk 190 MH/s bitstream (the older one, without watch dog) but ICA0/1 which are running makomk's dcmwd2 160MH/s one.
What can it be that happens here?
spiccioli
Jump to: