I have not updated cgminer since version 2.4.3 on my win7 x64 box with dual 7970 gpu's running with catalyst 12.6
So when i saw you have released 2 newer versions i firstly installed the 2.5.0 version and restarted my batch with the usual config file
Sadly i see that mining does not start on my pool
Instead i see it reporting that the pool is not providing work fast enough and switches to another pool
Another thing what instant caught my attention is the extreme low mining performance (i run my card on low clocks and temp (750 mhz core / 800 memory speed))
So i downloaded version 2.4.4 to see if that would run normal, but here again same issue.
With the 2.4.3 i get a average mining speed of 850 mh but with the newer versions i get an enormous drop in speed and again the failure to run at the pool i wish as my primary pool
When i use the newer versions i get with both cards a mining speed between 500 and 620 mh ... my question is why or did i make a mistake in the config
here is the parameter part of my config file
"intensity" : "7",
"gpu-engine" : "750",
"gpu-memclock" : "800",
"temp-overheat" : "85",
"temp-cutoff" : "95",
"temp-target" : "75",
"failover-only" : true,
"gpu-threads" : "2",
"retry-pause" : "5",
"scan-time" : "60",
"worksize" : "256",
"expiry" : "120",
"vectors" : "2",
"algo" : "auto",
"queue" : "1",
"log" : "5"
}
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 542. (Read 5805728 times)
July 09, 2012, 06:36:55 PM
July 09, 2012, 05:47:03 PM
The benchmark only tests with a single pre-defined getwork repeatedly.
That's not a test of both cases on the Icarus.
As I said above, the Icarus has 2 cases
1) Find a share
2) Abort before idle
Anyway, what did debug tell you?
It should hopefully make it quite clear what is going on.
The reason I mentioned benchmarking was beacause you started to talk about timing issues and misbehaving hardware, so I pointed out that benchmarking should then show that. But it doesn't show that. Do you understand?That's not a test of both cases on the Icarus.
As I said above, the Icarus has 2 cases
1) Find a share
2) Abort before idle
Anyway, what did debug tell you?
It should hopefully make it quite clear what is going on.
As you point out there are two cases, and only one is involved in benchmarking. From that I conclude that the problem is lurking in the second case.
I have also concluded that it is probably related to the short expiration time on p2pool, because otherwise everybody with an Icarus would experience the issue, and it doesn't seem to be that way.
The debugging info told me that the number of hashes is written in hex
Apart from that not so much (yet). Looking at the source haven't gotten me far either.I also have another more serious problem, that may or may not be related and about which I have been posting in the p2pool thread. The problem is that I get lots (like 7%) of duplicate shares from cgminer. It turns out that some of these are rolled past the expiry (=10s) by cgminer and I don't understand that issue either
If you turn on protocol debug it will tell you what p2pool is telling you to do with rolled shares and expiry.
If there is an issue with the rolltime/expiry supplied by the pool, cgminer will use --expiry and --scan-time to work out what to do.
As for Icarus - in debug mode it reports the result of each piece of work it does and how long it took to run.
That should make it clear what is going on.
The 2 cases give debug:
1) Icarus %d nonce = 0x%08x = 0x%08llx hashes (%ld.%06lds)
2) Icarus %d no nonce = 0x%08llx hashes (%ld.%06lds)
And also for case 2) you should get a line before it saying:
Icarus Read: No data in %.2f seconds
Since you compiled cgminer yourself, also try using the binary release to see if that makes any difference (probably not though)
July 09, 2012, 05:30:37 PM
I have been running it for weeks. That is also not the issue.
July 09, 2012, 05:22:05 PM
Not to argue with anyone but my hashrate took 3 days to get to my expected value. It had kinda wild swings for 2 days for sure. The near instant hashrate reported what I expected. 860Mh but the average at 10 mins was 600Mh, after a day it got up to aound 800 and now it is finally nearly 844. It should hopefully land on 848 or so after long enough but above average LP could keep it down. Maybe let it run since the reported rate seems right for P2Pool and see if it evens out?
July 09, 2012, 05:09:48 PM
The benchmark only tests with a single pre-defined getwork repeatedly.
That's not a test of both cases on the Icarus.
As I said above, the Icarus has 2 cases
1) Find a share
2) Abort before idle
Anyway, what did debug tell you?
It should hopefully make it quite clear what is going on.
The reason I mentioned benchmarking was beacause you started to talk about timing issues and misbehaving hardware, so I pointed out that benchmarking should then show that. But it doesn't show that. Do you understand?That's not a test of both cases on the Icarus.
As I said above, the Icarus has 2 cases
1) Find a share
2) Abort before idle
Anyway, what did debug tell you?
It should hopefully make it quite clear what is going on.
As you point out there are two cases, and only one is involved in benchmarking. From that I conclude that the problem is lurking in the second case.
I have also concluded that it is probably related to the short expiration time on p2pool, because otherwise everybody with an Icarus would experience the issue, and it doesn't seem to be that way.
The debugging info told me that the number of hashes is written in hex
Apart from that not so much (yet). Looking at the source haven't gotten me far either.I also have another more serious problem, that may or may not be related and about which I have been posting in the p2pool thread. The problem is that I get lots (like 7%) of duplicate shares from cgminer. It turns out that some of these are rolled past the expiry (=10s) by cgminer and I don't understand that issue either
July 09, 2012, 04:33:28 PM
Now I'm starting to doubt your reading capabilities...
I said a "rough" estimate of U, and the utility is not the issue here. My actual hashrate is more or less what it shoud be, both according to "utility" and to p2pool stats. There.
The issue is the cgminer hashrate estimate which is less than 60% of what it should be.
I also rule out timing issues and termios because it is fully capable to get it right when benchmarking.
The benchmark only tests with a single pre-defined getwork repeatedly.I said a "rough" estimate of U, and the utility is not the issue here. My actual hashrate is more or less what it shoud be, both according to "utility" and to p2pool stats. There.
The issue is the cgminer hashrate estimate which is less than 60% of what it should be.
I also rule out timing issues and termios because it is fully capable to get it right when benchmarking.
That's not a test of both cases on the Icarus.
As I said above, the Icarus has 2 cases
1) Find a share
2) Abort before idle
Anyway, what did debug tell you?
It should hopefully make it quite clear what is going on.
July 09, 2012, 03:20:48 PM
Hey people before now I've been using Kiv's GUIminer but I got some brand new BFL singles that I need to use and I think cgminer is the most widely used and has bitforce enabled but I keep getting an error that I can't seem to find documented anywhere idk but here's the issue. When I try to open this "cgminer.exe" it opens for a second or so then shuts down doesn't mine or anything just quits. Also when I tried to build cgminer using the instructions in the "windows-build.txt" I get to the last step before running the "make" command in mingw the "CFLAGS="-02 -msse2" ./configure" command and I get and error message that I can't understand:
and when I open the config.log it displays this:
someone else when I made my own thread in the newb boards directed me to something he's written for ozcoin which is https://ozcoin.net/content/win7-cgminer-setup-guide. I've tried that and it works but I get the same instant shutdown thing. If someone could help me build and run this thing it would be much appreciated or if someone knows that the fix for my problems have been mentioned earlier in this or another thread it would also be greatly appreciated if you could tell me which thread so I can go and read through it and not trouble you guys any further.
its -O2 not -02 it's the Letter O not the number zero Code:
$ CFLAGS="-02 -msse2" ./configure
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/XXXXX/cgminer-2.4.2-win32':
configure: error: C compiler cannot create executables
See `config.log' for more details
and when I open the config.log it displays this:
Code:
$ config.log
./config.log: line 1: This: command not found
./config.log: line 2: running: command not found
./config.log: line 4: It: command not found
./config.log: line 5: generated: command not found
./config.log: line 7: $: command not found
hostname: extra operand `XXXXX-PC'
Try `hostname --help' for more information.
uname: extra operand `='
Try `uname --help' for more information.
./config.log: line 15: syntax error near unexpected token `('
./config.log: line 15: `uname -r = 1.0.17(0.48/3/2)'
someone else when I made my own thread in the newb boards directed me to something he's written for ozcoin which is https://ozcoin.net/content/win7-cgminer-setup-guide. I've tried that and it works but I get the same instant shutdown thing. If someone could help me build and run this thing it would be much appreciated or if someone knows that the fix for my problems have been mentioned earlier in this or another thread it would also be greatly appreciated if you could tell me which thread so I can go and read through it and not trouble you guys any further.
July 09, 2012, 03:02:20 PM
Wrong.
...
Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing
If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.
...
Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing
If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.
Well, in my setup, on Windows 7, abort time changes the hash rate. the utility does not change much, but hash rate is very sensitive to abort time.
Abort time lower than 8 seconds (80), increases the hash rate, higher than 8 secs (80) lowers the hash rate.
BTW, I've played with many timings, and 6.5 seconds abort time produce best utility rate. I don't care about the hash rate reported by the cgminer. Number of submitted, valid shares per minute is what makes money. So who cares if cgminer is reporting 410 or 210 Mh/s. If utility is 5.35, I'm a happy camper.
On Windows 7 (64bit), the new icarus code barely gets utility of 5.
Kano, maybe you optimized too much for Unix and Windows performance took a hit.
July 09, 2012, 02:59:23 PM
cgminer has stale x2 greater than DiabloMiner
on deepbit
(0.24%) Prop.
(0.21%) Prop.
(0.19%) Prop.
(0.23%) Prop.
(0.11%) Prop. - DiabloMiner
(0.20%) Prop.
(0.20%) Prop.
(0.23%) Prop.
(0.22%) Prop.
(0.24%) Prop.
(0.37%) Prop.
(0.22%) Prop.
on deepbit
(0.24%) Prop.
(0.21%) Prop.
(0.19%) Prop.
(0.23%) Prop.
(0.11%) Prop. - DiabloMiner
(0.20%) Prop.
(0.20%) Prop.
(0.23%) Prop.
(0.22%) Prop.
(0.24%) Prop.
(0.37%) Prop.
(0.22%) Prop.
July 09, 2012, 11:08:46 AM
Con, have you ever considered signing your cgminer binary releases with gpg using one of your gpg keys or a new one?
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x65483BFADA7A9915
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x65483BFADA7A9915
July 09, 2012, 10:59:51 AM
... press 'd' and 'd' ...
July 09, 2012, 10:57:53 AM
Now I'm starting to doubt your reading capabilities...
I said a "rough" estimate of U, and the utility is not the issue here. My actual hashrate is more or less what it shoud be, both according to "utility" and to p2pool stats. There.
The issue is the cgminer hashrate estimate which is less than 60% of what it should be.
I also rule out timing issues and termios because it is fully capable to get it right when benchmarking.
I said a "rough" estimate of U, and the utility is not the issue here. My actual hashrate is more or less what it shoud be, both according to "utility" and to p2pool stats. There.
The issue is the cgminer hashrate estimate which is less than 60% of what it should be.
I also rule out timing issues and termios because it is fully capable to get it right when benchmarking.
July 09, 2012, 10:48:24 AM
...
Thank you. That was informative, but I'm not on windows and my hashrate estimate is clearly way off. When running with --benchmark all devices report a hashrate close to 380MH/s, so there is nothing wrong with the devices. Furthermore the utility is more or less constant at all settings (except with really low abort time, but that is expected). It is true that it takes a long time to get a good estimate of utility, but the rough neighbouhood can be achieved in an hour or so, especially when averaging over 10 devices.
So my conclusion is that the estimation has a bug and it doesn't do what it (and you) says it does. I guess I have to try to decipher the source to try to find it.
No, an hour is not long enough to get a reliable estimate for U:Thank you. That was informative, but I'm not on windows and my hashrate estimate is clearly way off. When running with --benchmark all devices report a hashrate close to 380MH/s, so there is nothing wrong with the devices. Furthermore the utility is more or less constant at all settings (except with really low abort time, but that is expected). It is true that it takes a long time to get a good estimate of utility, but the rough neighbouhood can be achieved in an hour or so, especially when averaging over 10 devices.
So my conclusion is that the estimation has a bug and it doesn't do what it (and you) says it does. I guess I have to try to decipher the source to try to find it.
An hour is probably long enough to get an estimate that is within 10%
10% of 5.3 is of course 0.53 so it could read as high 5.83 or as low as 4.77 after an hour and not be unexpected.
Even averaging over 10 devices is the equivalent of only running for 10 hours.
As I said, you'd need a few days running to START to converge on the expected value for U:
That's random probability - nothing do with code.
Easiest way to show this is to look at my 6950 GPU.
After 28hrs runtime it reads 365.96MH/s but has a U: of 5.00 - that's out by 2%
The GPU code counts all hashes exactly - no calculations involved - just simply adding them up.
Of course that 2% could be higher and I'd not consider that unexpected either.
Anyway, if you want to see exactly what's happening, then in the cgminer screen press 'd' then 'd' and look for the all "Icarus" messages.
It will tell you all the timing calculations it is doing.
However, as I said before, the timing of the termios must be correct (that includes the computer clock and of course you should be using ntp - and ntp can also tell you how good or bad your clock is)
Edit: since you mentioned p2pool before, then also taking the small effect of 10s LP's into consideration:
Each LP loses 0.1s of processing time - i.e. 1% - so you will certainly expect to lose 3 or 4 MH/s from that also.
Edit2: though I should have said this at the start - you can easily determine if it is somehow p2pool related by trying it on a normal pool
July 09, 2012, 10:12:01 AM
Decreasing the time from 112 to 60 results in an increased hashrate to ~275MH/s. About 25%. Better but no cigarr...
The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e9/4295032833 = 69.23 shares/minute.
The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e9/4295032833 = 69.23 shares/minute.
The hash rate is an estimate. If you put 80 as abort time, you'll get a better estimate.
If you put 90 or a 100, your hash rate estimate will be lower.
In my setup, the new icarus code does weird things (hash rates swing wildly), my utility rarely goes above 5/min.
With the old icarus code (some small mods by me, see my site) I get consistently 26.80/min out of my 5 icarus boards.
I stopped using the latest greatest icarus code as it is making me less money.
BTW, I'm using 6.5 secs to abandon previously submitted jobs.
The hash rate is 2 things:
1) If a nonce range returns a share, it is the exact number of hashes that happened and the exact amount of time it took.
2) If a nonce range did not return a share by the time the abort counter was reached, it is the calculated number of hashes that should have been done in the exact time from start to abort based on the Hs value (which is also correct for a standard Icarus Rev3)
--icarus-timing allows you to calculate/specify the Hs time and abort time for non-standard Icarus Rev3 (different bitstream) or non Icarus devices that use the Icarus bitstream.
Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing
If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.
Some time in the ... future ... I'm going to rewrite that code to not rely on the OS being accurate with timing
My linux xubuntu 11.04 is very accurate with the termios timing and never has issues of running past the full nonce time (and ending up idle)
Your code is also using that same termios timing and that is probably why you have to set it to such a low abort value when it really should be 11.2/11.3
A standard Icarus Rev3 hashes at ~380Mh/s
That equates to a U: of 5.31 x 5 = 26.54
A U: of 26.80 over 5 devices is 383.6MH/s
Utility is random, it takes a few days to START to converge on it's expected value.
Also, you cannot get it to hash at max MH/s constantly, LP's will reduce that by about 0.6MH/s
So my conclusion is that the estimation has a bug and it doesn't do what it (and you) says it does. I guess I have to try to decipher the source to try to find it.
July 09, 2012, 09:11:02 AM
Decreasing the time from 112 to 60 results in an increased hashrate to ~275MH/s. About 25%. Better but no cigarr...
The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e9/4295032833 = 69.23 shares/minute.
The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e9/4295032833 = 69.23 shares/minute.
The hash rate is an estimate. If you put 80 as abort time, you'll get a better estimate.
If you put 90 or a 100, your hash rate estimate will be lower.
In my setup, the new icarus code does weird things (hash rates swing wildly), my utility rarely goes above 5/min.
With the old icarus code (some small mods by me, see my site) I get consistently 26.80/min out of my 5 icarus boards.
I stopped using the latest greatest icarus code as it is making me less money.
BTW, I'm using 6.5 secs to abandon previously submitted jobs.
The hash rate is 2 things:
1) If a nonce range returns a share, it is the exact number of hashes that happened and the exact amount of time it took.
2) If a nonce range did not return a share by the time the abort counter was reached, it is the calculated number of hashes that should have been done in the exact time from start to abort based on the Hs value (which is also correct for a standard Icarus Rev3)
--icarus-timing allows you to calculate/specify the Hs time and abort time for non-standard Icarus Rev3 (different bitstream) or non Icarus devices that use the Icarus bitstream.
Adjusting the abort time will not change the Hash rate unless there is something wrong either with the device or the computer's termios timing
If you are using 6.5 seconds to abandon jobs then you are aborting work too early.
However the reason you have to do that may be because you are using windows and the termios timing may not be accurate.
Some time in the ... future ... I'm going to rewrite that code to not rely on the OS being accurate with timing
My linux xubuntu 11.04 is very accurate with the termios timing and never has issues of running past the full nonce time (and ending up idle)
Your code is also using that same termios timing and that is probably why you have to set it to such a low abort value when it really should be 11.2/11.3
A standard Icarus Rev3 hashes at ~380Mh/s
That equates to a U: of 5.31 x 5 = 26.54
A U: of 26.80 over 5 devices is 383.6MH/s
Utility is random, it takes a few days to START to converge on it's expected value.
Also, you cannot get it to hash at max MH/s constantly, LP's will reduce that by about 0.6MH/s
July 09, 2012, 04:32:02 AM
Quote
Try --icarus-timing 2.6316=60
and see how that goes
Decreasing the time from 112 to 60 results in an increased hashrate to ~275MH/s. About 25%. Better but no cigarr...and see how that goes
The Utility stays about the same. The total goes from about 69 to 70. But it was correct from the start. Theoretically my total hashrate is 4956MH/s, which should give a utility of 60 x 4.956e9/4295032833 = 69.23 shares/minute.
Quote
What version of cgminer? What OS?
don't have java installed, but I can use netcat:Code:
$ echo -n version|netcat localhost 4028|tr '|' '\n'
STATUS=S,When=1341825320,Code=22,Msg=CGMiner versions,Description=cgminer 2.5.0
VERSION,CGMiner=2.5.0,API=1.14
$ echo -n config|netcat localhost 4028|tr '|' '\n'
STATUS=S,When=1341825320,Code=33,Msg=CGMiner config,Description=cgminer 2.5.0
CONFIG,GPU Count=4,PGA Count=10,CPU Count=0,Pool Count=3,ADL=Y,ADL in use=Y,Strategy=Failover,Log Interval=5,Device Code=GPU ICA ,OS=Linux
$ echo -n stats|netcat localhost 4028|tr '|' '\n'|grep -a 'ID=ICA'
STATS=4,ID=ICA0,Elapsed=4058,Calls=1149,Wait=0.007328,Max=0.000117,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=5,ID=ICA1,Elapsed=4058,Calls=1155,Wait=0.008084,Max=0.000199,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=6,ID=ICA2,Elapsed=4058,Calls=1140,Wait=0.007985,Max=0.000643,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=7,ID=ICA3,Elapsed=4058,Calls=1157,Wait=0.007119,Max=0.000081,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=8,ID=ICA4,Elapsed=4058,Calls=1149,Wait=0.006996,Max=0.000149,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=9,ID=ICA5,Elapsed=4058,Calls=1124,Wait=0.007068,Max=0.000069,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=10,ID=ICA6,Elapsed=4058,Calls=1160,Wait=0.015211,Max=0.000337,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=11,ID=ICA7,Elapsed=4058,Calls=1147,Wait=0.007531,Max=0.000140,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=12,ID=ICA8,Elapsed=4058,Calls=1145,Wait=0.009075,Max=0.000069,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
STATS=13,ID=ICA9,Elapsed=4058,Calls=1161,Wait=0.007518,Max=0.000137,Min=0.000001,read_count=60,fullnonce=11.302546,count=0,Hs=0.000000002631579,W=0.000000,total_values=0,range=0,history_count=0,history_time=0.000000,min_data_count=5,timing_values=0,timing_mode=value,is_timing=false
$ echo -n devs|netcat localhost 4028|tr '|' '\n'|grep -a '^PGA'
PGA=0,Name=ICA,ID=0,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=271.60,MHS 5s=315.51,Accepted=369,Rejected=5,Hardware Errors=0,Utility=5.46,Last Share Pool=0,Last Share Time=1341825314,Total MH=1102250.2917,Frequency=0.00
PGA=1,Name=ICA,ID=1,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=269.40,MHS 5s=320.07,Accepted=367,Rejected=5,Hardware Errors=0,Utility=5.43,Last Share Pool=0,Last Share Time=1341825292,Total MH=1093339.7307,Frequency=0.00
PGA=2,Name=ICA,ID=2,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=272.01,MHS 5s=319.05,Accepted=348,Rejected=3,Hardware Errors=0,Utility=5.14,Last Share Pool=0,Last Share Time=1341825301,Total MH=1103934.3132,Frequency=0.00
PGA=3,Name=ICA,ID=3,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=271.99,MHS 5s=302.06,Accepted=378,Rejected=5,Hardware Errors=0,Utility=5.59,Last Share Pool=0,Last Share Time=1341825319,Total MH=1103838.6265,Frequency=0.00
PGA=4,Name=ICA,ID=4,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=271.59,MHS 5s=333.23,Accepted=370,Rejected=2,Hardware Errors=0,Utility=5.47,Last Share Pool=0,Last Share Time=1341825303,Total MH=1102219.0277,Frequency=0.00
PGA=5,Name=ICA,ID=5,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=270.25,MHS 5s=297.82,Accepted=336,Rejected=5,Hardware Errors=0,Utility=4.97,Last Share Pool=0,Last Share Time=1341825318,Total MH=1096755.9705,Frequency=0.00
PGA=6,Name=ICA,ID=6,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=272.78,MHS 5s=293.71,Accepted=370,Rejected=6,Hardware Errors=0,Utility=5.47,Last Share Pool=0,Last Share Time=1341825320,Total MH=1107036.1526,Frequency=0.00
PGA=7,Name=ICA,ID=7,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=269.22,MHS 5s=336.00,Accepted=379,Rejected=2,Hardware Errors=0,Utility=5.60,Last Share Pool=0,Last Share Time=1341825319,Total MH=1092576.1434,Frequency=0.00
PGA=8,Name=ICA,ID=8,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=273.70,MHS 5s=303.55,Accepted=367,Rejected=0,Hardware Errors=0,Utility=5.43,Last Share Pool=0,Last Share Time=1341825300,Total MH=1110775.4866,Frequency=0.00
PGA=9,Name=ICA,ID=9,Enabled=Y,Status=Alive,Temperature=0.00,MHS av=274.27,MHS 5s=324.41,Accepted=370,Rejected=8,Hardware Errors=0,Utility=5.47,Last Share Pool=0,Last Share Time=1341825313,Total MH=1113103.2650,Frequency=0.00
July 08, 2012, 08:57:53 PM
I might add that running cgminer with --benchmark gives the expected 380MH/s result for my Icarus boards. Switching back to normal mode gives me 220MH/s :-(
Could it be an issue with p2pool-Icarus combo?
What version of cgminer? What OS?Could it be an issue with p2pool-Icarus combo?
java API version
java API config
The numbers to expect on the cgminer screen if everything is working fine are something like:
379.6/376.4Mh/s (give or take a MH/s
)If you are using the current version of cgminer it will also report the timing information in
java API stats
Icarus are pretty static in their performance under normal conditions, so 'short' is really only needed for the other non-Icarus boards where the default settings may be different.
'long' would only be useful on an unstable device
Having the wrong value for Hs (default 2.6316ns) will increase the displayed hash rate if the number is too low (but not affect anything else)
If the number is way too high the Icarus will idle at the end of each nonce range that doesn't find a share - so it will lower the hash rate.
If your device is unstable, then yes it may not get the expected results - I don't have a faulty Icarus to see what happens in that case
Try --icarus-timing 2.6316=60
and see how that goes
Also if you don't already, make sure at least --api-allow is on so you can use
java API stats
to see what the timing is doing
July 08, 2012, 03:15:12 PM
I might add that running cgminer with --benchmark gives the expected 380MH/s result for my Icarus boards. Switching back to normal mode gives me 220MH/s :-(
Could it be an issue with p2pool-Icarus combo?
Could it be an issue with p2pool-Icarus combo?
July 08, 2012, 10:58:04 AM
I thought it was supposed to be timing=short?
According to the FPGA-README, "short" makes it measure for a while and then stop whereas "long" measures continuosly. Anway, I have tried both and the result is the same. It comes up with a number close to the theoretical 1/380e6=2.631579e9, but the hashrate is still wrong. 
July 08, 2012, 10:38:18 AM
cgminer gives the wrong hashrate for my Incarus rev3 boards and I can't understand what I'm doing wrong. According to FPGA-README I shouldn't have to use the icarus-timing option but I have tried different settings anyway, but to no avail. My searches have also come up with nothing, so if anybody can help I would appreciate it.
The hashrate is estimated by cgminer as ~220MH/s instead of the expected 380MH/s even with icarus-timing=long. The "shares mer minute" number (U) seems correct though (around 5.2) and the pool is giving reasonable numbers so there is not a huge issue but if possible I would like to configue cgminer correctly.
Does anybody experience the same thing or perhaps have a solution?
The hashrate is estimated by cgminer as ~220MH/s instead of the expected 380MH/s even with icarus-timing=long. The "shares mer minute" number (U) seems correct though (around 5.2) and the pool is giving reasonable numbers so there is not a huge issue but if possible I would like to configue cgminer correctly.
Does anybody experience the same thing or perhaps have a solution?
I thought it was supposed to be timing=short?
Jump to: