Try adding http:// to the url, it doesn't recognize it as an url. Currently there is no validation of input parameters, that code part was added in a hurry to be able to share a first usable edition. But still, you found the first bug, it should abort on MalformedURLException because further tries won't ever succeed. Default behaviour is to try for ever to make sure it starts working again after networking problems occured. Multiple boards with one miner instance and LP are on the todo list  . I'm not sure about scanning the ports though, I wouldn't want a miner to automatically write to all my serial connections. But something like a startup flag would probably be fine. i just add a "http://" but looks like no use... maybe deepbit is a little different? BTW, i'm using windows7 64bit. an additional beg: is it possible to add a valid nonce offset parameter to the program as a debug function? it means add or subtract a constant value to the calculated nonce. this will help me a lot on the debug flow. thankyou~ Looks like I'm gonna jump on the FPGA bandwagon too. Just placed my first order today. Hope everything goes smooth.
Question for ngzhang (apologies if it's been asked before): Can the dev kits be ordered separately? Or they must be bundled with a FPGA board?
i replayed your mail, and certainly , the Dev kit can order separately (with the same price). |
|
|
|
it works good on abcpool.co ,but can not get work on deepbit.net C:\javaminer>java -jar RG7Miner_prerelease.jar ngzhang1983@msn.com_0 1234 pit.deepbit.net:8332 COM7
WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre1
native lib Version = RXTX-2.2-20081207 Cloudhopper Build rxtx.cloudhopper.net
[2012-02-05 00:17:12,697] [WARN] [rg7.rg7miner.WorkMngr][]: Getwork failed (networking problem).
java.net.MalformedURLException: unknown protocol: pit.deepbit.net
at java.net.URL.<init>(Unknown Source) ~[na:1.6.0_30]
at java.net.URL.<init>(Unknown Source) ~[na:1.6.0_30]
at java.net.URL.<init>(Unknown Source) ~[na:1.6.0_30]
at rg7.rg7miner.rpc.RPCControl.send(RPCControl.java:32) ~[rsrc:./:na]
at rg7.rg7miner.WorkMngr.run(WorkMngr.java:66) ~[rsrc:./:na]
at java.lang.Thread.run(Unknown Source) [na:1.6.0_30]
[2012-02-05 00:17:12,704] [TRACE] [rg7.rg7miner.WorkMngr][]: Waiting 1 second(s), then retry.
[2012-02-05 00:17:13,704] [WARN] [rg7.rg7miner.WorkMngr][]: Getwork failed (networking problem).
java.net.MalformedURLException: unknown protocol: pit.deepbit.net
at java.net.URL.<init>(Unknown Source) ~[na:1.6.0_30]
at java.net.URL.<init>(Unknown Source) ~[na:1.6.0_30]
at java.net.URL.<init>(Unknown Source) ~[na:1.6.0_30]
at rg7.rg7miner.rpc.RPCControl.send(RPCControl.java:32) ~[rsrc:./:na]
at rg7.rg7miner.WorkMngr.run(WorkMngr.java:66) ~[rsrc:./:na]
at java.lang.Thread.run(Unknown Source) [na:1.6.0_30]
[2012-02-05 00:17:13,705] [TRACE] [rg7.rg7miner.WorkMngr][]: Waiting 2 second(s), then retry. it's certainly will be better if it can auto scan whole com port (using the dummy midstate&data), support multi-boards with one miner instance, and long pool... maybe i'm tooooo greed.  good work! |
|
|
|
If someone wants to test the miner I'm currently working on, I prepared a litte prerelease for testing purposes. I'm using it to mine since about 12 hours now. PM me and I send you a copy (I don't currently have any hosting ready where I could put the file). The miner is written in java and should not be affected to much by a bad network connection. Long polling is not yet supported but it's the next thing on my list. I probably release the miner as open source when it's ready. Feedback is highly welcome . Why not host it on Github? Hm not sure if that works. Github is free for open source only, and I'm not ready yet to fully release it. email me: ngzhang1983@msn.com |
|
|
|
I expect all new products to have problems
and brought icarus to test fpga mining and the product
and 1 X 380 mh/s miner locking up is not a problem at all - so take your time to fix it
in next 6 months I want to get rid of my all GPU's based miners
and buy about 200 fpga based miners
it's certainly a problem. and present working is around the miner software. |
|
|
|
For what it's worth it's been my experience that BTCGuild has been the most stable with the least number of rejects of many pools I've tried (by a wide margin too such that it's even worth the fee). You may want to test pointing your hashing there and see if it works better.
oh, that pool is very unstable here. you know i'm in the Great Fire Wall. now i'm using ABCpool.co |
|
|
|
"the "upstream result: False" means stale, or just a wrong data.
miner stuck is a known issue, by my first plan, i don't want to do any fix on this miner, because i want to change to another common use miner software.
but looks like this progress needs some time.
"
Thanks for the update
since the miner stuck is a known issue -- there is no point in me changing pc or trying another mining pool
i will wait till you have a fix
regards
Luke
by my plan, miner software may change in this month. before that, a watchdog timer may add to present miner to solve this problem as a temporary solution. a experience is , if your pool is stable, the miner stuck may rarely happens.  |
|
|
|
let's discuss about the pool selection. in brief, if you have a large ping, please use the queue version of the miner software, but it will cause a higher stale rate. about 1-2%. but the FPGA could run at a full speed. but if your connection is unstable, it has already been found that both miner software sometimes get stuck. the both simple and queue miner will not continue or fix. we will change to a more common use miner, like CGminer or some other stuff who want to support icarus. there are already some people working on this. I'm sure it hasn't yet. My question was more a what if scenario aimed at understanding the dependence between the FPGAs. If one were to be damaged/abused how would the other one be affected. If one gets sick/dead does that render the other also inoperable? I'm not saying anything is wrong but it's good to understand how they relate to each other. From looking at the code it seems like the first dead would knock out the second, but not the other way around; unless I'm wrong about how the second communicates via the first. hmmmm, the FPGA simply act as a wire. pass the host data to the next one, and store-and-forward data to the host. I have changed to queue miner and now get 374.25 +/- 5.93 MHash/s I also get "upstream result: False" about every day and the mining stops --- I throught it may be my pc -- so I am in process of setting up a new pc to run software/icarus I will run some traceroutes and ping test and post results and respond to ecki the "upstream result: False" means stale, or just a wrong data. miner stuck is a known issue, by my first plan, i don't want to do any fix on this miner, because i want to change to another common use miner software. but looks like this progress needs some time. 我想请问一下张博士，这个用人民币买多少钱一个？本人住的离北航不远，运费可以忽略不计的，或者自己去取也行啊？
没有现货哦，目前订货状态，小批量大约3周。价格是3650￥。 |
|
|
|
let's discuss about the pool selection. in brief, if you have a large ping, please use the queue version of the miner software, but it will cause a higher stale rate. about 1-2%. but the FPGA could run at a full speed. but if your connection is unstable, it has already been found that both miner software sometimes get stuck. the both simple and queue miner will not continue or fix. we will change to a more common use miner, like CGminer or some other stuff who want to support icarus. there are already some people working on this. I'm sure it hasn't yet. My question was more a what if scenario aimed at understanding the dependence between the FPGAs. If one were to be damaged/abused how would the other one be affected. If one gets sick/dead does that render the other also inoperable? I'm not saying anything is wrong but it's good to understand how they relate to each other. From looking at the code it seems like the first dead would knock out the second, but not the other way around; unless I'm wrong about how the second communicates via the first. hmmmm, the FPGA simply act as a wire. pass the host data to the next one, and store-and-forward data to the host. |
|
|
|
this event may only happen when the FPGA is broken. and NEVER happened until now. Just to clarify before someone panics, I'm sure ngzhang meant to say that "it has NEVER happened yet" or hasn't happened yet. Grammar Syntax Nazi on the attack  lol OK。 it has NEVER happened yet  |
|
|
|
Hi there, I have some questions: -In the first post, I can see this: "$: 569 (1) / 469$ (multiple of 30)" so 1 board is 569$ and 30 boards is 469$ each, is that correct? If 30 boards is 469$ each, I might be interested in buying 30 Icarus boards. -Also, to use them, you only need the boards and a PC where you connect the boards with USB. So, in theory, the more there is USB ports, the more you can plug into that PC, correct? -Does the PC have some requirements on their specs? If I use a basic Sempron 130 with 1 Gb of RAM, is it going to be ok? I also suppose that using Linux on that PC is ok? -You ship to Canada? What's the shipping cost? -Let's say that in theory, I have a motherboard with 8 USB ports and 4 PCI-Express slots. So, always in theory, I could plug 8 FGPA board and 4 GPU in that motherboard and they could all mine together, correct? Thanks for your answers. This project seems to have potential yes, if your amount is larger than 30, the unit price is 469$, if you do not need the adapter (recommend for bulk orders), the unit price is 464$. save you 150$ to get a good power. there is nearly no requirements for the PC. even somebody is working on put the miner into an ARM based platform. a PC can run windowsXP or linux is ok. about the shipment cost, if using EMS, a 15KG package cost is around 300$. the USB port can expand with HUBs. so 100+ FPGA boards may operate on one PC. Hi!
I´m from Brazil and I would like to buy the FPGA to mine. Can you send to Brazil?
Thank you!
certainly , some Brazilian is already my customers. [quote author=ngzhang link=topic=51371.msg727871#msg727871 date=1328204144]
present configuration is the FPGA will stop working when it find a valid nonce. but the other FPGA in chain will continue working (because it didn't know what is happened on the other FPGA).
this idea is to keep a simple event. so software miner should push a work to FPGA immediately when received a valid nonce.
Does this behaviour also mean that if the second FPGA goes dead/locks up the first one will continue working? I'd assume if the first one goes dead it prevents comm to the 2nd one but I'm curious about independence when the first is still reachable but the second doesn't respond any more? i designed the logic inside the FPGA as a robust way. this event may only happen when the FPGA is broken. and NEVER happened until now. |
|
|
|
Another question about the communication specs: How do the boards behave after they found a solution? Do they keep working on the current work till they get new work, possibly resulting in 3 or more solutions per work unit?
present configuration is the FPGA will stop working when it find a valid nonce. but the other FPGA in chain will continue working (because it didn't know what is happened on the other FPGA). this idea is to keep a simple event. so software miner should push a work to FPGA immediately when received a valid nonce. ADD: about the detection. there is a simple way to impalement, with out any RTL change. just push a 512bits dummy work package to the COM port, fot example: ['data'] = "0000000120c8222d0497a7ab44a1a2c7bf39de941c9970b1dc7cdc400000079700000000e88aabe1f353238c668d8a4df9318e614c10c474f8cdf8bc5f6397b946c33d7c4e7242c31a098ea500000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"
['midstate'] = "33c5bf5751ec7f7e056443b5aee3800331432c83f404d9de38b94ecbf907b92d"
the boards will return "063c5e01" in a short time. Hehe I found this in our miner source, too. Helped me a lot to get the communication working . About the stop-searching-after-a-nonce-is-found thing, is there some specific reason for this behaviour or could this be changed? I think it would simplify miner developement if it kept searching, because currently a new getwork request has to be made after a nonce is found. Laggy internet connections make the FPGAs idle more and lead to lower hash rates (I think that's why my boards currently only make about 350 mhash each). If the FPGAs kept searching, a simple getwork-thread could feed the FPGAs new work every about <11 seconds, minimizing the negative effects of a bad connection. I think for now I'm going to implement some queueing mechanism as a workaround (couldn't flash a different bitstream anyways because I don't yet have a platform cable). i know what you mean. and i just solve this problem by a work queue function. my suggest is DO NOT CHANGE THE BITSTEAM, because a near 200M speed bitsteam is very hard to implement. or you can try to synthesize the code. |
|
|
|
Another question about the communication specs: How do the boards behave after they found a solution? Do they keep working on the current work till they get new work, possibly resulting in 3 or more solutions per work unit?
present configuration is the FPGA will stop working when it find a valid nonce. but the other FPGA in chain will continue working (because it didn't know what is happened on the other FPGA). this idea is to keep a simple event. so software miner should push a work to FPGA immediately when received a valid nonce. ADD: about the detection. there is a simple way to impalement, with out any RTL change. just push a 512bits dummy work package to the COM port, fot example: ['data'] = "0000000120c8222d0497a7ab44a1a2c7bf39de941c9970b1dc7cdc400000079700000000e88aabe1f353238c668d8a4df9318e614c10c474f8cdf8bc5f6397b946c33d7c4e7242c31a098ea500000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000"
['midstate'] = "33c5bf5751ec7f7e056443b5aee3800331432c83f404d9de38b94ecbf907b92d"
the boards will return "063c5e01" in a short time. |
|
|
|
hi, guys. the holiday is finally over. i'm going to have some meeting with my supplier and factory, and place some order for the 3rd batch. it's sure there will be some BOM changes to increase power efficiency, enhanced cooling, and so on. so later 2-3 days i will very busy. PM and email reply will much slower. please forgive me. confirm an accurate manufacture plan is the most important thing to do now. regards everyone. I thought the Chinese New Year holiday is 15 days long ?!?! Wikipedia seems to say so: http://en.wikipedia.org/wiki/Chinese_new_yearSo, if day 1 was Jan. 23rd, day 9 is Jan 31st, day 10 is Feb 1st and day 15 is Feb. 6th <confused> yeah, 15 days long "in the country". or even 1 month long. but in city, about 7-10 days long. |
|
|
|
hi, guys. the holiday is finally over. i'm going to have some meeting with my supplier and factory, and place some order for the 3rd batch. it's sure there will be some BOM changes to increase power efficiency, enhanced cooling, and so on. so later 2-3 days i will very busy. PM and email reply will much slower. please forgive me. confirm an accurate manufacture plan is the most important thing to do now. regards everyone. |
|
|
|
2 weeks after that. ADD: sorry guys. i just found a serious mistake in the code. it result in unstable. i will fix this issue in 1 week. Hi, I was trying to look at your PDF schematic, but Adobe reader says it's damaged or incomplete. Can you please double-check that? Thanks! it's ok here, how about change to another version of pdf reader? I can assure you, my Adobe Acrobat 10.1.2 is fine - and I tried this on multiple computers. When downloaded from github, the file Icarus_V1.pdf has a length of only 25474 bytes, not enough for a schematic. Can you attach it to a PM? Is that possible? Or upload it somewhere else? it's: 1115.404 kb size. or give me an email, and i will attach it for you. |
|
|
|
But by then, it's too late (and the FPGA destroyed), right?
should be not. if only the heatsink is still on the chip, the FPGA is hard to burnout by a fan fail. a FPGA only generate about 6~7W heat, much less than a GPU. but it will output error data at first. I'm at a loss as to why option 6 needs to be requested for these FPGA's (Yeah this is the 2nd one to be mentioned here in the cgminer thread and also the 2nd time the question had to be asked) Do all the companies who make these things believe that their device will never have heat problems? Fans stop, rooms get hot, some countries even have summer every year  If it works fine for 24 hours straight without causing any damage when you put it in an oven at 50 degrees Celsius without a fan running on the FPGA, then OK yep knowing the temp may not be necessary Otherwise ... temp monitoring is necessary. (Fan rate would be good too but not mandatory: temp will go up if the fan dies anyway) FPGA mining is not a heat concentrated project. engineers rarely pay attention to overheating protection on these stuff. at least that's my case. spartan-6 FPGAs haven't a built-in thermal sensor. so a monitor of temperature needs additional hardware, and logic in the FPGA. may i put a "heat switch" on board, and simply reset the FPGA when they reached a TEMP protect point? so the software will notice the FPGAs stopped and tigger some exception handling code? |
|
|
|
2 weeks after that. ADD: sorry guys. i just found a serious mistake in the code. it result in unstable. i will fix this issue in 1 week. Will the batch 3 boards run at a higher clockrate? hard to say now, but possible -- if the FPGAs maintain a good quality as first and second batch's. but a certain frequency only can be decided after the manufacture.  |
|
|
|
2 weeks after that. ADD: sorry guys. i just found a serious mistake in the code. it result in unstable. i will fix this issue in 1 week. Hi, I was trying to look at your PDF schematic, but Adobe reader says it's damaged or incomplete. Can you please double-check that? Thanks! it's ok here, how about change to another version of pdf reader? |
|
|
|
2 weeks after that. ADD: sorry guys. i just found a serious mistake in the code. it result in unstable. i will fix this issue in 1 week. |
|
|
|
unfortunately , i haven't any boards left in my hand. it looks like an sample is needed for the software development. and now china is in a huge new year holiday, every factory closed for half month.... until Feb.1
|
|
|
|
|
Show Posts
