i suggest every one switch to Modular Python Bitcoin Miner
https://bitcointalksearch.org/topic/modular-python-bitcoin-miner-official-thread-62823
Topic: FPGA development board "Icarus" - DisContinued/ important announcement - page 30. (Read 207279 times)
February 09, 2012, 12:14:56 PM
February 08, 2012, 10:45:50 PM
things get eaiser, I create a openwrt package for the router:
http://downloads.qi-hardware.com/people/xiangfu/icarus/icarus-miner_20120209_all.ipk
wiki page have updated:
http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host
xiangfu
http://downloads.qi-hardware.com/people/xiangfu/icarus/icarus-miner_20120209_all.ipk
wiki page have updated:
http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host
xiangfu
I setup the miner.py under TP-Link wr1043nd home router. there is the steps:
http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host
it is using Openwrt. since the python package is too big for the flash. so I cut down a lot of the python stuff. only works fine with miner.py.
and for now it only support monitor only one worker.
if you also want try. please let me know if it doesn't work.
http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host
it is using Openwrt. since the python package is too big for the flash. so I cut down a lot of the python stuff. only works fine with miner.py.
and for now it only support monitor only one worker.
if you also want try. please let me know if it doesn't work.
February 08, 2012, 10:25:16 PM
it's ok
February 08, 2012, 09:26:40 PM
i am lost to what software i should be now using
for more reliable mining under windows 7
bitsteam v4 and queue_ver_with_auto_restart
is this correct?
for more reliable mining under windows 7
bitsteam v4 and queue_ver_with_auto_restart
is this correct?
February 08, 2012, 07:16:39 PM
Can you post a video?
It´s necessary to connect the boards (Icarus) on PC? To connect to the internet? Or Icarus has connection to internet?
It´s necessary to connect the boards (Icarus) on PC? To connect to the internet? Or Icarus has connection to internet?
Yes, you do need to connect these boards to a PC which runs the mining software. The board play's the graphics card's role in mining.
BTW, I'm happy to announce that (experimental) Icarus board support was added to the Modular Python Bitcoin Miner some minutes ago
February 08, 2012, 06:43:11 PM
Can you post a video?
It´s necessary to connect the boards (Icarus) on PC? To connect to the internet? Or Icarus has connection to internet?
It´s necessary to connect the boards (Icarus) on PC? To connect to the internet? Or Icarus has connection to internet?
February 08, 2012, 10:05:29 AM
Ah so this is just a shift register without latches? So the FPGA works on corrupt data (instead of the old work) while work is being uploaded?
Is the nonce counter being reset whenever a byte is received, or how is that handled?
Is the nonce counter being reset whenever a byte is received, or how is that handled?
haha, yes, i use the simplest way as described above. there are no byte counter or some other useless stuff. just a 64 bytes wide shift register.
and the nonce counter will reset when a byte is received, as a very barbarous way.
it's really doesn't matter if the FPGA generates some wrong data, or not calculate all nonce range. the work push need only 5.6ms for 512bit data transform, so i think the loss is acceptable.
I do think so.
This is what I base my answer on,
This is what I base my answer on,
1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work.
So if the rs232 is at 115k2 you waste 512 / 115200 of a second, 4.444444ms which is at 200MH/s a total of 888,889 hashes each time you send new work.cause a 1/2000 speed loss.
February 08, 2012, 10:02:14 AM
I do think so.
This is what I base my answer on,
This is what I base my answer on,
1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work.
So if the rs232 is at 115k2 you waste 512 / 115200 of a second, 4.444444ms which is at 200MH/s a total of 888,889 hashes each time you send new work. February 08, 2012, 09:47:03 AM
Ah so this is just a shift register without latches? So the FPGA works on corrupt data (instead of the old work) while work is being uploaded?
Is the nonce counter being reset whenever a byte is received, or how is that handled?
Is the nonce counter being reset whenever a byte is received, or how is that handled?
February 08, 2012, 09:19:40 AM
How does it know when the next 512bit packet will start? By means of a timeout? I see no other way to determine packet boundaries once a desync has happened with the current protocol. It would wait for the missing byte, and then steal the first byte of the next packet, and so on.
For easier example I change 512bit to 32bit 
FPGA buffer starts at some value 0x?
?New value is 0x12345678
Computer sends a byte 0x12
FPGA buffer is now 0x?
??12Computer sends a byte 0x34
FPGA buffer is now 0x????1234
Computer sends a byte 0x56
FPGA buffer is now 0x??123456
Computer sends a byte 0x78
FPGA buffer is now 0x12345678
New value is 0x87654321
Computer sends a byte 0x87
FPGA buffer is now 0x34567887
Computer sends a byte 0x65 but FPGA doesn't receive
FPGA buffer is still 0x34567887
Computer sends a byte 0x43
FPGA buffer is now 0x56788743
Computer sends a byte 0x21
FPGA buffer is now 0x78874321
FPGA calculates with wrong value
New value is 0xCAFEBABE
Computer sends a byte 0xCA
FPGA buffer is now 0x874321CA
Computer sends a byte 0xFE but FPGA doesn't receive
FPGA buffer is still 0x4321CAFE
Computer sends a byte 0xBA
FPGA buffer is now 0x21CAFEBA
Computer sends a byte 0xBE
FPGA buffer is now 0xCAFEBABE
FPGA calculates with correct value
February 08, 2012, 08:58:09 AM
hi. i review these issue, and :
1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work.
How does it know when the next 512bit packet will start? By means of a timeout? I see no other way to determine packet boundaries once a desync has happened with the current protocol. It would wait for the missing byte, and then steal the first byte of the next packet, and so on.1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work.
2, it's a problem. but not a frequent occurrences. it can be fix by a workID model, as the V1 firmware, but this function generates lots of BUGs... so i return to a simple protocol.
No need for identifying work, the only thing you need is some feedback on when exactly work was accepted. You could for example add a leading byte to the nonce response that identifies the packet type (nonce found or work accepted, possibly some more in the future). Every nonce sent before the work accepted packet would belong to the old work, every nonce sent after that would belong to the new work.3, this "behavior" is changed in a under-test firmware. the FPGA will continue working until nonce_to.
Sounds good. Would be perfect if you also made sure that nonces won't get lost because of that by having a small nonce queue.Having a work queue would also help in using the full keyspace (and thus reducing pool load), but that's not quite as important.
4, at first, i set the time-out manually, so i just used this work split method, i think it's easier.
Well, it doesn't really matter if the fixed bit (per FPGA) is the first or last one right? Tying the LSB value to the FPGA ID is much better from a software point of view (it just behaves like one faster FPGA). February 08, 2012, 05:04:19 AM
If you change the serial protocol a bit, it might work with the SimpleRS232 interface that MPBM provides. This would also fix some other flaws that I've spotted in the interface you're currently using.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
Changing the FPGA firmware is much mode difficult and time-consuming than just modifying the mining software.Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
- Possible desyncs if a byte gets lost on RS232
- Not knowing which work a nonce belongs to that's sent shortly after (or during) work upload
- Wasting mining time by needing a new job after finding a nonce for no good reason? (at least if I understood the protocol specification right)
- No generic way of figuring out the actual hash rate (why don't you split the work into even and odd nonces instead of low and high half?)
hi. i review these issue, and :
1, if a byte lost during the communication, it will generate some wrong data, but at the next work push, it will return to normal. it uses only a simple 512bits shift register to receive work.
2, it's a problem. but not a frequent occurrences. it can be fix by a workID model, as the V1 firmware, but this function generates lots of BUGs... so i return to a simple protocol.
3, this "behavior" is changed in a under-test firmware. the FPGA will continue working until nonce_to.
check it here: https://github.com/ngzhang/Icarus/tree/master/Downloads/bitsteam/V4
4, at first, i set the time-out manually, so i just used this work split method, i think it's easier.
regards.
BTW:
and a script with watch dog timer is pushed to github, check it here:
https://github.com/ngzhang/Icarus/tree/master/miner_software/queue_ver_with_auto_restart
February 08, 2012, 04:51:22 AM
Hi all
I setup the miner.py under TP-Link wr1043nd home router. there is the steps:
http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host
it is using Openwrt. since the python package is too big for the flash. so I cut down a lot of the python stuff. only works fine with miner.py.
and for now it only support monitor only one worker.
if you also want try. please let me know if it doesn't work.
thanks
xiangfu
I setup the miner.py under TP-Link wr1043nd home router. there is the steps:
http://en.qi-hardware.com/wiki/Icarus#Using_TP-link.2Ftl-wr1043nd_as_host
it is using Openwrt. since the python package is too big for the flash. so I cut down a lot of the python stuff. only works fine with miner.py.
and for now it only support monitor only one worker.
if you also want try. please let me know if it doesn't work.
thanks
xiangfu
February 08, 2012, 02:23:56 AM
If you change the serial protocol a bit, it might work with the SimpleRS232 interface that MPBM provides. This would also fix some other flaws that I've spotted in the interface you're currently using.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
Changing the FPGA firmware is much mode difficult and time-consuming than just modifying the mining software.Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
- Possible desyncs if a byte gets lost on RS232
- Not knowing which work a nonce belongs to that's sent shortly after (or during) work upload
- Wasting mining time by needing a new job after finding a nonce for no good reason? (at least if I understood the protocol specification right)
- No generic way of figuring out the actual hash rate (why don't you split the work into even and odd nonces instead of low and high half?)
February 08, 2012, 12:09:42 AM
All that is needed is an east wind
some improvement on 3rd batch:
cooling update
power module efficiency increase 5%
etc
some improvement on 3rd batch:
cooling update
power module efficiency increase 5%
etc
February 07, 2012, 07:52:31 PM
If you change the serial protocol a bit, it might work with the SimpleRS232 interface that MPBM provides. This would also fix some other flaws that I've spotted in the interface you're currently using.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
Changing the FPGA firmware is much mode difficult and time-consuming than just modifying the mining software. Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
February 07, 2012, 07:51:32 PM
Isn't the existing mining software python only? What would prevent it from running on ARM.
Has anyone tried running Icarus off of a Linux router or other such ARM device?
V1 bitstream used TCL script as mining software.Has anyone tried running Icarus off of a Linux router or other such ARM device?
But the protocol is so simple that any programmer can create/modify other miner in less than a day.
February 07, 2012, 06:30:22 PM
Everybody
May i please direct your attention to the following thread:
Modular Python Bitcoin Miner
https://bitcointalksearch.org/topic/modular-python-bitcoin-miner-official-thread-62823
It is a new python only FPGA board hostprogram.
It therefore runs on ethery plattform with python 2.6+ (also ARM etc)
It currently includes a module for the x6500 board.
I would like to advertise the creation of a worker module for the icarus board.
It would certainly benefit all participants.
Im not good at programming high level languages.
So maybe somebody else is willing to do so ?
May i please direct your attention to the following thread:
Modular Python Bitcoin Miner
https://bitcointalksearch.org/topic/modular-python-bitcoin-miner-official-thread-62823
It is a new python only FPGA board hostprogram.
It therefore runs on ethery plattform with python 2.6+ (also ARM etc)
It currently includes a module for the x6500 board.
I would like to advertise the creation of a worker module for the icarus board.
It would certainly benefit all participants.
Im not good at programming high level languages.
So maybe somebody else is willing to do so ?
Isn't the existing mining software python only? What would prevent it from running on ARM.
Has anyone tried running Icarus off of a Linux router or other such ARM device?
February 07, 2012, 05:27:36 PM
If you change the serial protocol a bit, it might work with the SimpleRS232 interface that MPBM provides. This would also fix some other flaws that I've spotted in the interface you're currently using.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
Alternatively the SimpleRS232 interface module could be adapted to fit the current bitstream, but I'd really go for the other way round.
February 07, 2012, 04:37:11 PM
Everybody
May i please direct your attention to the following thread:
Modular Python Bitcoin Miner
https://bitcointalksearch.org/topic/modular-python-bitcoin-miner-official-thread-62823
It is a new python only FPGA board hostprogram.
It therefore runs on ethery plattform with python 2.6+ (also ARM etc)
It currently includes a module for the x6500 board.
I would like to advertise the creation of a worker module for the icarus board.
It would certainly benefit all participants.
Im not good at programming high level languages.
So maybe somebody else is willing to do so ?
May i please direct your attention to the following thread:
Modular Python Bitcoin Miner
https://bitcointalksearch.org/topic/modular-python-bitcoin-miner-official-thread-62823
It is a new python only FPGA board hostprogram.
It therefore runs on ethery plattform with python 2.6+ (also ARM etc)
It currently includes a module for the x6500 board.
I would like to advertise the creation of a worker module for the icarus board.
It would certainly benefit all participants.
Im not good at programming high level languages.
So maybe somebody else is willing to do so ?
Jump to: