Ok some running dip switch settings. These are now on support page as well.
Your pic says more than my 1000 words, yohan.  Thanks! The Icarus setting is exactly what I am using to mine with unmodified cgminer 2.4.3. For programming, I just set SW1-3 off and than back to on - works reliably. I found another mini USB hub and attached 4 more boards. Looking at the cgminer output after a hour or so: --------------------------------------------------------------------------------
(5s):10926.6 (avg):11799.3 Mh/s | Q:1397 A:1364 R:0 HW:0 E:98% U:65.8/m
TQ: 56 ST: 58 SS: 0 DW: 256 NB: 3 LW: 4553 GF: 3 RF: 0
Connected to http://eu.ozco.in:8332 with LP as user zeta-mining.1
Block: 000008eb5cae1b4d3a1d0ebf00a7342e... Started: [17:49:15]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.8/366.0Mh/s | A:54 R:0 HW:0 U: 2.61/m
ICA 1: | 379.9/370.3Mh/s | A:13 R:0 HW:0 U: 0.63/m
ICA 2: | 380.0/365.6Mh/s | A:51 R:0 HW:0 U: 2.46/m
ICA 3: | 379.9/374.7Mh/s | A:21 R:0 HW:0 U: 1.01/m
ICA 4: | 379.8/372.6Mh/s | A:56 R:0 HW:0 U: 2.70/m
ICA 5: | 379.9/372.1Mh/s | A:58 R:0 HW:0 U: 2.80/m
ICA 6: | 379.5/370.3Mh/s | A: 0 R:0 HW:0 U: 0.00/m
ICA 7: | 379.3/369.5Mh/s | A: 0 R:0 HW:0 U: 0.00/m
ICA 8: | 379.9/369.4Mh/s | A:53 R:0 HW:0 U: 2.56/m
ICA 9: | 379.9/369.3Mh/s | A:46 R:0 HW:0 U: 2.22/m
ICA 10: | 379.8/369.8Mh/s | A:45 R:0 HW:0 U: 2.17/m
ICA 11: | 379.9/370.1Mh/s | A:27 R:0 HW:0 U: 1.30/m
ICA 12: | 379.8/368.1Mh/s | A:60 R:0 HW:0 U: 2.90/m
ICA 13: | 379.8/369.3Mh/s | A:53 R:0 HW:0 U: 2.56/m
ICA 14: | 379.9/368.7Mh/s | A:49 R:0 HW:0 U: 2.37/m
ICA 15: | 379.8/368.8Mh/s | A:46 R:0 HW:0 U: 2.22/m
ICA 16: | 379.7/371.6Mh/s | A:57 R:0 HW:0 U: 2.75/m
ICA 17: | 379.8/372.4Mh/s | A:61 R:0 HW:0 U: 2.94/m
ICA 18: | 379.9/368.8Mh/s | A:60 R:0 HW:0 U: 2.90/m
ICA 19: | 379.7/369.8Mh/s | A:73 R:0 HW:0 U: 3.52/m
ICA 20: | 379.9/368.8Mh/s | A:43 R:0 HW:0 U: 2.08/m
ICA 21: | 379.9/368.2Mh/s | A:43 R:0 HW:0 U: 2.08/m
ICA 22: | 379.8/372.7Mh/s | A:38 R:0 HW:0 U: 1.83/m
ICA 23: | 379.9/373.6Mh/s | A:55 R:0 HW:0 U: 2.66/m
ICA 24: | 379.8/368.0Mh/s | A:44 R:0 HW:0 U: 2.12/m
ICA 25: | 379.6/369.5Mh/s | A:55 R:0 HW:0 U: 2.66/m
ICA 26: | 379.9/368.9Mh/s | A:44 R:0 HW:0 U: 2.12/m
ICA 27: | 379.9/366.1Mh/s | A:48 R:0 HW:0 U: 2.32/m
ICA 28: | 379.7/365.0Mh/s | A:48 R:0 HW:0 U: 2.32/m
ICA 29: | 379.9/368.2Mh/s | A:63 R:0 HW:0 U: 3.04/m
ICA 30: | 379.8/372.0Mh/s | A: 1 R:0 HW:0 U: 0.05/m
ICA 31: | 379.7/372.0Mh/s | A: 0 R:0 HW:0 U: 0.00/m
--------------------------------------------------------------------------------
There are always some units that remain at a very low U, i.e. not generating valid shares. Seems to be the instability eberon was reporting. Looking forward for the real bitstream |
|
|
|
Are there different board versions with different switchs positions ?
in my card the switch positions are:
23
6(top) ##
1(botton) ##
54
could you confirm your config to avoid misunderstandings. Thank you.
Sorry if I caused confusion. I was not aware that the switch numbers are printed on the board. Now with a lens I saw them (my eyes, you know...) and in fact in my post the numbering is swapped for SW1 SW6. Will correct it there. Thanks for the heads up. |
|
|
|
|
Short update before I head to work.
I got 12 boards (with all USB hubs and PSUs I could grab) up and running over night with no hiccups. Pool reports 4.3 GHps average which matches half of what cgminer is reporting as all time rate.
One problem I observed is the USB cables. With my lot I got two types with 1.8 and 1.2m, with the long ones had problems to properly operate (both directly connected to my Laptop or over a passive USB hub). While some cause aborting communication, with others the ttyUSB ports are even not detected at all. So, if you observe glitches and see from your syslog that the tty ports were disconnected, just take the USB cable from your digital cam and give a try.
For those who also ordered lots of boards, here is how I set mine up (which without persistent SPI programing is PITA), for Linux:
1.) connect all to the PSU and USB cables
2.) set DIP switches as described for twin_test PROGRAMMING plus 115kBaud:
SW6 (array top): 1 off, 234 on (115kBaud)
SW1 (array bottom): 3 off, 124 on (programming mode)
SW2 + SW5 (FPGA 0+3): 1234 on
SW3 + SW4 (FPGA 1+2): 12 off, 34 on
3.) power on all boards
4.) for every board
a) connect it to host
b) program all FPGAs with 190M_V3.bit
c) disconnect from host
d) switch SW6-3 on (red controller LED starts blinking)
5.) connect boards to host one after another (first connect the hub and then the boards to the hub)
6.) run cgminer (default Icarus at 115kBaud) with all ttyUSB
7.) note which ones are the inactive FPGAs (usually those at ttyUSBx with (x/2 % 2 == 0))
8.) run cgminer with only active FPGAs (you might need to run several times until all are detected properly)
9.) mine
10.) hope nothing goes bad, otherwise: goto 1
HTH
Edit: fixed previously swapped SW1 and SW6
|
|
|
|
|
Short update (before I'm done for today): got three boards (serial# 126-128) programmed with the V3 bitstream (with eberon's howto) up and running. After around an hour the average hashrate reported by the pool is 1150 MHps, which is quite in line with 380 per board.
One important thing (lost track in the thread, might already been mentioned): do not run cgminer with automatic Icarus detection or with the script proposed by xiangfu to run all available FPGAs. Instead, do a dry run first to see which ttyUSB ports are assigned to the malfunction FPGAs (with Linux it depends on the order of how they are plugged into the hub) and then run cgminer with only the valid ttyUSB ports as parameters. Giving all ports to cgminer confuses some processing, i.e. the faulty ones get disabled but the scheduling is also messed up with the FPGAs idling most of the time.
Good night.
|
|
|
|
... currently not available at Amazon. Plus need to get it to Switzerland -> ~2 weeks delivery time  Best deal here would be to go to a local store and buy 8x7-port hubs for ~35$ each. Sad thing is, I prepared the up/down cables already and hoped to bring up all boards to life tomorrow without wasting money for the USB hubs - but thats life... |
|
|
|
Thanks rjk and spicioli, helped me to find the problem with the xc3sprog host build. Ok I am told we didn't do any patches for the xc3sprog so it is as the original.
Yet, you did U. Bonnes added support for the cm1 cable to the SVN repository two weeks ago and swapped two digits in the product-id entry: 0x8530 instead of 0x8350 In the cablelist.txt file in the VirtualBox image you fixed that typo, but did not update in the repository. Since I have no write access to the xc3sprog SVN repo and assume Mr. Bonnes is an Enterpoint fellow, you maybe want to forward him the required patch to fix the issue: Index: cablelist.txt
===================================================================
--- cablelist.txt (revision 679)
+++ cablelist.txt (working copy)
@@ -9,7 +9,7 @@
ftdi ftdi 1500000 0x0403:0x6010:
ft232h ftdi 1500000 0x0403:0x6014:
ft4232h ftdi 1500000 0x0403:0x6011:
-cm1 ftdi 1500000 0x0403:0x8530:
+cm1 ftdi 1500000 0x0403:0x8350:
bbv2 ftdi 1500000 0x0403:0x6010::1:0x00:0x10:0x00:0x0
bbv2_2 ftdi 1500000 0x0403:0x6010::2
dlp2232h ftdi 1500000 0x0403:0x6010:DLP-2232H:1:0x00:0x10:0x00:0x0
To the Linux folks: forget the VirtualBox fuss and just compile the xc3sprog sources from SVN with the above patch and program your board natively. Up/Down is not working yet. That will come after our first original bitstream. That will need another controller update.
Are the USB hubs you are using powered with a brick supply or bus powered? You might get this issue on un-powered hubs and it just one board is marginally more power hungary.
Ah, really? That might be the reason, since all tested hubs were passive. Isn't the FTDI powered by the main board power supply? If not, does this imply that powered USB hubs must be used if using more than 3 boards? Do send this stuff to the emial support.bitcoin at enterpoint.co.uk. Response won't be terribly fast as we are balancing getting on with the new stuff with supporting the temporary things.
Will do. But will also post a copy in this thread, since evidently the community is of great help. On a different point on CGminer we will probably put a second build for Windows up on the website shortly. It's specifically for the twin build. Basically the one that is currently up there is for the 50MHz build and we should have made that a little clearer. The twin build version is more or less the same as Icarus. I think there are a couple of minor switch settings changed but that's all.
As long as there are no functional differences to Icarus (i.e. if you could use baud-rate of 115.2k), I'd suggest to leave it as is and just take the Icarus cgminer. Right now I can use it as is with the one DIP switch correctly set and it does not make sense for your SW team to follow the Icarus development all the time when the only difference is the baud-rate. When we bring in our own original build bitstream I expect to have quite a lot of changes including a new step of CGminer and new revision of the Controller. The up/down function may, or not, make the first of these versions but if it doesn't it should not be far behind. When we have that it will take a lot of the historical problems of large numbers of USB trying to run on one machine and will start to look much more like our planned long term structure of network nodes. That's a key in to what is coming in Cairnsmore2 where we will extend that idea somewhat more.
I understand that, alas that puts me personally in an odd situation: to have the boards running now I need to buy a dozen USB hubs - and dump them only two weeks later when the up/down functionality is supported Anyhow, your boards are great - you folks know what you are doing and how to satisfy your customers. Thanks, zefir |
|
|
|
Yohan, got my first batch of Cairnsmores delivered and would like to ask you for clarification on: 1) Patches for xc3sprog I can't access the boards from VirtualBox. Since I am using Ubuntu as host system anyhow and xc3sprog is open source, I built the tools for my host system. With all prerequisites met claims that it can not find devices using libftdi. Could you please check whether you had to patch the source code for the binaries you delivered with your VirtualBox image - and if so please publish the patches (since it is GPLv2 anyway)? 2) Up/Down cable support I have a 2x5 IDC ribbon cable at hand and connected two boards over the up/down interface with one board attached via USB to the host. It does not seem to work as I expected, i.e. neither I see 8 ttyUSB ports nor I get a higher hashing rate with the second board attached via up/down cable. Could you please confirm whether the up/down functionality is currently supported at all? 3) FTDI disconnects One of the four boards I am testing has obvious problems with the FTDI chip. It causes the PC to become non responsive or freezes it completely until I plug the USB cable to the related unit. Tried with several USB hubs and swapped the cables, but it is always the one unit that causes problems. This is the syslog when things go bad: Jun 25 19:43:08 d620 kernel: [15947.382768] ftdi_sio 1-4.1:1.2: FTDI USB Serial Device converter detected
Jun 25 19:43:08 d620 kernel: [15947.382833] usb 1-4.1: Detected FT4232H
Jun 25 19:43:08 d620 kernel: [15947.382838] usb 1-4.1: Number of endpoints 2
Jun 25 19:43:08 d620 kernel: [15947.382843] usb 1-4.1: Endpoint 1 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.382849] usb 1-4.1: Endpoint 2 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.382854] usb 1-4.1: Setting MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.383210] usb 1-4.1: FTDI USB Serial Device converter now attached to ttyUSB2
Jun 25 19:43:08 d620 kernel: [15947.384871] ftdi_sio 1-4.1:1.3: FTDI USB Serial Device converter detected
Jun 25 19:43:08 d620 kernel: [15947.384942] usb 1-4.1: Detected FT4232H
Jun 25 19:43:08 d620 kernel: [15947.384947] usb 1-4.1: Number of endpoints 2
Jun 25 19:43:08 d620 kernel: [15947.384952] usb 1-4.1: Endpoint 1 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.384958] usb 1-4.1: Endpoint 2 MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.384963] usb 1-4.1: Setting MaxPacketSize 512
Jun 25 19:43:08 d620 kernel: [15947.385366] usb 1-4.1: FTDI USB Serial Device converter now attached to ttyUSB3
Jun 25 19:43:08 d620 kernel: [15947.460411] usb 1-4.2: new high speed USB device using ehci_hcd and address 101
Jun 25 19:43:08 d620 kernel: [15947.544437] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:08 d620 kernel: [15947.732438] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15947.908443] usb 1-4.2: new high speed USB device using ehci_hcd and address 102
Jun 25 19:43:09 d620 kernel: [15947.992441] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15948.180403] usb 1-4.2: device descriptor read/64, error -71
Jun 25 19:43:09 d620 kernel: [15948.356446] usb 1-4.2: new high speed USB device using ehci_hcd and address 103
Jun 25 19:43:10 d620 kernel: [15948.772066] usb 1-4.2: device not accepting address 103, error -71
Jun 25 19:43:10 d620 kernel: [15948.844451] usb 1-4.2: new high speed USB device using ehci_hcd and address 104
Jun 25 19:43:10 d620 kernel: [15949.260132] usb 1-4.2: device not accepting address 104, error -71
Jun 25 19:43:10 d620 kernel: [15949.260486] hub 1-4:1.0: unable to enumerate USB device on port 2
Are you aware of such problems and is there anything I can do SW wise to bypass it (aside of the udev rules I am already using)? I considered sending this support request to the support email address you gave, but think that it might be interesting for other users and/or it could already be solved by someone. Thanks. |
|
|
|
|
Update: dividends for week 25.2012 paid & Cairnsmore1 Quad shipped
Dear investors,
dividend payments for the past week were processed. With a return of 4.2456 mBTC/bond and today's 5-day average price of 235 mBTC this week's yield is 1.8%.
The 50 Cairnsmore1 Quads I ordered for expansion has been shipped last week and will be at my company early next week. Currently, a modified Icarus bitstream can be used to operate the Quads in dual-FPGA mode at 360+ MHps per board, while a dedicated bitstream (being currently worked on by Enterpoint and community developers) should push it more to the 800 MHps range. At the final performance level and the resulting efficiency gain along with the recent increase of BTC/fiat exchange rates I will be able to offer new bonds worth 30 GHps at a very competitive price to the public.
Those who are not convinced that FPGA mining becomes obsolete by October and also do not believe in the world's Armageddon by the end of 2012: stay tuned for a promising investment offer.
Have a nice week,
Zefir
|
|
|
|
|
Update: dividends for week 24.2012 paid & clarification on ASIC upgrade
Dear investors,
with yesterday's payment of dividends for week 23.2012 we had a row of relatively constant weekly returns of around 1.5%. I wish I could promise that this will continue and allow us to recover our investments within less then a year. But while I hope for the best, there's no room for promises. The decline in mining bond prices that started last week is continuing and brought back some of them for almost 40%. One component of this decline is clearly the rise in BTC-to-fiat exchange rate, since a given amount of Bitcoins buys you more mining rig and consequently the price per MH/s should be less. While this almost always is only half the truth (coins collected from investors are put in pre-orders or converted to fiat to prepare rig payments), there is an evidence that market is currently behaving irrational: the top five mining bonds (which I do not count Zeta in) are issued by highly respected and trustworthy community members - but the market price for their bonds normalized to 1MH/s differs significantly. Ideally all face the same risk (assuming all are evenly trustworthy) and offer identical returns - still some are 60% more expensive than others. Heads up for more glitches to come until mining bonds consolidate in the long run.
The other large disruption we had the past week was BFL's announcement of their 'soon to come' ASIC based mining rig. The related forum threads are long and entertaining enough for an enjoying weekend reading - no need to add more to the ongoing speculation. But I've been contacted by investors who are asking for some free upgrade to ASIC based mining bonds that other issuers are offering. That gimmick would imply that when the issuer upgrades his existing rig to ASICs, the issued 1MH/s bonds become 20MH/s ones... As you'd already guessed by my choice of the word for this 'instrument', there will be no such free upgrade feature for ZETA-MINING.
The first and practical reason for that is that most of my mining rig is not from BFL - my inventory is 5 BFLS and 50 Cairnsmore1 Quads. The Quads are, as soon as Enterpoint provides fully operational bitstream, the most efficient mining devices around (maybe the MiniRigs are comparable). Consequently, all today's mining rig needs to be wiped out first before I need to pull the plug due to negative mining ROI. Needless to say that I will upgrade to ASICs as soon as they are available to remain competitive, but until then lots of blocks are to be mined.
The other reason I see such upgrade program will fail is its inherent lack of transparency. How do I as a bond issuer prove or disprove that I already traded my BFLS for SC Singles? Fact is, bonds are traded per MH/s, not as MH/s generated by GPU or FPGA - the rig used to mine is completely irrelevant and therefore renders any upgrade or exchange program useless.
Now what does all this ASIC hype mean to you as an investor? It comes down to exactly the same as it does to me: will it allow me to get back my investment and earn some profit before the next generation mining rig pushes me out of the market? If you do not believe in that, you should bail out from any mining investment (bonds or mining equipment) right away. But think further: if the majority is scared off and stops investing in mining, the difficulty remains the same and helps ROI of existing miners. The self stabilization of difficulty to give miners enough incentive to mine worked so far and I personally think this was Satoshi's most ingenious idea.
Have a nice week,
Zefir
|
|
|
|
[...]
Oh my how I do tend to babble.
No, I don't feel you are babbling - you're just telling the obvious. Two things I'd like to comment: 1) Pirate's business and its impact on mining True, everyone who is willing to take the risk would be just stupid to not put his money into BTCS&T and instead invest in mining business. My own money is with Pirate while I am waiting to pay the mining rig I ordered and guess what - I earn 5 times more from BTCS&T payouts per week than I do with mining. Now while this is a great opportunity, we all know that there is a mathematical necessity that this will not work for too long. From the number of direct and indirect investments of lenders, PPT bonds and other pass-through businesses I'd assume that Pirate manages 250kBTC. Now 7% weekly means factor 33 per year - how long can this work before all existing coins are held by Pirate? It is inevitable that the system either collapses if Pirate had dishonest intentions (which I do not believe), or he will adjust his rates to more realistic values. Still your argument is valid: if he came down to say 2% weekly, there's still no incentive to invest in mining for less than 1.5%  Time will tell... 2) Inner value of mining bonds Just stating mining bonds are generally overpriced and should consolidate at 0.2 per 1MH is shortsighted. You can't just take the current price of a BFLS and its hashing rate to calculate the supposed fair value. This would currently result in ~0.135 BTC per 1MH and since BFLS are price wise the current optimal choice this is the absolute minimum inner value. Add on top of that taxes (VAT), fees (shipping) and infrastructural investments (PSU, cooling) and you're approaching the 0.2 range. Now take into consideration that your rig is mining at 95% of its lifetime on average (service, downtime, network issues) but you are paying 100%, plus add the energy cost you as operator pay from your pockets, 0.2BTC per 1MH today would mean loss to the bond issuer. Based on my initial calculations (based on 5$/BTC), I'm able to guarantee mining for a bond issued at 0.27 for two years. With the recent rate increase I see the par line at 0.25 - not 0.2 if you do serious business. Competition is good, since it forces operators to head for the most energy efficient devices. But if someone is offering GPU based 1MH/s bonds for 0.2BTC, it should be obvious that this won't survive for too long. Cheers, zefir |
|
|
|
so, if Germany beats Portugal or vice versa? Now I'm confused  If Germany beats Portugal I am going to pay the bonus. I am supporting the weaker one, which I think is Portugal here (might be wrong, since I am really not interested in soccer generally). So bets are good for the extra 10% maybe. OTOH: Denmark just kicked Netherlands' ass some minutes ago! Favorites often fall, let's see |
|
|
|
Dear investors, during the last two weeks mining business has gotten more competitive. We saw many new miners entering the bond market, along with established ones flooding the market with newly issued bonds in anticipation of the MiniRigs to be delivered soon. As a result of this overcrowding, silently operating businesses (like I want Zeta-Mining to be) soon get lost from investor's radars: companies listed in the securities section of the Bitcoin forum disappear from the front page if they do not post news every day. Due to the fact that with continuous long-term operations like mining there are not always news to tell, people start to generate 'creative' news, like varying PPS or re-scheduling payout times. Those PR actions are established everywhere and it is completely legitimate to apply them here to stay in the news. But this is not the way Zeta-Mining will go. I expect my investors to know what they pay for and what to exactly expect in return - without the need for continuous publicity campaigns. While this will remain a no-frills investment, I'll take care to update you at least once a week to let you know that business is alive - if not more, the payment of dividends is at least something worth to report for those of you who are not looking at the provided Google Doc spreadsheet. That said, lurking in IRC I fooled around and made a statement that I need to post here officially to put my money where my mouth is: The dividend payment for week 23.2012 is scheduled for tomorrow with ~4.434 mBTC per coupon. At current market price of 0.2788 this yields a weekly ROI of 1.6%. I will add 10% on top of the payments in case Germany beats Portugal in today's European soccer championship match. Not that I am a soccer fan or believe Portugal is stronger. But since Switzerland is not participating, I support the weaker side - go Portugal go! Have a nice weekend, Zefir |
|
|
|
The baud-rate is not used anywhere. It's just a formality.
Regards,
BF Labs Inc.
Thanks for saving us from wasting more time on this |
|
|
|
After 900 accepted shares, my U seems to be a little higher, but I'm going to leave it for a while.
BTW, why does cgminer occasionally (after about 50K shares) stop sending work to the BFL box? It stays running and shows longpolls as they come in, but no shares...
Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs. Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused the device idling around two nights The communication protocol on the unit side is rock-solid. Probably it's the cgminer upgrade that has caused this. The firmware only affects hashing engine and how they work, and does not affect the MCU on board which handles communication protocol. Most likely this is due to cgminer change. Regards, BF Labs Inc. Hey, great you are around. I'll try with previous cgminer if this happened again. While you are here, could you give a hint whether changing the FTDI baudrate has any effect on the communication (and idle hashing) time as is discussed above? Just to save us from tapping around in the dark. Thanks. |
|
|
|
After 900 accepted shares, my U seems to be a little higher, but I'm going to leave it for a while.
BTW, why does cgminer occasionally (after about 50K shares) stop sending work to the BFL box? It stays running and shows longpolls as they come in, but no shares...
Since when do you observe this? One of my BFLS (running at 872) happened to just quit working two times this week. No indication that communication failed or any other log messages from cgminer. The only thing I noticed is the right LED being off, indicating that device is not hashing. Since restarting cgminer makes it work again, I assume it is only communication that hangs. Before I updated to cgminer-2.4.2 and played with the different firmwares, the BFLS worked for weeks non-stop. Would be a pity if the FW with the higher clock caused the device idling around two nights |
|
|
|
Hm, I guess we don't see the full picture. At Linux side the buadrate can be set with setserial (like kano said, it is not explicitly set by the bitforce driver): stty -F /dev/ttyUSBx <baudrate> and read it back with I can set all known rates from 75Bd to 3MBd while cgminer is working without any noticable effect. Either the Linux driver does not support setting or the chip is hardwired to operate at a defined speed. But it is obvious that it is not operating at 75Bd, since that would exceed cycle time. The FTDI chip used is FT232RL ( datasheet). |
|
|
|
I get 857 and some change mh/s with the 864 firmware.
But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS. That is the average over a day +. The only time the thing comes off of 857 is when the long poll hits from the pool. Are you really sure you flashed the 864 FW? 857 MH/s would otherwise perfectly match 872 MHz. If you're sure, what OS and miner SW are you using? |
|
|
|
One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit. Yes, I also wouldn't worry too much about tweaking this inefficiency out. If a non-throttling 816 unit throttles with 832 firmware (a 2% increase), then that same 816 unit would likely throttle if the 80ms idle time was eliminated. On the other hand, there's a number of us who are running 896 in cool environments are getting 883 MHash/sec without throttling. Until BFL releases even faster firmwares, we could benefit from this improvement. The pre-fetch and caching mechanisms has to be implemented by BFL. What can be tweaked SW wise is to reduce the polling time, but this might potentially save only some milliseconds per cycle. What I am more curious about is the unusually low baud rate used for communication. 9600 Bd was used two decades ago, if we could use today's common rates of 115.2 kBd, that would be a huge improvement potential. To you Windows folks: could you maybe check if it is possible to change the related COM port settings before you run EasyMiner to e.g. 38.4 kBd 8N1 and check whether they change during and after EasyMiner accessing the BFLS? Thanks. |
|
|
|
I get 857 and some change mh/s with the 864 firmware.
But not long term, or? The values averaged over the last 5s might fluctuate (I even see higher values than clock rate now and then), but if you let the device run for a day or so, the hash rate should settle to the values I gave - at least that's what I see with my Linux driven BFLS. |
|
|
|
I believe BFL addressed this question elsewhere. But basically when going through the full nonce range (2^32, of 4 billion hashes), a Single runs at its full speed of 832Mhps. It is able to do this in 5.16 seconds. After that it stops until the mining software give it another work unit. So the question is, how long does it take for the mining software (e.g. cgminer) to give it more work? Well, the miner needs to POLL the USB port to see when the Single is done, it needs to collect any difficulty-1 solutions found (typically 1), then it needs to send the next work. I believe the polling interval in cgminer is on the order of 100ms. The USB link to the Single seems to be only 9600 baud, which will add many more milliseconds to the sending of commands, collecting results, and feeding more work.
Let's assume the average delay between polls is 50ms (100ms polling interval means an average of 50ms delay); we'll assume the additional delay due to sending/receiving/processing commands is negligible. So the Single is running for 5.16 seconds at a speed of 832, then sitting 'idle' for 0.05 seconds. Another way of looking at this is that it takes (5.16+0.05) seconds to run through the entire nonce range. That would give it an effective speed of only 824Mhps, not 832.
This happens to be what cgminer reports for a full-bore 832-firmware Single (my 832-speed Singles are reported as 825 by cgminer). Perhaps my assumptions are a bit off, perhaps the polling interval is faster than 100ms ... maybe it is only 10ms. But then the overhead in transferring the serial commands becomes more significant and we're basically back to the same situation again.
You asked why EasyMiner reports a higher rate than cgminer. This is why. I think you already suspected as much. EasyMiner reports the raw rate only. That is, the rate at which a full 2^32 hash range is calculated at. It does NOT take into account the overhead of polling and command transfer over a longer period. cgminer does take this into account, which is why its reported rate will be lower.
It may be possible for BFL to tweak the firmware such that the next work could be queued in the device before it has completed its current work; that would essentially eliminate the polling delay and allow the device to operate at 100% efficiency. Currently that is not the case; we lose about 1% due to the polling and USB communication overhead.
Hi Epoch, I had similar estimates in a different thread and did some further digging to get a more solid understanding. Bottom line is, if the BFLS is not throttling, you will get some long term hash rate of (system clock - 14) MH/s, that is a device with 864MHz firmware will deliver 850MH/s at most. The loss is taken for the communication to/from device. Converting it down based on a nonce time of ~5.2s, the idle time is around 80ms per cycle. That matches the real numbers for cgminer operation, that are: - baudrate of 9600 => ~1ms (937.5 us exactly) to read/write a single character
- submitting work: write ">>>>>>>>[32 bytes midstate][last 12 bytes of block header]>>>>>>>>" => 56ms
- polling for shares: after work submission, first wait 4.5 seconds, then poll every 10ms by writing "ZFX" => 8ms average delay
- reading shares: read "NONCE-FOUND:1234ABCD,2468EFAB,1111BBBB" => (11 + #nonces * 9) ms => 18.7ms average
One could maybe implement some pre-fetching of work and caching of nonces functionality to add the potential 12MH/s - but at the same time maybe the FPGAs need this small idle time to cool down a little bit. |
|
|
|
|
Show Posts
