I think the error you’re getting is because of connectivity issues. During and since their “upgrade”, which they refuse to divulge what was actually being upgraded, their servers have had horrible issues with latency and connectivity. I actually think since EIP1559 they have actually DOWNGRADED their servers in order to save money and still offer a “free” pool. The servers in the east coast of the US have had 300ms or greater ping times since and every other server has had a significant increase in ping times. I don’t think they were upgrading anything. The loss of income and poor connectivity since clearly indicate that there was an actual downgrade. If you run the net stats command, you will see the HORRIBLE ping times from their servers worldwide, not just one particular set of servers. And even more alarming, if you run the test over and over consecutively, you will see that on each run there’s at least one or two FAILED connections to their API servers. As a client, I don’t see how HiveOS can actually pay for a service like that. I believe that they’re using CloudFlare free services as a CDN and you’re seeing the results of that.
Can you please tell me how you concluded that the loss of income was “added” yesterday. I’m genuinely curious how u made this deduction without actual internal access. I want to see if my losses were added yesterday cause I was off the pool for almost 12hrs and they haven’t added a penny.
fwiw: Have you used the newer feature in the flight sheets to measure access to the servers?
If you have multiple rigs, consider pointing at various primary/backup options or even pools.
I run my own Recursive Resolver (Unbound) from home and get usually 0.1-0.5ms response times to repeated/cached queries on Unbound. Even with this advanced setup, NOTHING helps HiveOS ping times. Just check your net stats, you won’t see a ping under 80ms from ANY server at any given time, usually it’s 300-3,000ms. In a situation like that there’s nothing the user can do. HiveOS obviously uses low quality servers or most likely a free or lower-tiered CDN plan. Nothing can be done about that. They have to upgrade their servers.
I’m not sure if that’s the case.
I would be more inclined to agree with your hypothesis if, after I reboot the system, it would still fail to connect.
The fact that a reboot appears to “fix” the issue would suggest something else.
I won’t be surprised if it was due to HiveOn “upgrading their infrastructure”, but again, the fact that a reboot appears to “fix” this issue - I’m not sure how I can make it “fix” itself WITHOUT having to do a reboot.
A miner stop/start doesn’t seem to be enough to try and rectify/resolve this issue.
re: ping times
The other potential hypothesis as to why their servers might have longer ping times CAN also be the fact that other people are realising that HiveOn pays the transaction fees (unlike ethermine) and therefore; people might be jumping on to the HiveOn pool for this reason.
I was actually originally mining on the HiveOn pool and then jumped on to the ethermine pool after watching a few of the YouTubers use ethermine, and then once ethermine implemented the change where miners would have to pay your own transaction fees to get your ETH out from the pool (like I said, I was paying like 50 Gwei to get my ETH paid out from ethermine), I jumped back onto HiveOn pool because HiveOn pays your transaction fees.
I think that more and more people are realising that this is the case, so I won’t be surprised if a part of the reason for the slow down is the increase in activity/traffic on the pool itself that HiveOn previously didn’t have.
That would be another hypothesis.
And yes, the ping times have gotten worse (actually, more importantly, the standard deviation for the ping times have gotten worse), but I’ve also historically didn’t get great ping times already in the first place (when I am trying to secure my system).
To your last point - I have no idea.
I was going to run some tests with the different local pool addresses, but it looks like that this might be a broader, systemic issue because I did notice the increase in ping times at least starting from about a week ago.
But the error message that I am getting/seeing now - this is more of a more recent development (as of at least the 20210818 HiveOn OS/client release).
(The good news is that it is very easy for me to roll back to an earlier version of their OS by just swapping out the hiveramfs.tar.xz file on my HiveOS diskless PXE server.)
As I stated earlier, I ran consecutive net tests for over an hour, and EACH AND EVERY TIME there’s was a minimum of 1-2 “Failed” connections to random API servers around the globe. That’s all the testing I need. IT is what I been doing for a living. I know how to test a network. Doesn’t matter if u agree with me or not, I have my own testing and experience tell me what I need to know. If there was a global OS issue, this forum would be filled with posts just like yours. Their pool and API servers are hosted on extremely low quality servers. It’s easy to see that.
“Just check your net stats, you won’t see a ping under 80ms from ANY server at any given time, usually it’s 300-3,000ms.”
That’s not necessarily true.
I just ping naw-eth-hiveon.net and this is what I am getting:
Check back again in a few minutes. The issue is intermittent and with different servers at any given time. Other posters have already stated this. Look at my example below. “Aaawave” is the name of the client, the rig, sent the ping in 2.2ms, the server took over 86ms to respond.
The data that I have doesn’t support your claims though.
Let assume that what you are saying is true.
So, then how do you explain where my average ping times is 20 ms vs. what you are seeing?
(I posted the screenshot from the ping test above. Statistics for that are as follows:
round-trip (ms) min/avg/max/med = 15/20/41/18)
(If you want me to run net stat and/or long duration ping tests, I can certainly do that. Not a problem.)
I don’t have your server or ISP skills, I am a small time miner.
I have a very tight “payout per days model” which has remained consistent. My payout results do not show a material deviation during the “stats blackouts” which would justify paying for HiveOS(maxed at 4) or transaction fees.
Full disclosure: I have “free” MMPOS rigs pointed at other pools to stay informed, tweak weak GPUs, and to be pointed at Hive pool to make up for my rig service outages on Hive pool rigs. My experience with some pools is definitely behind Hive on a per MH/s to net payout basis. I have not tried all the pools…yet 
Forgive my idiot question, but I don’t see, in the picture that you have attached, where it shows an 86 ms respond time.
It shows aaawave forwarded to unbound#5353 IP (2.3 ms).
I must not be looking at the right spot because I am unable to see the 86 ms reponse in the screenshot that has been provided.
Yes do that. Because several of us on this thread were testing extensively during and after the outage. You can get those ping times now, and in one hour the whole connection fails. Then switch to another server that seems good, and within a few hours those servers started lagging behind with 300+ms. We’re talking about pool and server ping times, if your issue isn’t that and your ping times are so great, open another thread and get the answers u need. Why r u here debating obviously bad ping times that everyone else is having
Because I compared it to the output on HiveShell net stat responses when I was doing my testing. Dude, just go somewhere. I been doing IT work since 1998, not debating networks or network testing with some random miner. If your issue isn’t bad connections, then u might have a corrupt file, or like I stated, intermittent loss of connection that made the file unreachable/unreadable. Either way it goes, this isn’t the thread for your issue if you’re so convinced it isn’t a network issue. In that case, open up a thread.
So…here is a screenshot that I just took now where I have kicked off pinging all seven of the HiveOn pool servers, simultaneously, with the command ping -c 100000 server where server comes from the list here:
(in the order that it appears)
And this is with the super simple command ping - nothing fancy.
I figure that if it can’t pass the ping test, then we can use more advanced tools like the stuff that you’re using.
(I’m also NOT that sophisticated. I’m a lot more “basic” or simpler than that. If it can’t pass a simple ping test, then it would be worthwhile to use more advanced testing, diagnostic, and troubleshooting tools. But if a simple ping test is already able to show some data/results (all of my pin times appears to be < 250 ms), then I don’t see really an need to overkill this with more advanced tools.)
I’ll repeat for the last time. The server response times are all over the place. One minute they’re good, one minute they’re bad. But your issue isn’t network related. So open up a thread for that and debate over there. More advanced tools? I’m not using tools. Unbound is a recursive resolver. Look it up. These “advanced tools” you speak of aren’t for testing, they’re for my everyday use and security of my home network. Your “Data” consists of one or two pings u have recently done on your behalf, how is this “data” relevant to your issue. U stated your issue isn’t network related, so what r u doing here?
“Dude, just go somewhere. I been doing IT work since 1998, not debating networks or network testing with some random miner.”
Again, the data that I can show and provide here does not conform to your statements.
Sorry that my data does not conform to your pre-determined world view/mental model of what you think is going on here.
Having a contradicting set of data sucks eh?
Since 1998 eh?
That’s cute.
I don’t remember when I started using Solaris, not that it really matters here.
For all of your testing, you can’t explain the sub-20 ms ping times that I am getting, which provides the data in support of the counter argument, which counters your claims.
You claim that the ping times are 300-3000 ms.
Yet, the data that I have clearly shows < 250 ms ping times.
Can’t you run something like a traceroute or something along those lines to figure out which “layer” is adding or causing your additional ping times?
I have no idea which server you were trying to ping, so I ended up just pinging all seven of them, simultaneously.
When the ping jobs complete, it’ll provide the statistics for the min/avg/max/mdev which will tell us more information.
Ok, you must have reading comprehension issues. This is MY FINDINGS when the pool and servers were completely out of wack. I can care less what your one or two pings of “data” say. There are dozens of other users here who confirmed my findings. Now, go open up a thread for your issue and have a good day. You’re trying to be smart and looking like a total fool. I don’t need to run trace routes. I RUN MY OWN RECURSIVE RESOLVER!!! . I will no longer respond to you cause I’m losing brain cells having this convo with you. You don’t have network issues? GREAT…but me and several other users here sure did! Goodbye. Have a good day.
EDIT: What’s cuter is the idea of you Googling what’s a Recursive Resolver. Now that’s cute.
“Unbound is a recursive resolver. Look it up.”
I did. It’s an application, which by any other name, is a tool. It something that helps you to something else.
"But your issue isn’t network related. So open up a thread for that and debate over there. "
I can’t rule a connection issue out yet. It can’t parse the json file, but when I start the system up, it works fine, and then it stops working. So I don’t know if the “can’t parse json” is really because it can’t connect to the server or if it is really because it can’t parse the json file. Hard to say at the moment.
"These “advanced tools” you speak of aren’t for testing, they’re for my everyday use and security of my home network. "
I never said that they were specifically nor ONLY for testing. You said that.
“Your “Data” consists of one or two pings u have recently done on your behalf, how is this “data” relevant to your issue.”
Your claim is “you won’t see a ping under 80ms from ANY server at any given time”.
The data shows that statement to be false.
In other words, your claim is that the ping times is 80-3000 ms.
The data shows that I can get 16 ms ping time and you can’t explain why your statement about “you won’t see a ping under 80ms from ANY server at any given time.”
I’ve categorically disproved that statement already.
It’s fun to watch how people react when they are presented with data that contradicts the claims and statements that they’re making.
Time for me to go make dinner.
You can enjoy your > 80 ms ping times whilst I enjoy my sub-20 ms ping times, in direct contradiction and contravention to your stated claims about how “you won’t see a ping under 80ms from ANY server at any given time.”
(I just did (see ping times under 80 ms from at least two of the servers). Welp…there goes your statement.)
Ping to naw-eth.hiveon.net is currently averaging around 16 ms.
Ping to eu-eth.hiveon.net is currently averaging around 78.7 ms.
GREAT. have a good day.
“Ok, you must have reading comprehension issues.”
Let’s test your hypothesis, shall we?
This is what you ACTUALLY wrote:
“you won’t see a ping under 80ms from ANY server at any given time”
“This is MY FINDINGS when the pool and servers were completely out of wack.”
You didn’t write:
“I can’t see a ping under 80ms from ANY server at any given time”
What you ACTUALLY wrote was:
“you won’t see a ping under 80ms from ANY server at any given time”
And yet, all I had to do to test your statement/theory/hypothesis was to run a simple, quick, dumb ping test and the data that resulted from that was able to provide the evidence that flies in the face of YOUR statement where you stated “YOU won’t see a ping under 80ms from ANY server at any given time”.
YOU didn’t write “I didn’t see a ping under 80ms from ANY server at any given time”.
Therefore; BOTH of your statements are false.
My reading comprehension (because you wrote “you won’t see”, not “I didn’t see”) is JUST fine, thank you very much.
LOL…if you’re going to blame others for YOUR faults, it would’ve probably behooved you to check how quickly and easily it would be for others to pinpoint and disprove your statement.
And whilst we’re at it, let’s clarify a few things:
- You wrote that you work in IT (since 1998) and that this is what you do and that you know how to conduct network testing.
And yet, all it took was for someone who DOESN’T work in IT, to run a simple ping command to provide the data and the evidence in this data-driven, evidence-based discussion that I am CLEARLY able to ping the HiveOn pool servers with LESS than 80ms ping times, a feat that according to you (who supposedly does this daily), cannot and should not have been able to happen.
Therefore; on the front of you saying that quote “you” “won’t see a ping under 80ms”, all I had to do was literally ping it and I can get < 80 ms ping times - a feat that you said I “won’t see a ping under 80ms” and yet I did.
When I asked you to explain how I was able to accomplish what you stated was something that I “won’t see”, instead of ACTUALLY looking at the data and being like “maybe you’re right. Huh. Apparently, you CAN see a ping time under 80ms”, you, instead, go on this whataboutism and deflection rant rather than actually providing an answer when the data CLEARLY shows that your statement is false/wrong/incorrect.
Instead of taking responsibility for your statement, you blame others instead.
CLEARLY, in 23 years of doing this, you STILL haven’t developed sufficient proficiency in your profession to take responsibility for your errata statements when you make them. No, instead, you blame others for YOUR mistakes.
- You drop your credentials (that you’ve been doing this kind of stuff since 1998) and you self-profess that you know what you’re doing, and yet, all I had to do was to run a simple
pingtest to disprove your statement and hypothesis.
Again, when asked “I’m getting a min of 16 ms and an average of 20 ms, how do you explain that?” - you NEVER explained how I was able to accomplish what you stated was something that I “won’t see (a ping under 80ms from ANY server).”
In other words, the credentials that you dropped LITERALLY proved how worthless they are by the fact that someone who doesn’t even work in IT, can run a simple command, and am able to clearly show data that contradicts your statement, for which, you have literally ZERO response in regards as to how I am able to see the data that you said that I won’t see.
Your credentials are worthless when someone who doesn’t even work in IT can run a simple ping command and so easily and readily disprove your statement.
It shows that it doesn’t matter that you’ve been doing this since 1998 and it doesn’t matter that this is what you do all day, every day.
If someone such as myself who DOESN’T do this every day, and who DOESN’T work in IT can just run ping and provide the data to disprove your statement, it literally shows that for this, I don’t need someone with your credentials because despite your credentials, you still haven’t and can’t explain why I am seeing what you said I won’t see.
- “Yes do that. Because several of us on this thread were testing extensively during and after the outage. You can get those ping times now, and in one hour the whole connection fails. Then switch to another server that seems good, and within a few hours those servers started lagging behind with 300+ms.”
I’ve ran the ping test now for over 18,000 seconds (5 hours and change) and you can see the statistics below:
TWO of the servers have an average ping time over 16705 packets and 18442 packets respectively where the average ping times is < 60 ms. NONE of the servers that were tested over the past 5 hours have an average ping time > 253 ms.
The standard deviation in some cases are quite high with respect to the mean, and when you take the max into consideration, the statistics tells us that there are some statistical outliers in the data, which increases the standard deviation, but otherwise, it’s possible that the data is within +/-10 to 20% about the mean.
But, here’s the thing (since you wrote about reading comprehension) - the statistical outliers WASN’T what you wrote about though.
What you ACTUALLY wrote was:
“you won’t see a ping under 80ms from ANY server at any given time”
(which I have already proven this statement is false and the data shows that and it’s a really simple question to you: You said “you won’t see a ping under 80ms. The data shows that the average ping time to two of the six of the servers as being < 80ms. According to you, I shouldn’t see that, but I am and I do. How come?” You have been asked to explain your statement of what you said I can’t see before already and so far, you have completely and utterly FAILED to provide ANY sort of explanation as to why I am able to see ping times less than what you said I won’t see. (Min ping time across any of the six servers, by the way, was 14.718 ms. According to you, I shouldn’t see a ping time < 80 ms and yet my min is quite a lot lower than what you said I should see for the min would/should be. How come?" The question about comprehension LITERALLY boils down to this and you have FAILED to provide an answer. You have done everything BUT provide an answer to that super simple question.)
- “Why r u here debating obviously bad ping times that everyone else is having”
Because your response is evidently crap.
You: “You won’t see a ping under 80ms”
Me: runs ping, see an average of 20 ms the first time (with a short run). Sees an minimum average of 25.743 ms on a 5 hour run of ping.
Me (asking you): According to you, ‘you won’t see a ping under 80ms’. How do you explain an average ping of 20 ms (from the first time that I asked you this question).
You: You have reading comprehension problems. “Why r u here debating obviously bad ping times that everyone else is having”
Me: Because your data is evidently crap. And so is your explanation. And despite your credentials and your profession (and your lack of professionalism), you have failed to be able to explain and account for what you said I won’t see.
If this is what you do, you clearly suck at your job so much so that someone who DOESN’T work in IT can run a simple test and is able to collect data that so clearly and evidently disproves your statement. And rather than taking responsibility for your statement, you instead, go on to blame others.
Your credentials are literally worthless given your lack of professionalism and the fact that even an idiot such as myself can just run a basic ping and show the results from that simple ping test that your statement about “you won’t see a ping under 80ms” as being categorically and empirically false.
And you just literally can’t deal with this data.
Rather than taking responsiblity for yourself, you instead, blame others.
Instead of being like “oh damn. Maybe you CAN see ping times under 80ms” and instead of asking “how did you manage to do that?” you instead, go on and bitch about my lack of reading comprehension (which, if you are going to bitch about being off topic or why am I here, you might ask yourself what in the world does reading comprehension have to do with ping tests?).
-
“There are dozens of other users here who confirmed my findings.”
So, you abide by confirmation bias. No wonder why you suck at your job (apparently). -
“You’re trying to be smart and looking like a total fool.”
BWAHAHAHA…
Says the person who’s like “I’ve been doing this since 1998. IT is what I do. I know how to run a network test.”
And yet, you can’t even run a simple ping test or answer why I am able to get < 80 ms ping times to at least TWO of the seven HiveOn servers.
The fact that you have to tell people your credentials as opposed to letting your credentials speak for themselves is the sign of a con man.
A con man has to try and convince other people that they know what they’re doing.
Someone who ACTUALLY knows what they’re doing NEVER has to tell other people that they know what they’re doing because their results will speak for themselves.
I have NEVER claimed to be smart.
YOU, however, claimed to have these credentials (of working in IT since 1998 and IT is what you do, and you know how to run network tests). And yet, literally, all it takes is an idiot such as myself to come by, run a basic ping test, post the screenshot from the console/command window, show that my min is 16 ms and my average is 20 ms respectively and ask you, point blank, “I thought you said that I won’t see this. So why I am seeing it (at all)? According to you, I won’t see it, and yet, here we are, seeing it. How come?”
You: silence
You LITERALLY have no answer to that.
This is how even an idiot such as myself am able to prove that you’re a con man.
I have never declared that I know what I am doing.
I have never declared that I am smart.
In fact, I am the biggest and the stupidest idiot that I know.
- “I don’t need to run trace routes. I RUN MY OWN RECURSIVE RESOLVER!!!”
And yet, you still can’t explain why I am seeing what you’ve said that I won’t be able to see.
Yeah…all the good THAT does for you.
Here’s a lesson for you kids: There is no point in running your own recursive resolver if you can’t answer SIMPLE, BASIC questions about your network and how data packet from one of your system is getting from your system to its intended destination.
If you can’t figure out where the additional latency is coming from, it is irrelevant and useless that you can’t identify nor troubleshoot the source of your latency problem.
If IT is what you do (since 1998) and you can’t run a basic traceroute to figure out where and why you are seeing/experiencing additional latencies, then your credentials are worthless if you can’t answer/perform BASIC, simple troubleshooting of your own network that even an idiot such as myself can perform in order to try and figure out where does the problem, on the surface, begin to manifest?
It such a simple troubleshooting/diagnostic test to run and yet you can’t even come up with SIMPLE troubleshooting suggestions of things to run like that in order to try and figure out where the problem lies.
" traceroute tracks the route packets taken from an IP network on their way to a given host. It utilizes the IP protocol’s time to live (TTL) field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to the host."
Therefore; the fact that you run a recursive resolver is wholly and entirely irrelevant here.
If IT is what you do, then I feel bad for any of the companies that hire you when your answer to the suggestion of running traceroute is “I don’t need to run trace routes. I RUN MY OWN RECURSIVE RESOLVER!!!”
Your problem is unlikely to be the result of your recursive domain name resolver. DNS is NOT the same as “tracks the route packets takes from an IP network on their way to a given host”.
For someone who claims that you’ve been doing IT since 1998, and your response to “run traceroute” is “I don’t need to run trace routes. I RUN MY OWN RECURSIVE RESOLVER!!!” - that’s clearly a stupid response.
- “I will no longer respond to you cause I’m losing brain cells having this convo with you.”
BWAHAHAHA…
It is clearly evident that you never had brain cells to begin with, so I’m sure that you’re not going to miss them as they sure as heck aren’t going to miss you. Can’t miss what you’ve never had before.
- "EDIT: What’s cuter is the idea of you Googling what’s a Recursive Resolver. Now that’s cute. "
Unlike you, I can admit when I don’t know something, which means that I am capable of growth and learning.
You can’t even explain something so simple as to why your minimum ping times are at least FIVE TIMES greater than my minimum ping times.
#epicfail
And I don’t even work in IT.
That’s just sad that someone who doesn’t even work in IT can out-IT someone who’s been working in IT for the past 23 years, with commands so simple that even an idiot such as myself can run (and produce data which clearly disproves your statement) LOL…
Your credentials are worthless.
Why would anybody want to or need to hire you if you can’t answer this BASIC type of question.
(ooh…this would make a really good interview question. You test the ping from your company’s systems and you get a minimum of 80 ms. Someone else pings the same IP destination and they see a minimum of 16 ms. How would you go about trying to figure out why the company’s minimum ping time is FIVE TIMES greater than the minimum ping time that someone else is able to produce? This would be an EXCELLENT interview question.)
(And as you’ve already demonstrated, you would have FAILED this interview question.)