Is this an SSH one or firmware? I'm guessing ssh into the S4 and replace this file, but I'll let you tell me for sure. Thanks. Binary for installation via ssh only. I don't do firmware. And a damn fine job you did with this for the s4! Both units now humming along perfectly on EMC pool  Sent ya 0.1 btc remuneration  |
|
|
|
;d Thank you so much for the time you've invested to make the S4 more funtional, ckolivas. I'm going to send you a donation tomorrow morning.
I'd like to try ck's new version tomorrow, but I have no idea how to go about updating cgminer. Can anyone shed some light, or point me towards a guide?
Assuming your S4's IP address was say 192.168.1.99: ssh -l root 192.168.1.99 (or equivalent with putty)
wget http://ck.kolivas.org/apps/cgminer/antminer/s4/4.6.1-141018/cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
chmod +x cgminer
mv cgminer /usr/bin/cgminer
/etc/init.d/cgminer.sh restart
I think that might not keep across a power cycle though. Installed your new binary last night on the S4 I have at home and now works great on EMC pool Prior to the update was averaging 1.66ths there with swing from 1.4 up to ocassionally 1.94ths with worker dif wildly swinging between 1.2k to 1.86k. Now diff bangs around between 1.46k and 1.87k and on EMC it's averaging 1.95-2.0THs, swing is from 1.7ish up to occasionally 2.3THs. Damn fine work with the Voodoo that you do so well  Now to see if it works on my other s4 that is at work. Made a backup of the working s4 and will apply it to the other one. That one never gets over 25ghs on EMC so is currently pointed at CKpool where its works perfect. |
|
|
|
Did you see the video I posted? http://youtu.be/uiZPOZcI20oThis wasn't a burnt smell only. visible smoke billowing and this was after it had calmed down a bit. Not to lessen the severity of this issue but that is normal for power electronics. The volume released can be rather impressive. Once released the Majik Smoke (and smell) from popped caps and/or burnt circuit boards lingers for quite a while. The smell in the rack case will last days... Point is any actual fire is wholly contained within the psu case and miner case. Once the power is cut from circuits burning open/circuit breakers opening any actual fire ceases leaving only lingering memories. |
|
|
|
|
^^ I'd guess that they paid for their sponsorship earlier in the year like they did the Las Vegas show.
Wonder if they will show up?
And on the BITMAIN s4's - In BITMAIN's response to the matter, aside from their perfect handling of the PSU issue, ya gotta love their answer to concerns on any possible fire: "at high temperatures may result in some smoke from the PCB and thermal pad, it will not start a fire. All internal components of the PSU meet the requirements of the UL94-V0 flame retardancy standard, which certifies that any ignition will self-extinguish within a maximum of 10 seconds."
Very safe bet that AMT cannot make any such assurances.
|
|
|
|
|
and don't need to format... The image is just that - an image of the entire logical structure of the storage media formatting and all. When you burn the image to a device that's all you need to do. It's ready to go.
|
|
|
|
Well, bitmain is a very honest company and they give ssh access.
Ja. that is why Opeium and I were baffled about the weird connections popping up when looking at the network realtime graphs. It was Opie that finally recognized one of the addresses as a ntp time server. Weird thing is it didn't show up on the rt graphs on my s1's. then again I recall Bitmain was having troubles with ntp back then and may have disabled the function. When I recently updated the s1 software it now showed traffic when ntp was on.. |
|
|
|
|
Smething that traffic may have been is communications to ntp.org time servers. When I got my first Ant s3's I saw a LOT of weird ip addresses being talked to - including one owned by Bitmain.
Turns out they were time servers being polled every 5 min.
I disabled using a time server in the Ant configs and traffic stopped.
|
|
|
|
|
ja, it is. And is why we need to be able have full root access to these miners. If they are hard coded to ping an address it would be in the configs for the CPU used. In the Canadian case it was only kept in temp storage as the cable ISP's routers took care of re-injecting when needed.
|
|
|
|
The way it works is the miner is a worker in the pool handling some of the processing duty to mine a block in the pool. The pool in effect would be like a giant worker directly pointed at the bitcoin network decrypting blocks. Each worker within that pool is identified and gets a share of the solved block. I think that is more or less the simplest explanation I can come up with.
That is the intended overall effect, OK; but I was asking about a technical implementation detail, to see whether a manufacturer can steal hashpower from a pool member. AFAIK, the mining software periodically gathers a batch of unprocessed transactions into a candidate block, that includes a coinbase transaction directing the eventual reward to the pool's input address. Then the mining software sets one or more machines to work on that candidate block. The work consists in making a series of attempts. In each attempt, the nonce field in the block header is replaced by a different value, and the SHA-squared hash of the header is recomputed. If the hash value is below the network difficulty threshold, the attempt was successful and the block is broadcast to the bitcoin network, which credits the reward to the pool. Otherwise, if the hash is below the pool's difficulty threshold, the block and the hash value are sent to the pool, as proof of effort. Otherwise the attempt has no effect. Correct so far? Now consider whether this attack by malicious mining software could be viable: in one attempt out of every six (or in one candidate block out of every six) the software replaces the coinbase output address by the thief's address. As before, if an attempt yields a hash below the network threshold, the block is broadcast to the bitcoin network. Otherwise, if the hash is below the pool's threshold and the coinbase address is pointing at the pool, then block+hash are sent to the pool as proof of effort. Otherwise, the attempt has no effect. If this attack could be set up, then the data seen by the pool would be consistent with the miner having only 5/6 of the hash power that he really has. Of every 6 successfully mined blocks, 5 would be credited to the pool, and 1 to the thief; but the pool will not notice the latter. If the miner is monitoring his performance exclusively through the pool's site, he will not notice the stolen blocks either -- only a loss of 1/6 of the hashpower. Does this make sense? Earlier this year a disgruntled IT worker at a cable company in Canada did something rather like that. The weak points was using Stratum (I don't) and his access to routers at the company. Normal share divisions is timed by the pools servers. In round-robin they periodically poll the miners to see if data is needed or available from them. To some extent I assume the polling is adjusted to a miners performance but still is up to the pool servers to decide. Like any good single purpose tool the miner only does what is needed and only when asked. Stratum makes the miner a bit more of an active party in that it does not wait. Only link I found on a quicky is https://en.bitcoin.it/wiki/Stratum When needed it pings the block server for actions. In the above case it also pointed out a flaw in Stratum - the ability to actually *run* other code. AFAIK that is fixed btw. Point is, yes the perp injected code into miner data being moved: At the ISP's routers he targeted a couple pool servers for the re-directs and injection. Once the miner got the new code it from time to time changed the wallet addresses mined to... |
|
|
|
im curious... is there even 1 amt miner out in the world that is working?
I have the feeling that after me cleaning it up, changing the fans *and getting a PSU from AMT*, channeling airflow, my miner is one of the best of these running out there... Consistently reports 1 to 1.02ths on the EMC pool with 900ghs or so for dips and the occasional 1.21ths as a not very often spike. Oh, and the 1 working card from the original design testbed is still running a rock-solid 178ghs. A long way from the 250-something ghs it should be but solid. The 2 other functional ones shipped with it died within days. |
|
|
|
Not to imply anything, but: there were claims (not confirmed, apparently) of another Chinese manufacturer of mining equipment that shipped machines with a closed-source software that stole 10% of the solutions and sent them encrypted to the manufacturer.
Not versed in what's implied by solutions, but your post brought something to mind. Recall, BFL used this dude name John Cheng outta California to produce their chips, first the 65nm-, then the 28nm-based one. I can't seem to shake the notion that something's amiss outta that camp, with Sonny benefiting somehow due to funding the 28nm (and previously the 65nm) chip development off the backs of BFL's investomers. Sonny is on record in stating that John's to blame for the chip being late, but seemed calm during the exchange as like saying, "Oh, well, shit happens!" Akin to taking monies earmarked for one venture, allocating them toward another, then profiting due to the exchange with only later satisfying those who contributed with product that's no longer relevant, i.e., the Monarch.<snip? One thing our Josh had mentioned was that there are a very few 'go-to folks' that many of the miner chip companies used for basic design ideas. And for the 28-20nm series of chips at least most miner companies hit the same problems: Grossly underestimating both the thermal and power needs of the designs and how they set very specific requirements for the boards regarding materials, power circuit design, physical layout, and construction methods all of which the Powers That Be at the various miner companies cheerfully ignored through too many board revisions until too late. Coincidence? |
|
|
|
no matter if you believe it or not, that is what I was sent from China and I am not a liar. No one else was sent a miner with used fans.
Bzzzzt. wrong. The original fans in my miner are also pulls from salvaged servers. Filthy dirty and the wires cut to less than 1inch long stubs which have extension wires added to them. |
|
|
|
For all intents and purposes and better or worse, so the community at large can see his full range, the FULL chat logs from when we started will be getting released. No more snippets of leaks. NotFuzzyWarm and I agreed it would be better the community sees it all. Rather than snippets. Our real and skype names will be changed to our forum names for purposes of privacy. That is the only change. Obviously in alot of cases we said things to bait him to talk and gain his trust. Those who we speak of already are aware of this as it has been pointed out in private as well. At any rate for better or worse those chats are being prepared for a full release.
Joshua Zipkin is predictable....easy to read. I will admit I am not proud of the things I had to say in those chats to get him talking, but it was necessary to keep his trust especially when he started questioning it.
I will also similarly be releasing my personal chats with Josh as well. Since he has shown no interest in being honest with anyone. The best way is to just expose him raw. I did what I thought was right at the time to try to get everyone made whole. He made excuses not to. Despite stating in the first AMT thread that AMT would go broke to make this right with us. That again was another lie.
^^ Ditto. Only exception is that my personal chats with Josh will not be released. While Joshua Zipkin never presented me with a copy of the NDA signed by him I *did* submit an amended and signed copy to him regarding working on solving the problems with the first Bitmine.ch/AMT hash boards. For what it's worth I do consider myself professionally bound to the NDA and as the personal chats are nearly 100% regarding protected IP owned by Bitmine.ch and others (not not mention very dry and technical) they are not open for Public view. Normally since the relationship with Josh/AMT has ended I would destroy all pertinent IP documents however - given the ongoing legal matters they are safely archived if needed until the legalities are resolved. As Opeium has said, a disclaimer is needed: This was an open and honest (on our part) chatroom meaning off-the-cuff chatter. Some about folks here are um, not spoken of in the best light. Then again, in the Early Days of the AMT Saga Opeium and I made our views about them known here so Sorry in advance and hopefully is water under the bridge. To the true trolls mentioned - Fine. We already said it before but, you were right. Then again even a broken clock is right 2x a day. I still say bugger off. With the full context of the chats one thing that will be very clear was our intent and reasons for our contact. Only goal for me was getting the Bitmine.ch/AMT board crap party resolved so miners could get shipped. Period. Josh put an end to that within weeks with plans for China... Going with Innosilicon's boards was the one intelligent thing Josh has done. Actually settling with his existing customers would be the one other but don't see that happening in this lifetime. |
|
|
|
|
Show Posts
