OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[SiegeBreaker]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

[GenTarkin]

I couldnt easily find this anywhere, but whats the proper json format for the new "restricted access" feature? vs full access for remote API accessing of cgminer?

I'm not really sure exactly what you mean by your question - but the API-README contains all the info about the API ...

Edit: If you mean the command line parameters then they are in README for the basic command definitions and more details in API-README

figured it out, it was the api-groups addition =)ty for pointing me to api-readme

[Phraust]

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:
...
The error I get when trying with --enable-bitforce is:

Code:

 CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

...

CBAUD is part of termios.h - which is included by termio.h - the same place B115200 comes from.
The actual definition of both of them is in bits/termios.h

Find where B115200 is defined and CBAUD should be in the same place:
 grep B115200 /usr/include/*
 grep B115200 /usr/include/*/*
 grep CBAUD /usr/include/*
 grep CBAUD /usr/include/*/*

If it's missing then all I can guess is that OSX has done something very strange ...

The addition of CBAUD was to fix an old issue that setting the serial BAUD rate should only change the bits that represent the BAUD, not zero everything else.

I ran across this same issue, and tried to do some research into it.  The best I could find was:

http://earthworm.isti.com/trac/earthworm/ticket/151

This is because CBAUD is a Linux extension to the POSIX Terminal I/O definitions. The fix is to use the standard POSIX Terminal I/O functions to set the serial input and output BAUD rates (e.g., if CBAUD is undefined)...

Dunno how to change that in the fpgautils.c file, though that looks to be the root cause since CBAUD is showing up as undeclared.

[-ck]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

https://bitcointalk.org/index.php?topic=28402.msg983090#msg983090

[Krak]

I've been using 2.5 for a while now and it seems like dynamic intensity is broken again. It'll constantly go anywhere from 1 to 14 and when it spikes up to 12-14, the desktop becomes completely unresponsive for several seconds. This also has a negative affect on my second GPU with a static intensity because its hashrate drops by about 50% when the desktop goes unresponsive.

[kano]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

Thanks for the BTC

I keep making 11.04 binaries since my GPU/BFL rig is 11.04 based on my setup script in cgminer and I don't have any 7xxx GPUs (yet)

The GLIBC version ties in with the kernel, so updating GLIBC has a habit of hitting a brick wall at some stage after kernel upgrades stop on any linux distro version.

I'd certainly not want to try building a later GLIBC from scratch coz I'd expect there to be issues that either:
1) I'd not know about and thus be using a potentially buggy GLIBC
 (I'd have to spend a lot of effort looking at all the changes in GLIBC and why they changed)
or
2) would show up as failing to build it on the 11.04 kernel (2.6.38-8) and thus most likely be lots of effort to resolve

It's all pretty much: lots of effort for no real gain for me, and building on 11.04 is simple enough for me with an 11.04 dev VM also.
(interesting for me also is that the binaries I build on 11.04 work on my desktop fc16 too where I have my 2xIcarus)

[Phraust]

Just built this on OSX 10.7.4, but I have trouble getting --enable-bitforce to work, and beeing a newbie on these kind of things I would like if anybody can help. If I can be of any help, I built it with these steps:
...
The error I get when trying with --enable-bitforce is:

Code:

 CC       cgminer-fpgautils.o
fpgautils.c: In function ‘serial_open’:
fpgautils.c:214: error: ‘CBAUD’ undeclared (first use in this function)
fpgautils.c:214: error: (Each undeclared identifier is reported only once
fpgautils.c:214: error: for each function it appears in.)
make[1]: *** [cgminer-fpgautils.o] Error 1
make: *** [install-recursive] Error 1

...

CBAUD is part of termios.h - which is included by termio.h - the same place B115200 comes from.
The actual definition of both of them is in bits/termios.h

Find where B115200 is defined and CBAUD should be in the same place:
 grep B115200 /usr/include/*
 grep B115200 /usr/include/*/*
 grep CBAUD /usr/include/*
 grep CBAUD /usr/include/*/*

If it's missing then all I can guess is that OSX has done something very strange ...

The addition of CBAUD was to fix an old issue that setting the serial BAUD rate should only change the bits that represent the BAUD, not zero everything else.

I ran across this same issue, and tried to do some research into it.  The best I could find was:

http://earthworm.isti.com/trac/earthworm/ticket/151

This is because CBAUD is a Linux extension to the POSIX Terminal I/O definitions. The fix is to use the standard POSIX Terminal I/O functions to set the serial input and output BAUD rates (e.g., if CBAUD is undefined)...

Dunno how to change that in the fpgautils.c file, though that looks to be the root cause since CBAUD is showing up as undeclared.

After some bungling around with fpgautils.c, I managed to get things working.  Where CBAUD is undefined in OSX (why?  dunno...), it throws the error around line 214:

      my_termios.c_cflag &= ~CBAUD;
      my_termios.c_cflag |= B115200;
      break;

So using the link I posted earlier http://earthworm.isti.com/trac/earthworm/ticket/151 as a template, I changed it to this:

   #ifdef CBAUD
           my_termios.c_cflag &= ~CBAUD;     // baudrate mask
             my_termios.c_cflag |=  B115200;   // baudrate
   #else
           cfsetispeed( &my_termios, B115200 );
           cfsetospeed( &my_termios, B115200 );
   #endif
      break;

This allowed it to compile in OSX, and I'm currently testing it out now.  Any help regarding the change I made would be awesome, as it LOOKS like it worked (it's mining right now), but I have no idea if this breaks anything else.

Oh, I have uploaded my updated version here: http://bitcoin.phraust.com/fpgautils.c

[Inaba]

So there seems to be some bugs in cgminer (and bfgminer) in relation to ridiculous number of units.  Here's basically the setup:

With more than ~30-32 units, if you try to launch cgminer from the command line without a .conf file and without -q, cgminer will hang.  Adding -q and controlling things from the API and having a .conf file with your pools in it seems to bypass the issue and will mine with a lot of units, far in excess of 32 units.  I can reproduce this repeatedly... but if I do, it tends to kill the BFL units which require a power cycle.. so I'm thinking i'ts something to do with the BFL initialization routines, possibly.

This is on Linux, I did not test Windows.  Latest git as of this writing (2.5.0).

[SiegeBreaker]

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!

./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./cgminer)
./cgminer: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./cgminer)

That's why I recently added xubuntu 11.04 builds of the binary in my git download for anyone who still uses ubu 11.04 or similar and doesn't want to build from source:
https://github.com/kanoi/cgminer/downloads

Kano, sent some bitcs your way for saving me an OS upgrade. Seriously, why is it required to upgrade your OS for a new version of software? Shouldn't there be an easy way to just get the new GLIBC installed on an old version?

Thanks for the BTC

I keep making 11.04 binaries since my GPU/BFL rig is 11.04 based on my setup script in cgminer and I don't have any 7xxx GPUs (yet)

The GLIBC version ties in with the kernel, so updating GLIBC has a habit of hitting a brick wall at some stage after kernel upgrades stop on any linux distro version.

I'd certainly not want to try building a later GLIBC from scratch coz I'd expect there to be issues that either:
1) I'd not know about and thus be using a potentially buggy GLIBC
 (I'd have to spend a lot of effort looking at all the changes in GLIBC and why they changed)
or
2) would show up as failing to build it on the 11.04 kernel (2.6.38-8) and thus most likely be lots of effort to resolve

It's all pretty much: lots of effort for no real gain for me, and building on 11.04 is simple enough for me with an 11.04 dev VM also.
(interesting for me also is that the binaries I build on 11.04 work on my desktop fc16 too where I have my 2xIcarus)

Thanks for the explanation, Kano. I figured it was coupled to the OS fairly tightly or else I would have been able to find some how-to googling, your explanation is a lot better than anything I found online.

cklovias, I understand that at some point you have to move on (although I don't know specifically what new feature was required in the newer version, I know you are smart enough to not just rebase to the new version for fun). My gripe is with the linux setup, not with your excellent software.

Thanks to both of you for all your work!

[BlackPrapor]

In win7x64 after updating to 2.5.0 cgminer would hang up right after start. I'm using catalyst 12.5 and 6950 video cards. Currently went back to 2.4.1

[tucenaber]

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?

[UnderGod]

Hi there, been using cgminer on Windows 7 for quite a bit now, decided to go back to linux, not without problems offcourse :]
I have a 6990, with windows cgminer sees gpu0 and gpu1 and happily mines on both.
In linux cgminer only sees gpu0.
cgminer -n shows only one gpu.
Does anyone have an idea where I should start to look why he doesn't want to see the second gpu?
Thanks

[TheHarbinger]

Hi there, been using cgminer on Windows 7 for quite a bit now, decided to go back to linux, not without problems offcourse :]
I have a 6990, with windows cgminer sees gpu0 and gpu1 and happily mines on both.
In linux cgminer only sees gpu0.
cgminer -n shows only one gpu.
Does anyone have an idea where I should start to look why he doesn't want to see the second gpu?
Thanks

I will give you a hint.  It's in the README.

[TheHarbinger]

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?

I thought it was supposed to be timing=short?

[tucenaber]

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.

[tucenaber]

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?

[kano]

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?
 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

[tucenaber]

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...

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.956e⁹/4295032833 = 69.23 shares/minute.

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

[kano]

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.956e⁹/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.

Wrong.

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

[tucenaber]

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.956e⁹/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.

Wrong.

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

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.