3. What freq are you running at?
275/0815 target, last night's test I ran five that way, then the one I dropped to 268/0815.
Did you try 275/0800 before 275/0815? The datasheet states 2 voltages for that freq, 0800 and 0850. You should try 0800 first and increment if you get LOTS of HW errors or a very low hash-rate. For freq 275, you should have hit at least 550 Gh/s(avg) in the hour IF your HW % is low and no x's showing. EDIT: Saying that, the 538 you are getting with no HW errors is not bad either but I should expect your rig to give at least 550. PS. I think you'll have to start one machine at a time .... also, I'll address the other bits as and when ... |
|
|
|
I am using the 1024 firmware, the only change on top of that is adding the new frequencies into cgminer.lua. All six units stable again at the lower frequencies with no voltage setting.
Trying again on one unit, this time with ckolivas's S3 cgminer 4.6.1 build, also deleting --queue and adding --lowmem. I can't think of anything else to try. The S3's are in a ventilated space, so the ambient temperature over the three hour period is constant. Why would I get great results for 1+ hours, but poor results over 3 hours? [/quote] Possibly easier to simply post a shot of your web UI, but I'll ask just in case: 1. What temps do you have on that rig? 2. What is the HW % 3. What freq are you running at? 4. If you've recently started the rig, could you post the cgminer startup string (usually logged in system log ...?)? 5. Finally, could you also post the freq setting line that you are running from the cgminer.lua file? |
|
|
|
Some works could be copy and paste, but we will be paying more attention to details. Each time you catch something, please let us know!
OK since you asked, here's another one. The work input timing table in the new BM1384 datasheet is that of the BM1382 (copied straight from the older datasheet and clearly incompatible with the updated BM1384 power performance table!); Care to update it or remove the values completely as they are misleading?  |
|
|
|
I continue to find this extremely frustrating. I am running 6 S3+ units, each supplied by a 750-800W power supply with a single 12V rail and all four PCI-E connectors connected. I tried the 275/0815 settings, and exactly the same thing happened as the last time. Hour 1: fantastic, all units over 500 GH/s, holy crap why did I not do this earlier. Hour 2: OK, but hashrates down both as reported by units and at the pool. Hour 3: terrible, all hashrates reported by units and by pool way below stock results. So I have yet again reverted everything to 225/231/243/237/225/237 with voltage left blank.
I do not understand the mechanism here. If it is heat, why does it take 2 hours to show up? With the OC settings, all chips show up as "o" and working. But the hashrate results speak for themselves. But why the very prominent jump in hashrate for the first hour, but then utter crap out in hour 3? Can anybody explain this?
Just a few pointers that may help: 1. The voltage setting from the datasheet for the freq of 275 is both 0800 and 0850, so you can try anything within / around that range. 2. Hash rate falling in a few hours is NOT the "end of the day". Overall hash-rate is what matters in the long run (I usually let it run for 12 - 24hrs). If you are not getting X's on chips when the hash-rate is falling, I'd let it run as long as this did NOT coincide with a sustained increase in HW errors. 3. Do not be spooked by a fairly high HW error % at the start, and here I mean if the rate is less than or around 0.01 in the first few minutes to an hour, let it run. S3 variants are the same but handle differently, so you may have to try different voltage settings (even freq settings). For example, the 262.5 freq does not ship from bitmain, but it turns out to be a sweet spot for most S3 variants! |
|
|
|
0.1 BTC for Mr. nitrox1 0.05 BTC for Mr. pekatete assuming both are male  Thank you both very much! Thank you, much appreciated! |
|
|
|
OK having problems with TFTP server part.
That is all you need to sort out now and you are home and dry! I gave you a link to setting up a tftp server; go through it again and ensure you have (to the last letter) done all the steps, including but not limited to completely disconnectiong from the network and ONLY connecting the board to you PC / laptop ethernet. Do not try to cut corners as networking can be finicky at the very best. I don't believe it!!!! number 5 is really alive. It was windows firewall!!!!!! It was you mentioning, to re read your post! Well well .... who'd have thought? Well done and now you know why networking can be finicky at the best of times! |
|
|
|
OK having problems with TFTP server part.
That is all you need to sort out now and you are home and dry! I gave you a link to setting up a tftp server; go through it again and ensure you have (to the last letter) done all the steps, including but not limited to completely disconnectiong from the network and ONLY connecting the board to you PC / laptop ethernet. Do not try to cut corners as networking can be finicky at the very best. |
|
|
|
|
Easy-Link>
That is the uboot prompt, so simply type (after saving the antMiner_S320141013.bin file in the tftp server root dir as directed by bitsolutions):
Easy-Link>tftpboot 0x80000000 antMiner_S320141013.bin
Easy-Link>erase 0x9f020000 +0x7c0000
Easy-Link>cp.b 0x80000000 0x9f020000 0x7c0000
Easy-Link>bootm 0x9f020000
|
|
|
|
|
^^^^^ Top man!
You must b laughing at us for wasting all this time!
|
|
|
|
|
From your output, you see this line:
mtdparts=ar7240-nor0:128k(u-boot),1024k(kernel),6912(rootfs),64k(config),64k(ART)
When you call erase, you want to provide one of these parts of the mtd, and that is supposed to be the root_fs, so I am thinking
erase rootfs
will do the trick, else we need to find the tags for the parts. NOTE that this method would be in lieu of the tftp flashing method, i.e that will erase the memory data that the system is booting THUS force the system to effectively do a reset and call on the NVRAM data to load.
|
|
|
|
|
Thanks for the output, I'll browse through and see if I can spot a light at the end of the tunnell.
By the way, I meant the command altogether, i.e:
run mtd -r erase rootfs_data
|
|
|
|
Clearly labelled BM1384, so not for the S3 which has a BM1382 (as far as I know)! Oops, didn't catch that, but did see that 275 was at optimal 14 delay so it's coincidence then. Do the other delay settings match up to the suggested speed also? You are right about freq 275 having an optimal 14ms delay and for the life of me, I do not know why I had mine set at 15! And by the way, that BM1384 datasheet still has most data relating to the BM1382 (including that work input timing table). I think the only thing they've changed thus far is the Power performance table! If I recall correctly, the S3 does not ship with these freqs and I got them off a thread on this forum .... so that must have been wrong, or even more likely, I was tinkering around (as I do) and forgot to set it back! |
|
|
|
Yes, I did , won't except commands, run mtd, mtd, or erase rootfs_data
How do they fail? Is it verbose and if so, could you paste here? Also, run a printenv command and report back. |
|
|
|
Clearly labelled BM1384, so not for the S3 which has a BM1382 (as far as I know)! |
|
|
|
You are getting somewhere then ....
What IP did you set for your PC (tftp server) and the control board? These are supposed to be the same and as far as I can recall, you can NOT be connected to the wider network (at least from what I recall, but I could be wrong on that).
Them ALLLLLLL! I get no response from 1.250 which the ping said was alive. TFTP2.exe responds to 1.100 and 1.1, when I input to the S3 TFTPboot. But it's looking for an img file Know how to turn a .bin into a .img? Edit: .1.100 was it's pre brick IP address It is not a matter of turning a bin into an img file as the original upload takes the bin file. It may be a matter of simply changing the extension (or indeed telling the tftp server to look for a bin rather than img ... don't ask me how) Din you try and type in the run mtd .... command? |
|
|
|
|
You are getting somewhere then ....
What IP did you set for your PC (tftp server) and the control board? These are supposed to be the same and as far as I can recall, you can NOT be connected to the wider network (at least from what I recall, but I could be wrong on that).
|
|
|
|
Eagle eye .... that is dated today! Lets have a good read then. EDIT: Looks like a copy paste jobby ..... still has references to BM1382 ! So, which is which? Bitmain are becoming a bit lax in more than one way .... this market dominance seems to be getting to their heads; but yeah, this thing is a fair bit more efficient than the BM1382, hopefully they'll have at least one unit priced to fit our smaller wallets besides the much vaunted S5!  EDIT2: Also, the work input timings in the BM1384 datasheet have NOT been updated from those of the BM1382 .... crickey bitmain!?! |
|
|
|
From your log, the ethernet seems to be up, so yes, you should be able to get a network connection. All you are left with is having the TFTP server up and flashing your image. It is a simple thing ..... here's a link: http://ftp://priede.bf.lu.lv/pub/OS/ruuteri/Lynksys/WRT54G/tftp.htmBut there are lots of articles on the web about this too, now what you are left with is setting up the TFTP server and flashing. Edit: does this help: Easy-Link> ping 192.168.1.250 eth1 link down Using eth0 device host 192.168.1.250 is alive Number 5 is alive edit: sorry link didn't work, but you wouldn't happen to be a polish biologist would you? Now we know you have a network connection, what is left is setting up the TFTP server, placing your firmware file in its public directory and flashing it. Here's another link on how to flash using a TFTP server: http://wiki.openwrt.org/doc/howto/generic.flashing.tftpEDIT: PS> Since you will not be flashing onto virgin hardware, you'll need to keep the serial onnected and interupting the boot process. |
|
|
|
Is there a way to go through the ethernet from the connection I can get? Is there a ping test I can do through the ethernet? it there a way to push through the serial connection I have going on? "reset" reset CPU will that help anything.
From your log, the ethernet seems to be up, so yes, you should be able to get a network connection. All you are left with is having the TFTP server up and flashing your image. It is a simple thing ..... here's a link: http://ftp://priede.bf.lu.lv/pub/OS/ruuteri/Lynksys/WRT54G/tftp.htmBut there are lots of articles on the web about this too, now what you are left with is setting up the TFTP server and flashing. |
|
|
|
Please please please, I have no idea what your talking about. I will use google.
But can I please have a noob version, I not only think it will help me, but a few others too.
Honestly, I am trying to help you here and neither am I an expert at this. I did, though, have an instance a long while ago where I wanted to hack the router that my ISP had locked and, via google, got acquainted with this openwrt hacking stuff. So you'll have to bear with me as much as I am trying to recall the process; it can be done though, no doubt! The only difference with the S3 board is it does not seem to have the otherwise "standard" commands that I encountered on my jaunt .... |
|
|
|
|
Show Posts
