@kilo17,
Thank you for sharing the info!!
If the Beagle Bone was fried, when the PSU went down, your unit is covered under the warranty. Please contact Bitmain or tech support and the tech can arrange you the replacement Beagle Bone.
We have beagle bones and the control PCB in stock for RMA needs!
So, you refuse to help the guy when he first asks you, leaving him to work out a fix for himself. Then, after he's done so & posted about it and your lack of help - you then decide to offer help for him?  Bit late don't you think? |
|
|
|
It's not just their prices anymore, their support has gone down the drain too, as well as their lack of quality control. Their S4 release was a joke, completely untested hardware & firmware resulting in either units going up in smoke or users only able to mine at a few select pools efficiently - so much for the "decentralization" they like to promote. Talking of which, they promised their customers that they would be investing heavily in p2pool months ago, but have gone completely silent since then - and the only miner that works with it out of the box is the S3. S2 users were promised a firmware update over 9 weeks ago to patch many security flaws, but again, nothing - leaving users vulnerable to having their hash rate redirected, as has been reported. The latest S3 firmware update actually breaks the units & has to be fixed immediately after flashing in order to be able to use it again, plus it's slower & performs worse than the earlier firmware, but Bitmain just leave it on their site anyway. S4 users have been promised a firmware update to fix all the issues also, but again, nothing. I can see the S4 users being tossed into the garbage can in the same way the S2 users were after parting with their cash for their latest & greatest units, waiting for promised updates to fix the various issues for weeks but getting ignored while Bitmain are busy promoting their latest model that probably won't work as advertised again due to zero R&D & no testing of firmware....... Bitmain have thrown their reputation down the drain, and their threads are now littered with dogie poop. I'll not be buying anything else from them again until they clean up their act, and their threads.....  Off to spondoolies I go. |
|
|
|
There's quite a lot wrong with this firmware update for me I'm afraid, apart from it being broken in the first place of course. Having to fix it before you can use your S3 again after flashing is pretty stupid on it's own, but the appearance of two invisible fan readings with no explanation & the voltage adjustment setting, again with no explanation, make it verging on the ridiculous. I've been running it on two of my S3's for 24 hours now just to experiment & see if there is any improvement over my other Ants running the older firmware with ck's excellent S3 binary added, and from what I can see - it's worse. The load on the Ants has gone up from ~1.8 to over 2.4, the reject rate has gone up from ~2.5% to over 3.5%, the stale rate has gone from less than 1% to over 2% and the cpu usage has increased from ~75% to 95-100% - the only thing that hasn't changed is the HW error rate & the hash rate. I'm not sure if Bitmain are using the same binary that ck done for the S3, but if they are, I can only imagine that all the extra needless additions to the (broken) firmware are overloading the already overloaded/underpowered controller which is causing the higher rejects/stales/cpu rate. One thing is certain though, Bitmain have once again not bothered testing their firmware whatsoever, making the same mistake as they did with the S4 - simply because if they had of tested it properly they would have noticed that it was not only broken in the first place, but also that the performance was worse than the older version. I just thank the cyber gods that I didn't rush straight in & flash all my S3's in one go with this junk firmware, as I now have only two S3's to revert back to the older firmware with ck's binary - instead of 20 Whoever "created" this firmware should be sacked. |
|
|
|
@ Ki773r: PatMan is correct. I done some testing of these settings some time ago & posted the results: I've ordered from batch 1, batch 4 and batch 5. Even in batch 5 the issues remain, although I did get "lucky" as one of my batch 5 units actually hashes at 504GH/s stable.
I also have one of those lucky ones at 505Gh/s from B1 - it's the most stable one out the lot!! Following up from this, I've been experimenting a little more with my settings & here's a screen of the results:  (click for larger) This is 4 x S3's running at various clock speeds. Looking at the graph, I was running --queue 1 up until ~3am (yup, I'm a night time fiddler  ) before changing the setting to --queue 0 & letting them run for the same amount of time. It can clearly be seen that after changing the setting to --queue 0, the DOA rate dropped & smoothed out - this was also confirmed by my nodes info page. Average hash rate was slightly higher as a result, so I'll be keeping all my S3's running with the --queue 0 setting from now on. I'm not saying that this will work for everyone, but it's definitely good for my setup & worth giving a try if you're experiencing a higher than expected DOA rate. The dip in hash rate at the end of the graph was due to a reboot after updating Xubuntu. Smoke'em if ya got'em  Edit: It's also worth mentioning that my reject rate was at ~4% with --queue 1 - and ~2% with the 0 setting. This is running on a local node. You are quite knowledgeable of p2pool, but to suggest that someone "doesn't know anything about what he is doing" when they clearly do, belittles you & your "legendary" status. Seems you owe him an apology Since setting --queue 0 my DOA has dropped to 2.6% and my stale rate is only 1 over the last 16 shares, this is much better than I was getting before making the change. Cheers. Glad it worked for you! |
|
|
|
Copy of PM I sent to Tim.Shao19 of Bitmaintech: Hello again Tim,
I see you have released another firmware update for the S3, the second in 6 weeks, where as S2 owners are still waiting for the firmware update you promised them over 9 weeks ago - and are still at risk from the various security threats associated with the older firmware. Why is this?
Also, your latest firmware for the S3 actually breaks the S3 - why have you not withdrawn it to fix it?
IYFTech.
|
|
|
|
Whatever dude |
|
|
|
TxID's are in the block chain & so in the public domain - it's not private at all - that's the whole idea What's your payment address if I buy one? |
|
|
|
Repost especially for the BAN shills who missed/ignored it:
Proven fake pics.
Proven fake user accounts.
s0br refusing/unable to answer a single question.
thephawner refusing/unable to answer a single question.
Deleted comments/evidence from pool thread.
Pool thread still locked.
Barrage of insults from the same few BAN shills here.
Etc, etc.......
THEY DID IT, PURE & SIMPLE. DO NOT TRUST THEM!!!!
Your time would be much better spent encouraging s0br to come out of hiding, than bumping this thread with pointless statements.
If you feel that you can do what s0br couldn't, and provide evidence to the contrary - please present it. If you can't, please refrain from posting.
Thanks.
I'm not sure how much more proof you want TBH......... Give it up dude - it's pointless & making you look worse than you already are.........really. It's done. Finished. Over. |
|
|
|
so it is reasonable to ask for at least 8-9 BTC.
Not anymore it ain't, those daze are loooong gone....... |
|
|
|
|
Website registered yesterday.........I'll pass.
|
|
|
|
Sooo, Bitmain release a new firmware for the S3 - that totally screws them up...... Meanwhile, S2 users are still waiting after 9 weeks........still having their hash stolen........ Thanks Bitmain........ |
|
|
|
@ Ki773r: PatMan is correct. I done some testing of these settings some time ago & posted the results: I've ordered from batch 1, batch 4 and batch 5. Even in batch 5 the issues remain, although I did get "lucky" as one of my batch 5 units actually hashes at 504GH/s stable.
I also have one of those lucky ones at 505Gh/s from B1 - it's the most stable one out the lot!! Following up from this, I've been experimenting a little more with my settings & here's a screen of the results: (click for larger) This is 4 x S3's running at various clock speeds. Looking at the graph, I was running --queue 1 up until ~3am (yup, I'm a night time fiddler ) before changing the setting to --queue 0 & letting them run for the same amount of time. It can clearly be seen that after changing the setting to --queue 0, the DOA rate dropped & smoothed out - this was also confirmed by my nodes info page. Average hash rate was slightly higher as a result, so I'll be keeping all my S3's running with the --queue 0 setting from now on. I'm not saying that this will work for everyone, but it's definitely good for my setup & worth giving a try if you're experiencing a higher than expected DOA rate. The dip in hash rate at the end of the graph was due to a reboot after updating Xubuntu. Smoke'em if ya got'em Edit: It's also worth mentioning that my reject rate was at ~4% with --queue 1 - and ~2% with the 0 setting. This is running on a local node. You are quite knowledgeable of p2pool, but to suggest that someone "doesn't know anything about what he is doing" when they clearly do, belittles you & your "legendary" status. Seems you owe him an apology |
|
|
|
According to "Bitmain employee of the Year" dogie in his updated "no conflict of interest here" manufacturer trustworthiness guide - these are classed as "minor" problems, so obviously they are not too bothered about it. Their "please wait patiently" phrase is one of their favourites, ask any S2 owner, they've been "waiting patiently" for 9 weeks now......and still nothing dogie is an employee of Bitmain and there is a conflict of interest in conscious or unconscious level. So, dogie statement should be considered as Bitmain's even if he is not agreeing that there is no conflict of interest. It's already evident in his messages. I would say that upgrading the Bitmain communication rating to "Great" was a "conscious" decision.....nothing like a bit of self promotion looking for a pay rise. What a joke. |
|
|
|
According to "Bitmain employee of the Year" dogie in his updated "no conflict of interest here" manufacturer trustworthiness guide - these are classed as "minor" problems, so obviously they are not too bothered about it. Their "please wait patiently" phrase is one of their favourites, ask any S2 owner, they've been "waiting patiently" for 9 weeks now......and still nothing |
|
|
|
I will offer BTC0.45 including shipping to the UK for the boxed, unused S3+  Only with escrow or you ship first, PM me |
|
|
|
Have these had the self incinerating PSU's changed? Also, what is the power draw on them? Ta |
|
|
|
So far so good - I noticed mdudes antmonitor no longer reports the diff value, did something change?
Lowmem stops showing the diff, so perhaps that's why. Yup, gotcha. Load has increased a little - it used to be around the 1.7 mark, but now sits around the 2 mark, not that it bothers me at all. I'll let it run a few hours to settle down...... Thanks for this ck, will report back later with any findings |
|
|
|
Here's an updated S3 binary. http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminerRecommended if you're mining on p2pool for the default binary actually discards stale shares which you should never do, especially on p2pool. Also includes changes to queuing and memory usage that were necessary on S4 but probably only of minor benefit here. Recommend you edit the cgminer startup script to remove the --queue value entirely, and add --lowmem. Performance should be pretty much unchanged. Excellent ck! Will try it now, many thanks So far so good - I noticed mdudes antmonitor no longer reports the diff value, did something change? |
|
|
|
Here's an updated S3 binary. http://ck.kolivas.org/apps/cgminer/antminer/s3/4.6.1-141020/cgminerRecommended if you're mining on p2pool for the default binary actually discards stale shares which you should never do, especially on p2pool. Also includes changes to queuing and memory usage that were necessary on S4 but probably only of minor benefit here. Recommend you edit the cgminer startup script to remove the --queue value entirely, and add --lowmem. Performance should be pretty much unchanged. Excellent ck! Will try it now, many thanks |
|
|
|
|
Show Posts
