TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 07: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. Sure, doing it from the software side is certainly easier, but fixing it on the FPGA side would also fix some other issues at the same time and allow for a generic interface: - 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?)
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
xiangfu
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 09: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_hostit 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
|
|
|
|
ngzhang (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 10:04:19 AM Last edit: February 08, 2012, 10:22:43 AM by ngzhang |
|
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. Sure, doing it from the software side is certainly easier, but fixing it on the FPGA side would also fix some other issues at the same time and allow for a generic interface: - 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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) 3, this "behavior" is changed in a under-test firmware. the FPGA will continue working until nonce_to. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) check it here: https://github.com/ngzhang/Icarus/tree/master/Downloads/bitsteam/V44, at first, i set the time-out manually, so i just used this work split method, i think it's easier. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) 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
|
|
|
|
TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 01:58:09 PM |
|
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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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. 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. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) 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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif) 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).
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
pieppiep
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 02:19:40 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) FPGA buffer starts at some value 0x? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) ? New value is 0x12345678 Computer sends a byte 0x12 FPGA buffer is now 0x? ![Huh](https://bitcointalk.org/Smileys/default/huh.gif) ??12 Computer 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
|
|
|
|
TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 02:47:03 PM |
|
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?
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
pieppiep
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 03:02:14 PM |
|
I do think so. 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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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.
|
|
|
|
ngzhang (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 03:05:29 PM |
|
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?
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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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, 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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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. ![Embarrassed](https://bitcointalk.org/Smileys/default/embarrassed.gif)
|
|
|
|
andrehorta
Legendary
Offline
Activity: 1261
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 08, 2012, 11: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?
|
|
|
|
TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 12:16:39 AM Last edit: February 09, 2012, 12:59:46 AM by TheSeven |
|
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?
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
hardpick
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 02:26:40 AM |
|
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?
|
|
|
|
ngzhang (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 03:25:16 AM |
|
it's ok
|
|
|
|
|
|
coblee
Donator
Legendary
Offline
Activity: 1654
Merit: 1350
Creator of Litecoin. Cryptocurrency enthusiast.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 05:58:07 PM |
|
|
|
|
|
server
Legendary
Offline
Activity: 892
Merit: 1002
1 BTC =1 BTC
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 06:58:28 PM |
|
Ok, but... I get this with curses installed... C:\TheSeven>miner.py Traceback (most recent call last): File "C:\TheSeven\miner.py", line 331, in <module> exec("import " + configfile + " as config") File "<string>", line 1, in <module> File "C:\TheSeven\default_config.py", line 9, in <module> import frontend.theseven.cursesui File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module> import curses File "C:\Python27\lib\curses\__init__.py", line 15, in <module> from _curses import * ImportError: No module named _curses
|
|
|
|
TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 09:12:37 PM |
|
C:\TheSeven>miner.py Traceback (most recent call last): File "C:\TheSeven\miner.py", line 331, in <module> exec("import " + configfile + " as config") File "<string>", line 1, in <module> File "C:\TheSeven\default_config.py", line 9, in <module> import frontend.theseven.cursesui File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module> import curses File "C:\Python27\lib\curses\__init__.py", line 15, in <module> from _curses import * ImportError: No module named _curses Which one of the curses for windows modules are you using? It has been reported that the second one listed in README.txt works fine, not sure about the other one. If it doesn't, I'll probably remove it.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
server
Legendary
Offline
Activity: 892
Merit: 1002
1 BTC =1 BTC
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 09, 2012, 11:39:52 PM |
|
Which one of the curses for windows modules are you using? It has been reported that the second one listed in README.txt works fine, not sure about the other one. If it doesn't, I'll probably remove it.
I tried both. I'm using w server 2008 x64 and python 2.7. but nevermind... I will try something else C:\TheSeven>miner.py Traceback (most recent call last): File "C:\TheSeven\miner.py", line 331, in <module> exec("import " + configfile + " as config") File "<string>", line 1, in <module> File "C:\TheSeven\default_config.py", line 9, in <module> import frontend.theseven.cursesui File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module> import curses ImportError: No module named curses
C:\TheSeven>miner.py Traceback (most recent call last): File "C:\TheSeven\miner.py", line 331, in <module> exec("import " + configfile + " as config") File "<string>", line 1, in <module> File "C:\TheSeven\default_config.py", line 9, in <module> import frontend.theseven.cursesui File "C:\TheSeven\frontend\theseven\cursesui.py", line 32, in <module> import curses File "C:\Python27\lib\curses\__init__.py", line 7, in <module> from _WCurses import * ImportError: No module named _WCurses
C:\TheSeven>
|
|
|
|
TheSeven
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2012, 12:14:49 AM |
|
Did you install the curses module for the correct python installation? There are separate packages for each combination of python version and architecture (32/64bit), and this needs to match with the python version you're running the miner on.
|
My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
|
|
|
Defkin
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 80
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 10, 2012, 07:18:33 AM |
|
Very nice.....thank you TheSeven ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Just need to change the blue font so i can read it, something to do over the weekend, lol ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fimg339.imageshack.us%2Fimg339%2F4851%2Fscreenof.jpg&t=665&c=w1MfaAUJS1UzSQ)
|
|
|
|
|