Yeah, sigh, it's another DNS issue like back in April. I had thought I'd resolved that by adding 2 more backup DNS servers but that hasn't handled the master DNS server failing. DNS will be back up as soon as the master is rebooted ... still awaiting for that ticket I raised almost 3 hours ago  Take a look at UltraDNS, I use it for my company and its been solid and very resistant to DDNS attacks. Not very pricy either when you have only a few domains and you can make the TTL long to cut down on the queries. |
|
|
|
When you flash does it reset the factory settings as far as frequency and voltage
factory settings on mine are:
Frequency 350M
Voltage 0725
You can double check to see what your factory settings were by logging in using Putty
Login as: root
password: admin
then to view the factory settings just type
cat /etc/cgminer.conf.factory
you should get something like this returned to you
{
"pools" : [
{
"url" : "solo.antpool.com:25",
"user" : "antminer",
"pass" : "123"
},
{
"url" : "p2p.antpool.com:3333",
"user" : "antminer",
"pass" : "123"
},
{
"url" : "stratum+tcp://stratum.f2pool.com:3333",
"user" : "ant.1",
"pass" : "123"
}
]
,
"api-listen" : true,
"api-network" : true,
"api-allow" : "W:0/0",
"bitmain-freq" : "3:350:0d82",
"bitmain-voltage" : "0725"
}
root@antMiner:~#
This was one of my factory config files on one of my s5's
as you can see factory freq was 350
and factory voltage was 0725
It does not reset the settings, I have the box checked to leave setting intact. I have 10 or so of the S5's, half are running at 375 and half at 400, just depends where I have them. The ones at 400 are in a cooler area then the ones at 375. They are all between 53-60c and this just started a few days ago. |
|
|
|
Issue with S5, here is a new one for ya. I have several S5's all running great on this pool. 2 days ago one of them started reporting only 800-850 Gh, while since placed in service its been reporting 1200-1290 Gh on the pool and on the UI. I have re-flashed with cgminer 4.9, rebooted, restored to factory etc. The UI reports the correct 1200-1290 hash rates, all chips report good, temps look normal. Nothing looks odd or different on the miner UI. I even tried 2 other pools and then all report speed at pool around 800-850 Gh while on the miner showing 1200-1250 avg.
Any ideas?
I guess my first question would be, how long are you allowing it to run on a pool before you decide it's slow? It does take time before you will get the 'UI side' to correspond with the 'Pool-side' readings. edit;plus, are you pre-setting the difficulty or allowing the pool vardiff to set difficulty? So after further testing, I pointed the miner to Ghash, it ran there for about 3 hours and it reports pretty much the same stats. On Gash the 5min refreshes every 10 seconds or so, I can see it go to 1.3 hang there and then start to drop back down to 800 or so, then back to 1 or 1.1 and drops back down. after 3 hours there, the 15m is 924Gh and 1hr is 990Gh, but now the 5 min is 1.21. So its like bouncing all over the place, now I am seeing similar behavior with another miner on Kano. In both cases the UI stats show 5s over 1.2 all the time and the avg is 1.23Th since last reboot 3 hours ago. I have done it both ways, set Diff manually at 1024, let is run for a day or two and then also set to zero and let pool manage diff. No difference. NOTE: Some of my S5's show best share and some show zero, same FW and same pool. Also some show DiffR and some don't. I'd expect the UI to show at least the same type of data across all my S5's on the same pool and same FW. |
|
|
|
|
Issue with S5, here is a new one for ya. I have several S5's all running great on this pool. 2 days ago one of them started reporting only 800-850 Gh, while since placed in service its been reporting 1200-1290 Gh on the pool and on the UI. I have re-flashed with cgminer 4.9, rebooted, restored to factory etc. The UI reports the correct 1200-1290 hash rates, all chips report good, temps look normal. Nothing looks odd or different on the miner UI. I even tried 2 other pools and then all report speed at pool around 800-850 Gh while on the miner showing 1200-1250 avg.
Any ideas?
|
|
|
|
Come on 64 hours already at time of this post and no block found yet  We're only at 150%, these happen very regularly. I wouldn't be surprised if we get to 200%+ Certainly hope its not one of the killer blocks, Antpool had one a few days ago. over 10 hours @66Ph. 584 Billion shares. That would take us like 21 days.... 371476 2015-08-25 11:39:10 25.51818244 121/120 10h 26m 12s 9.29% 66.80 PH/s 584,347,818,850 https://blockchain.info/block-index/0000000000000000136b74f40d450a726f12f6fe7efda208089ac73959ef8680That would be very nasty. I don't know what the luck% that come down to but one of those block is very rare. We had a 666.66666% block early this month it was iirc... and people were bordering on tears. ^_^" I've been here for a couple months so I know that block well. The above block @ANT was around 1,080% |
|
|
|
Come on 64 hours already at time of this post and no block found yet We're only at 150%, these happen very regularly. I wouldn't be surprised if we get to 200%+ Certainly hope its not one of the killer blocks, Antpool had one a few days ago. over 10 hours @66Ph. 584 Billion shares. That would take us like 21 days.... 371476 2015-08-25 11:39:10 25.51818244 121/120 10h 26m 12s 9.29% 66.80 PH/s 584,347,818,850 https://blockchain.info/block-index/0000000000000000136b74f40d450a726f12f6fe7efda208089ac73959ef8680 |
|
|
|
Wish I found this thread before I sent them 13btc for s5 miners! Lesson learned. Maybe take up a collection for the victims fund! |
|
|
|
Right now its adding several clicks to the usual several click to login then check your worker status. Its a lot of clicks unless you have a dedicated page on at all time auto refreshing so your session doesn't time out. Why not let read-only data always on?
I don't see a reason for always having to relog.
Same reason why a bank logs you out. Right, but a bank is transactional. PostgreSQL is transactional also  Not sure what the point is though. I think what he is saying is stay logged in to read stats and data and require login again if changing anything.
Session life time is fixed at where I consider it optimal and as the system wide php setting. If you want to stay logged in then use firefox with a reload every 5 minutes (like I do) or some other such option. Or use the API which has no session life time. Yes that is what i meant. There's no need for session expiring security on my private computer, imo. The information i'm interested to read is already public and kinda public. (Hashrate/Worker) Then if you need to change settings, you already need to re input your password so *shrug*. I might go the API route. The auto refresh doesn't work in every for situation for me. Maybe it could even be turned into a simple rain meter widget. That would be dandy. I don't mind this on the computer, but on my phone it's a PITA to keep logging in to check on my workers and hash. It was perfect before as my Mac would remember credentials in safari and all that is synched with my phone so I would just auto fill on phone. Now I have to type it in each time on my phone. |
|
|
|
Right now its adding several clicks to the usual several click to login then check your worker status. Its a lot of clicks unless you have a dedicated page on at all time auto refreshing so your session doesn't time out. Why not let read-only data always on?
I don't see a reason for always having to relog.
Same reason why a bank logs you out. Right, but a bank is transactional. I think what he is saying is stay logged in to read stats and data and require login again if changing anything. |
|
|
|
ckdb fixed - restarted and block now showing up properly.
Of course as per usual with a ckdb restart, no mining was affected at all.
As for the login page, can you clear all the remembered form data for the web site and see if that helps?
I do have it showing up on one of my browsers (I have 2fa on all the time now)
As for 2fa itself, if you don't enable 2fa, login is still just username+password as before.
You don't have to enable 2fa if you don't want to.
If you enable 2fa (later when it's ready - or if you want to try it now) then the 2fa value will also be required everywhere you enter your password.
Looks like Chrome saved password works, but does not work in Safari. It did work prior to the 2Fa changes. Possible that the 3 entry box on the new page is messing it up. Would it be possible to have a register, login and login 2FA link? If the standard login is back on its own, that may work as it did before. Another option is to put the login back where it was on the upper right of page, then just provide a 2FA login link that takes you to the new login page. Thanks, So that did not work, I see the stored user/pass in my keychain but each time I land on the login page, safari suggests a password after I enter username. I think its not detecting the page as the one I have already stored a user/pass for. Although the keychain shows kano.is https and saved user/pass PS. What about forwarding HTTP to HTTPS for the landing page? Then you could use the original login/pass that was at the top right, just a suggestion. |
|
|
|
ckdb fixed - restarted and block now showing up properly.
Of course as per usual with a ckdb restart, no mining was affected at all.
As for the login page, can you clear all the remembered form data for the web site and see if that helps?
I do have it showing up on one of my browsers (I have 2fa on all the time now)
As for 2fa itself, if you don't enable 2fa, login is still just username+password as before.
You don't have to enable 2fa if you don't want to.
If you enable 2fa (later when it's ready - or if you want to try it now) then the 2fa value will also be required everywhere you enter your password.
Looks like Chrome saved password works, but does not work in Safari. It did work prior to the 2Fa changes. Possible that the 3 entry box on the new page is messing it up. Would it be possible to have a register, login and login 2FA link? If the standard login is back on its own, that may work as it did before. Another option is to put the login back where it was on the upper right of page, then just provide a 2FA login link that takes you to the new login page. Thanks, |
|
|
|
I use the google 2fa for lots of websites I am a big fan although maybe I should not be ?
I don't understand how compatibility with a sha256 algorithm is relevant to 2fa
OTP uses a hash function to generate the code. "google 2fa" isn't "google", it's simply just the 2 IETF RFCs https://tools.ietf.org/html/rfc6238 https://tools.ietf.org/html/rfc4226I use sha2-256 since it's reasonably secure ... that's what we use in bitcoin mining It would appear that the "Google Authenticator" app doesn't understand the code that says to use sha2-256 so it only uses sha1 - which of course wont give the correct 6 digit hash number. The RFC specs say it should allow it but it doesn't work. The 2 Apps I've listed work fine when told to use SHA2-256 You can run both apps on one phone/tablet if you need to. However, you will find that the App I'm suggesting you use should work with gmail login also. Kano, Since the update to the page with 2Fa, the login and register have been combined, but my browser will no longer profile the login user & pass. I now have to type in the credentials each time where before the update I was able to have browser profile the upper right green login box that existed. Also, not profiling on my mobile phone, both of these were very useful as I check on miner status many times a day. Anything that can be done about that? Maybe extend the mission cookie to 24 hrs? don't mind logging in once a day but the current timeout must be around 15 or 30 min. Also, I am guessing that 2Fa will be optional and for things like changing payout address and not each time you login? again, just guessing. |
|
|
|
|
Nice, removing truth from this forum! Way to go!
You have just been sent a personal message by Bitcoin Forum on Bitcoin Forum.
IMPORTANT: Remember, this is just a notification. Please do not reply to this email.
The message they sent you was:
A reply of yours, quoted below, was deleted by the starter of a self-moderated topic. There are no rules of self-moderation, so this deletion cannot be appealed. Do not continue posting in this topic if the topic-starter has requested that you leave.
You can create a new topic if you are unsatisfied with this one. If the topic-starter is scamming, post about it in Scam Accusations.
Quote
Quote from: rikkie on August 03, 2015, 05:35:24 PM
Quote from: jmumich on August 03, 2015, 05:21:04 PM
Quote from: alh on August 03, 2015, 04:24:38 PM
Even if you can't get one of their new units, their website suggests that you buy an S5 for $199. Might be a good consolation prize.
While I told them I'd be happy to review a test unit for them, I can tell you that this alone raises red flags for me.
There's no reason to sell an S5 for $199. The market price is twice that.
The hardware has been used, this is why the price is so low. We no longer need this equipment.
How about you refund my 14 BTC or actually ship me the S5's I ordered 3 weeks ago!
We have received all required funds for your payment of 7.26439100 BTC to Cloud Think Mining Ltd. and your payment is now Complete.
The transaction ID of this payment is: 492daf46a98baea68e8eee9cb152c4711f4f33b8ad1b9fb7593c3bef46d52a9d
We have received all required funds for your payment of 3.74955900 BTC to Cloud Think Mining Ltd. and your payment is now Complete.
The transaction ID of this payment is: 3f35feeee2bc244045249d1c9ab054a754bf7078d0496a61f1cbb29b5e06d01e
We have received all required funds for your payment of 3.03512700 BTC to Cloud Think Mining Ltd. and your payment is now Complete.
The transaction ID of this payment is: 6398ea47da3d43c13ae9e39a4ec4fdc390c324e873f5446444d82bfb1a1e810d
|
|
|
|
I mined NMC with the "majority" because I had no choice....
Which places you firmly in the minority (akin to extremists in this forsaken landscape). Still, no skin off the majority's nostrils. ... well you missed one rather important point in my post: F2Pool is 75% of the NMC mining and those mining there are averaging less payout than the expected average here. ... still sounds like a majority of fools to me. You did miss that detail that I have NEVER mined at F2Pool then ... (as in no skin off my nose). Lets just say the "actual" average payout at slush is more than the "expected" average here. Now there. No it isn't. His fee is higher and his long term luck is lower ........... First off I don't use Slush anymore, I did several months back till I pointed my hash to Kano, but I did see that they dropped their 2% effective 8/1 and also started alt coin mining at the same time. But instead of giving you the alt coin, they instantly sell the alt coin and convert to BTC and add to miner rewards. Have no idea if that really makes a difference, but figured I'd chime in and make everyone aware. Thanks, |
|
|
|
So your saying that since the network as a whole had a period of bad luck, people shut down 70ph of hash during that time? Hash is Hash in the network, good luck or bad luck does not change how many miners are connected.
Nobody has any clue as to what the actual network hash rate is. It can only be estimated based on the rate blocks are solved. I see, did not know that. I figured there was a way to measure network hash rate by all the nodes that are connected. Did not know that network hash rate is only estimated based on block solve rate. Makes sense, thank you! |
|
|
|
31 minutes since the network has solved a block... is that a long time or is it just me
Meh... they are all slow today
2 days ago I saw 57 minutes since the network solved a block, it was a period where about 70Ph fell off for a while, since the diff is based on network hash and say a large pool has issues and the network looses 70ph, blocks can get quite long. I see that as an issue if say China lost all internet in a massive attack or natural disaster. Since more then 60% of all the hash is in China, we would be in deep dodo with blocks going days and maybe weeks. You have it backwards. It appeared that 70PHs fell off because of the bad luck on the entire network. It's the opposite as when there is a run of good luck and it appears that a lot of hashrate has been added to the network. I'm constantly surprised that so many miners don't understand this simple principle. So your saying that since the network as a whole had a period of bad luck, people shut down 70ph of hash during that time? Hash is Hash in the network, good luck or bad luck does not change how many miners are connected. Unless they choose to disconnect or a network/power/disaster type issue prevents them from connecting. I'm not sure I get the luck effect of current network hash. Luck only effects finding blocks and payments. Maybe I am missing something here. I think what we are saying is that china went offline, it would take a long time at 150ph to get past 2000 or so blocks till next adjustment. Much longer vs. someone adding 200ph to the network, within 1-2 days it would adjust to 100B plus to bring back to 10m blocks. Not being rude or anything, just don't understand the correlation of luck and amount of hash on network as a whole.  |
|
|
|
31 minutes since the network has solved a block... is that a long time or is it just me
Meh... they are all slow today
2 days ago I saw 57 minutes since the network solved a block, it was a period where about 70Ph fell off for a while, since the diff is based on network hash, then saw a large pool has issues and network looses 70ph, blocks can get quite long. I see that as an issue if say China lost all internet in a massive attack or natural disaster. Since more then 60% of all the hash is in China, we would be in deep dodo with blocks going days! Maybe China should lose internet more often.  They already have too much hash and could do with less. A big portion of the hash is there and it kinda feel like centralization to me. I agree, less hash from China. But with the diff at 52+ it would take months if not years for the network diff if reduce enough to get 10 min block if 60-70 percent of the hash went away. The remaining miners would have to fork the chain to get back to 10m blocks in a reasonable time frame. My 2 cents No, it would take to the next 2016 block re-adjustment to go down appropriately, at most two. If we lost 60% of the hash rate today, next week the diff would adjust downward significantly and the following 2016 block adjustment would finish it off. Correct, but if we lost that much hash shortly after an adjustment it would take a LONG time to get 2000 or so blocks. Say we are at 400ph now, just adjusted and then network went to 160ph it would be months. We lost 70ph for a short time a couple days ago and I saw a almost 1 hour block and others in 30min plus. At that time network went to 320ph. Now imagine 160Ph. I'm sure someone can do the math at 160ph at current diff and 2000 blocks to mint before next adjustment. Ahh, ok I see your point now... Misunderstood the angle you were taking with it. Would be roughly 2.5x longer, right? If it takes about 12 days now, it would take 30 days to get to the next adjustment in that case. Here is another viewpoint on the same topic. http://www.reddit.com/r/Bitcoin/comments/3fg0jw/could_a_cartel_of_pool_operators_collude_to/ |
|
|
|
31 minutes since the network has solved a block... is that a long time or is it just me
Meh... they are all slow today
2 days ago I saw 57 minutes since the network solved a block, it was a period where about 70Ph fell off for a while, since the diff is based on network hash, then saw a large pool has issues and network looses 70ph, blocks can get quite long. I see that as an issue if say China lost all internet in a massive attack or natural disaster. Since more then 60% of all the hash is in China, we would be in deep dodo with blocks going days! Maybe China should lose internet more often. They already have too much hash and could do with less. A big portion of the hash is there and it kinda feel like centralization to me. I agree, less hash from China. But with the diff at 52+ it would take months if not years for the network diff if reduce enough to get 10 min block if 60-70 percent of the hash went away. The remaining miners would have to fork the chain to get back to 10m blocks in a reasonable time frame. My 2 cents No, it would take to the next 2016 block re-adjustment to go down appropriately, at most two. If we lost 60% of the hash rate today, next week the diff would adjust downward significantly and the following 2016 block adjustment would finish it off. Correct, but if we lost that much hash shortly after an adjustment it would take a LONG time to get 2000 or so blocks. Say we are at 400ph now, just adjusted and then network went to 160ph it would be months. We lost 70ph for a short time a couple days ago and I saw a almost 1 hour block and others in 30min plus. At that time network went to 320ph. Now imagine 160Ph. I'm sure someone can do the math at 160ph at current diff and 2000 blocks to mint before next adjustment. |
|
|
|
31 minutes since the network has solved a block... is that a long time or is it just me
Meh... they are all slow today
2 days ago I saw 57 minutes since the network solved a block, it was a period where about 70Ph fell off for a while, since the diff is based on network hash, then saw a large pool has issues and network looses 70ph, blocks can get quite long. I see that as an issue if say China lost all internet in a massive attack or natural disaster. Since more then 60% of all the hash is in China, we would be in deep dodo with blocks going days! Maybe China should lose internet more often. They already have too much hash and could do with less. A big portion of the hash is there and it kinda feel like centralization to me. I agree, less hash from China. But with the diff at 52+ it would take months if not years for the network diff if reduce enough to get 10 min block if 60-70 percent of the hash went away. The remaining miners would have to fork the chain to get back to 10m blocks in a reasonable time frame. My 2 cents |
|
|
|
Holy shit, that are really trying to clean up before they disappear for good. I hope more people don't get burned like I did on the S5's hardware, really? They developed their own ASIC and hardware?? Introducing the NEW - CloudThink Imperator Bitcoin Miner http://cloudthink.io/imperatorminer/Dear CloudThink Customer, This email is to inform you that CloudThink has just released the new 8TH/s Imperator Bitcoin Miner with a very limited stock of just 500 units and only one unit / customer. The product is new and comes with a 24 months warrantfor all defects. Shipping is handled from Manchester, UK and included in the product price. This is your chance to run the best bitcoin hardware available this moment and become a Premium Bitcoin Miner. The first 500 units are ment to prove how CloudThink manages to sustain a very profitable business plan through innovation and brilliant design. The current price is available only for the first batch of Imperator Bitcoin Miners. Prices may change for next batches. Kind regards, CloudThink.IO support@cloudthink.io |
|
|
|
|
Show Posts
