Bitcoin Forum
December 07, 2016, 12:39:32 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 [306] 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4821363 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Phraust
Full Member
***
Offline Offline

Activity: 206


Mostly Harmless...


View Profile WWW
July 07, 2012, 09:15:42 PM
 #6101

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481114372
Hero Member
*
Offline Offline

Posts: 1481114372

View Profile Personal Message (Offline)

Ignore
1481114372
Reply with quote  #2

1481114372
Report to moderator
1481114372
Hero Member
*
Offline Offline

Posts: 1481114372

View Profile Personal Message (Offline)

Ignore
1481114372
Reply with quote  #2

1481114372
Report to moderator
1481114372
Hero Member
*
Offline Offline

Posts: 1481114372

View Profile Personal Message (Offline)

Ignore
1481114372
Reply with quote  #2

1481114372
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
July 07, 2012, 11:03:20 PM
 #6102

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!
Quote
./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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Krak
Hero Member
*****
Offline Offline

Activity: 591



View Profile WWW
July 08, 2012, 01:44:20 AM
 #6103

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.

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 08, 2012, 02:18:09 AM
 #6104

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!
Quote
./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 Smiley

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)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Phraust
Full Member
***
Offline Offline

Activity: 206


Mostly Harmless...


View Profile WWW
July 08, 2012, 02:54:20 AM
 #6105

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:

Quote
      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:

Quote

   #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
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
July 08, 2012, 03:00:40 AM
 #6106

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

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
SiegeBreaker
Newbie
*
Offline Offline

Activity: 23


View Profile
July 08, 2012, 06:40:34 AM
 #6107

Hi, What caused this after cgminer-2.4.3-x86_64-built? Have no any problem before 2.4.3. Thanks!
Quote
./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 Smiley

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
Hero Member
*****
Offline Offline

Activity: 584



View Profile
July 08, 2012, 11:05:43 AM
 #6108

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

There is no place like 127.0.0.1
In blockchain we trust
tucenaber
Sr. Member
****
Offline Offline

Activity: 336


View Profile
July 08, 2012, 01:57:34 PM
 #6109

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
Full Member
***
Offline Offline

Activity: 161



View Profile
July 08, 2012, 03:23:42 PM
 #6110

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 Smiley

TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile
July 08, 2012, 03:37:33 PM
 #6111

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 Smiley

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

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile
July 08, 2012, 03:38:18 PM
 #6112

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?

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
tucenaber
Sr. Member
****
Offline Offline

Activity: 336


View Profile
July 08, 2012, 03:58:04 PM
 #6113

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
Sr. Member
****
Offline Offline

Activity: 336


View Profile
July 08, 2012, 08:15:12 PM
 #6114

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
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 09, 2012, 01:57:53 AM
 #6115

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 Smiley)

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 Smiley

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
tucenaber
Sr. Member
****
Offline Offline

Activity: 336


View Profile
July 09, 2012, 09:32:02 AM
 #6116

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

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
af_newbie
Legendary
*
Offline Offline

Activity: 896



View Profile
July 09, 2012, 01:23:11 PM
 #6117

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 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.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 09, 2012, 02:11:02 PM
 #6118

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
tucenaber
Sr. Member
****
Offline Offline

Activity: 336


View Profile
July 09, 2012, 03:12:01 PM
 #6119

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 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.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
July 09, 2012, 03:48:24 PM
 #6120

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 ... 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 [306] 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!