works for me, hopefully it works elsewhere too
https://github.com/downloads/pshep/cgminer/cgminer-2.4.3-win32.zip
Topic: Looking for FPGA cgminer testers. (Read 3733 times)
made a windows binary with ocl and all fpga's.
works for me, hopefully it works elsewhere too
https://github.com/downloads/pshep/cgminer/cgminer-2.4.3-win32.zip
works for me, hopefully it works elsewhere too
https://github.com/downloads/pshep/cgminer/cgminer-2.4.3-win32.zip
I have 4 icarus on win7 32.
No idea how to compile it, so if you can run me up a win32 executable I can test it with icarus hardware.
kind regards
No idea how to compile it, so if you can run me up a win32 executable I can test it with icarus hardware.
kind regards
I've got a X6500 and an Asus E450 ITX board on order. After they come in and I have time to find the right Linux OS to use for my FPGA controller, I'll try your version.
Alright Kano, you win. Trivial to add, so I've done it...
if either user or pool set to not accept stales, work reset is checked, else it carries on with the job and submits the stales.
if either user or pool set to not accept stales, work reset is checked, else it carries on with the job and submits the stales.
Hmm - you seem to have completely missed the point of my last post.
Yes aborting work should be an option.
However, it must only do that when told to - i.e. if the user specified --no-submit-stale (and the getwork doesn't say to submit stales)
If you abort work on a pool that does accept stales, then you are reducing the number of accepted shares with BFL devices.
You're giving an example based on some pool that doesn't accept stales - which of course would mean you should use --no-submit-stale and then your new BFL code should abort work.
Yes aborting work should be an option.
However, it must only do that when told to - i.e. if the user specified --no-submit-stale (and the getwork doesn't say to submit stales)
If you abort work on a pool that does accept stales, then you are reducing the number of accepted shares with BFL devices.
You're giving an example based on some pool that doesn't accept stales - which of course would mean you should use --no-submit-stale and then your new BFL code should abort work.
It still does submit stales though. My logs still show plenty being submitted, just not the 2-3% I was getting. Now it's 0.4%.
I see you point, stick to what the command has set... but if you do that, one way or the other you lose performance.
Disable stales:
No stales are submitted potentially losing valid shares
Re-start work quickly and get on with new block
Enable stales:
Potentially gain some shares through submitting stales
Potentially lose up to 5s of work on each device
It's marginal either way, but why not take the best from both worlds and maximise as far as we can the performance, at the sacrifice not strictly doing what the user has asked. How many users do you think give a crap about whether stales are submitted or not over getting the best performance? My U has gone up about 0.5 from 69.2 to 69.7. Fred's has gone up 0.8.
If BFL worked the way every other device worked and returned a result as soon as it found it, of course we'd do it your way. We've got to handle what we're dealt the best we can, eh?
I see you point, stick to what the command has set... but if you do that, one way or the other you lose performance.
Disable stales:
No stales are submitted potentially losing valid shares
Re-start work quickly and get on with new block
Enable stales:
Potentially gain some shares through submitting stales
Potentially lose up to 5s of work on each device
It's marginal either way, but why not take the best from both worlds and maximise as far as we can the performance, at the sacrifice not strictly doing what the user has asked. How many users do you think give a crap about whether stales are submitted or not over getting the best performance? My U has gone up about 0.5 from 69.2 to 69.7. Fred's has gone up 0.8.
If BFL worked the way every other device worked and returned a result as soon as it found it, of course we'd do it your way. We've got to handle what we're dealt the best we can, eh?
...
Well, that's the thing, either way the work is lost, no? It's a matter of minimizing work lost. We can submit shares which may/may not be accepted, or we can restart work which we know will be accepted. As you say, this is only really a problem on P2Pool, which is problem anyway, so what's lost?
Well, no it's not an actual problem as such.Well, that's the thing, either way the work is lost, no? It's a matter of minimizing work lost. We can submit shares which may/may not be accepted, or we can restart work which we know will be accepted. As you say, this is only really a problem on P2Pool, which is problem anyway, so what's lost?
How the code must work is quite straight forward - as I said:
If --no-submit-stale is set and the getwork didn't say to submit stale, then yes abort.
i.e. the choice is the user's with using "--no-submit-stale" or the pool's by saying to submit stale in the getwork
Actually it'd be interest to get real performance data from someone with BFLs to mine on P2Pool with the existing 2.4.3, and my version. I'm quite curious 
Not sure if you are doing this so:
As I have mentioned to luke-jr so I'll mention to you also
The BFL abort should only be done if --no-submit-stale is enabled and the getwork said to not submit stale.
(i.e. you need to somehow check those two before aborting the work)
Reasons:
1) If you abort work on a pool that allows stale shares, then when you abort you may be throwing away shares (since BFL doesn't tell you what shares you have worked out already when you abort the work) - so on such a pool (or a getwork that says to submit stale) you'd never abort the work
2) On p2pool only ~1 in every ~60 LPs represent a real BTC LP - for all other LP's, if the stale work is a full difficulty block, it is a valid payable BTC block - and p2pool will send it to the bitcoind ... and throwing away blocks is bad
Of course no one in their right mind would mine on p2pool with a BFL since either you throw away blocks or you throw away shares - you must do one or the other with a BFL on p2pool.
As I have mentioned to luke-jr so I'll mention to you also
The BFL abort should only be done if --no-submit-stale is enabled and the getwork said to not submit stale.
(i.e. you need to somehow check those two before aborting the work)
Reasons:
1) If you abort work on a pool that allows stale shares, then when you abort you may be throwing away shares (since BFL doesn't tell you what shares you have worked out already when you abort the work) - so on such a pool (or a getwork that says to submit stale) you'd never abort the work
2) On p2pool only ~1 in every ~60 LPs represent a real BTC LP - for all other LP's, if the stale work is a full difficulty block, it is a valid payable BTC block - and p2pool will send it to the bitcoind ... and throwing away blocks is bad
Of course no one in their right mind would mine on p2pool with a BFL since either you throw away blocks or you throw away shares - you must do one or the other with a BFL on p2pool.
Well, that's the thing, either way the work is lost, no? It's a matter of minimizing work lost. We can submit shares which may/may not be accepted, or we can restart work which we know will be accepted. As you say, this is only really a problem on P2Pool, which is problem anyway, so what's lost?
Not sure if you are doing this so:
As I have mentioned to luke-jr so I'll mention to you also
The BFL abort should only be done if --no-submit-stale is enabled and the getwork said to not submit stale.
(i.e. you need to somehow check those two before aborting the work)
Reasons:
1) If you abort work on a pool that allows stale shares, then when you abort you may be throwing away shares (since BFL doesn't tell you what shares you have worked out already when you abort the work) - so on such a pool (or a getwork that says to submit stale) you'd never abort the work
2) On p2pool only ~1 in every ~60 LPs represent a real BTC LP - for all other LP's, if the stale work is a full difficulty block, it is a valid payable BTC block - and p2pool will send it to the bitcoind ... and throwing away blocks is bad
Of course no one in their right mind would mine on p2pool with a BFL since either you throw away blocks or you throw away shares - you must do one or the other with a BFL on p2pool.
As I have mentioned to luke-jr so I'll mention to you also
The BFL abort should only be done if --no-submit-stale is enabled and the getwork said to not submit stale.
(i.e. you need to somehow check those two before aborting the work)
Reasons:
1) If you abort work on a pool that allows stale shares, then when you abort you may be throwing away shares (since BFL doesn't tell you what shares you have worked out already when you abort the work) - so on such a pool (or a getwork that says to submit stale) you'd never abort the work
2) On p2pool only ~1 in every ~60 LPs represent a real BTC LP - for all other LP's, if the stale work is a full difficulty block, it is a valid payable BTC block - and p2pool will send it to the bitcoind ... and throwing away blocks is bad
Of course no one in their right mind would mine on p2pool with a BFL since either you throw away blocks or you throw away shares - you must do one or the other with a BFL on p2pool.
Thanks for that Kano, I'm just about ready to submit a pull request now, Sorting out one more thing...
Looks good there fred
Looks good there fred
Some numbers from testing BFL rev2 x16 running 800Mh/s Firmware
I disrupted the results by disconnecting the power on one unit mistakenly and did not notice, so results might be a teeny bit better for the pshep changes to cgminer.
Running under ubuntu 12.04 64-bit
I disrupted the results by disconnecting the power on one unit mistakenly and did not notice, so results might be a teeny bit better for the pshep changes to cgminer.
Running under ubuntu 12.04 64-bit
| CGMiner | Reject | Accepted | Util | MH/s | Getwork | Remote | Local | Discard | Found | HW Err | Network | Uptime hh:mm:ss | Rej % | Eff |
| std | 8249 | 700825 | 174.83 | 12514 | 92038 | 8 | 700853 | 9102 | 0 | 0 | 448 | 66:48:43 | 1.16% | 761% |
| pshep | 588 | 367158 | 175.68 | 12575 | 39888 | 102 | 353390 | 3685 | 0 | 0 | 213 | 34:49:58 | 0.16% | 920% |
Oh - you have a thread.
You didn't mention that
Yeah been running for a while - but it's 1:45am
I'll leave it running overnight anyway.
If you show up shortly in #cgminer I'll give you the link to see my rig (or in the morning when I wake up)
But yeah it's mining and showing the same av MH/s mine does.
You didn't mention that
Yeah been running for a while - but it's 1:45am
I'll leave it running overnight anyway.
If you show up shortly in #cgminer I'll give you the link to see my rig (or in the morning when I wake up)
But yeah it's mining and showing the same av MH/s mine does.
Great
Just need someone who has an FPGA other then BFL to test it...
Just need someone who has an FPGA other then BFL to test it...
Just wanted to update, it's been 24 hours and it's working like a champ, a solid 8.5gh with no issues.
I guess there's no hope for scan-serial to work for BFL's in Windows, eh?
Well I don't know... an ugly way maybe just to try an open each port in turn. But then where do you stop... 8? 16? 100? That might take a while...
Of course. Separate pool of "test" threads (say 10-20) could signal the main "scan" thread when they are done so that new port can be assigned to be scanned. The upper limit can be read from the OS. The "scan" thread would assign "untested" ports to worker "test" threads.
The BFL I/O code should be non-blocking, overlapped IO so that scanning can be stopped if needed.
When/if this is accepted, I'll look into it. I also want to have it scan port during operation so you can yank out and replace/add devices while it's running.
Not sure if this helps, but reserved for use COM identifiers are located here. Records in a key of sorts what has ever been assigned - offline devices, too.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\COM Name Arbiter
Problem with this method is unplug/replug of devices without reboot results in incrementing COM id's.
I guess there's no hope for scan-serial to work for BFL's in Windows, eh?
Well I don't know... an ugly way maybe just to try an open each port in turn. But then where do you stop... 8? 16? 100? That might take a while...
Of course. Separate pool of "test" threads (say 10-20) could signal the main "scan" thread when they are done so that new port can be assigned to be scanned. The upper limit can be read from the OS. The "scan" thread would assign "untested" ports to worker "test" threads.
The BFL I/O code should be non-blocking, overlapped IO so that scanning can be stopped if needed.
When/if this is accepted, I'll look into it. I also want to have it scan port during operation so you can yank out and replace/add devices while it's running.
I tried it out on OSX, seems to work pretty well.
With the stock cgminer, I've been noticing a decline in hashrate over the course of about 4 hours (from 8.5gh down to 7.
so I've been restarting it when I notice it dropping. I've been running your version for the last five hours, and it's still up at 8.5gh. Thanks a ton, I'll keep you updated.
I should add that after about 4 hours, one or more of the BFLs will drop below a U of 10 (normally around 8, sometimes down to 6. this behavior started after I moved my rig back, so it might be how I laid everything out, I was thinking it was probably noise across all the USB cables). Right now, they are all at or above 11.8, with one at 11.3, much much better.
With the stock cgminer, I've been noticing a decline in hashrate over the course of about 4 hours (from 8.5gh down to 7.
so I've been restarting it when I notice it dropping. I've been running your version for the last five hours, and it's still up at 8.5gh. Thanks a ton, I'll keep you updated.I should add that after about 4 hours, one or more of the BFLs will drop below a U of 10 (normally around 8, sometimes down to 6. this behavior started after I moved my rig back, so it might be how I laid everything out, I was thinking it was probably noise across all the USB cables). Right now, they are all at or above 11.8, with one at 11.3, much much better.
I guess there's no hope for scan-serial to work for BFL's in Windows, eh?
Well I don't know... an ugly way maybe just to try an open each port in turn. But then where do you stop... 8? 16? 100? That might take a while...
I guess there's no hope for scan-serial to work for BFL's in Windows, eh?
Well I don't know... an ugly way maybe just to try an open each port in turn. But then where do you stop... 8? 16? 100? That might take a while...
Jump to: