[X] My Assistant

There's no readout for overloads, no, but it hasn't been. Your range count is at 6000, which is indeed the cap.

The "session files served" counter resets if the internal HTTP server restarts due to a cert refresh, which happens every three months or so.

Whoops, I meant higher priority ranges stopped increasing - I edited that in a little late. Maybe I'm paying too much attention to it since my hitrate still hasn't recovered. (IMG:[invalid] style_emoticons/default/unsure.gif)

Good to know about the counter reset, never noticed it before.

Whoops, I meant higher priority ranges stopped increasing - I edited that in a little late. Maybe I'm paying too much attention to it since my hitrate still hasn't recovered. (IMG:[invalid] style_emoticons/default/unsure.gif)

There's no hard cap on priority ranges, in theory all your ranges could be P1. Unlikely for a large cache, but common for a fast VPS with a small cache. Your client's share of the ranges just depends on your client's score vs the score of the other clients in the same region.

Note that we've switched to a new way of tracking and tallying the traffic for H@H. As such, you may see a change in the hitrate readout. Generally the difference should be less than 10%, though there may be some outlier nodes.

The main goal with the new tracking was to increase the reliability of honoring the monthly bandwidth cap, and this should now be reliable even in cases where the client's average traffic increases quickly. Though you'll still want to keep an eye on it, just in case.

We will also soon start dropping clients after three months of inactivity. Clients that have been inactive for more than three months have a mostly stale cache, and basically have to start over anyway.

I have client 45734, which is set to a max upload speed of 10000kb/s,
but I've noticed that it is only maxing out at 4194kb/s and the Hitrate has dropped dramatically.
This state has been going on for a week, is this normal?

After some more time, it looked like it was getting worse instead of better
(IMG:[s2.loli.net] https://s2.loli.net/2023/10/08/xpEga7FiV8OC5BM.png)(IMG:[s2.loli.net] https://s2.loli.net/2023/10/08/7oETqR1aZMchWzN.png)

After some more time, it looked like it was getting worse instead of better

That just means it had another overload. There's really no way for me to tell exactly why your client is overloading, but it's generally caused by hardware issues or network congestion, so you'll need to verify that H@H has enough resources and that your connection isn't flaky.

(IMG:[s2.loli.net] https://s2.loli.net/2023/10/08/xpEga7FiV8OC5BM.png)

Wow, that hitrate, and here I thought my 81.9 was high(Europe). China is insane!

Wow, that hitrate, and here I thought my 81.9 was high(Europe). China is insane!

Since China has a lot of users and crawler programs, the demand is high. But again, hathrate is high because of GFW. (hathrate was high throughout Asia before the China region was carved out separately) (IMG:[invalid] style_emoticons/default/biggrin.gif)

--------
I restarted my server and changed the cables, now I don't know what will happen to it. If it still overloads then just let it be，I am not a qualified server ops (IMG:[invalid] style_emoticons/default/anime_cry.gif)

After some more time, it looked like it was getting worse instead of better
(IMG:[s2.loli.net] https://s2.loli.net/2023/10/08/xpEga7FiV8OC5BM.png)(IMG:[s2.loli.net] https://s2.loli.net/2023/10/08/7oETqR1aZMchWzN.png)

Im causing these overload problem too when I've back from away.
I use a bare metal machine (HP 400 Gen 1 DM, i3 4170, 8GB RAM, 960GB SSD, China Mobile Static IP Network capped to Fast Ethernet) to run h@h, the CPU usage of Java is always like under 5%. So I can surely confirm the overload thing is likely a network issue.

I restarted my server and changed the cables, now I don't know what will happen to it. If it still overloads then just let it be，I am not a qualified server ops (IMG:[invalid] style_emoticons/default/anime_cry.gif)

One thing I'm often seeing with the Chinese clients is that the overload happens at the exact same time of day, so it's probably some sort of daily/weekly network reset, and nothing wrong with the actual clients. I'm currently reworking the whole H@H backend, and an overload rework will be a part of that - this will probably happen in the next few days. The reworked version should better handle these types of events.

Im causing these overload problem too when I've back from away.
I use a bare metal machine (HP 400 Gen 1 DM, i3 4170, 8GB RAM, 960GB SSD, China Mobile Static IP Network capped to Fast Ethernet) to run h@h, the CPU usage of Java is always like under 5%. So I can surely confirm the overload thing is likely a network issue.

I'm not seeing any overloads on your client though.

One thing I'm often seeing with the Chinese clients is that the overload happens at the exact same time of day, so it's probably some sort of daily/weekly network reset, and nothing wrong with the actual clients. I'm currently reworking the whole H@H backend, and an overload rework will be a part of that - this will probably happen in the next few days. The reworked version should better handle these types of events.
I'm not seeing any overloads on your client though.

(IMG:[s2.loli.net] https://s2.loli.net/2023/10/09/dQzNsA48iZaI7nE.png)
OH, it looks like it has recovered, that's great news. (IMG:[invalid] style_emoticons/default/biggrin.gif)

--------
By the way, my hardware configuration is B75 motherboard + I5 3450 + 8G RAM (4+4) + 128G SSD + 1TB HDD (h@h's data is in the HDD) CPU usage with client-side speed limit on is only 5% (at 1.6GHz). This is a computer built specifically for h@h, all used hardware only. (IMG:[invalid] style_emoticons/default/ohmy.gif)
Maybe the overload is due to my cute kitten chewing on the SATA cable ((IMG:[invalid] style_emoticons/default/biggrin.gif)).



Translated with DeepL.

I'm not seeing any overloads on your client though.

but theres often some strange drop from the speed meter i see on h@h client.
It happens suddenly (from 80~100mbps drop to ~40mbps suddenly, and it happens on peak period like Sep 30 12~1PM GMT). I think thats not a upload restrict/overload issue now, Is that happens caused by static ranges priority?

This post has been edited by wakaba4465: Oct 9 2023, 12:47

but theres often some strange drop from the speed meter i see on h@h client.
It happens suddenly (from 80~100mbps drop to ~40mbps suddenly, and it happens on peak period like Sep 30 12~1PM GMT). I think thats not a upload restrict/overload issue now, Is that happens caused by static ranges priority?

It probably happens whenever Cloudflare thinks EHViewer and similar apps are a DDoS attack, which it does occasionally.

It probably happens whenever Cloudflare thinks EHViewer and similar apps are a DDoS attack, which it does occasionally.

(IMG:[s2.loli.net] https://s2.loli.net/2023/10/09/oc1TOaumYL2tHvp.jpg)
have no idea why my client keep receiveing bunch of timeout while network is stable(atleast result from pingpe is stable)

have no idea why my client keep receiveing bunch of timeout while network is stable(atleast result from pingpe is stable)

Hard to say, it's not obvious from those logs what it's trying to download. Could be that it's trying to test another client that is down/unresponsive, in which case there wouldn't be anything wrong with yours.

Hard to say, it's not obvious from those logs what it's trying to download. Could be that it's trying to test another client that is down/unresponsive, in which case there wouldn't be anything wrong with yours.

but my client quality keep decreasing while a lot of timeout and connection refuse...
hope your next h@h client update can provide more context about network related stuff

auguhhhhhhh

(IMG:[s2.loli.net] https://s2.loli.net/2023/10/09/MBVyjLzdWaUvpQZ.jpg)
(IMG:[s2.loli.net] https://s2.loli.net/2023/10/09/sDv9zyxET8BuoLK.jpg)


service port also unstable(while icmp ping has no issue)
(IMG:[s2.loli.net] https://s2.loli.net/2023/10/09/4rQRCyShcuKTVto.jpg)
(IMG:[s2.loli.net] https://s2.loli.net/2023/10/09/4OVbMElFxeJvWCI.jpg)

This post has been edited by ttp...: Oct 9 2023, 17:55

but my client quality keep decreasing while a lot of timeout and connection refuse...
hope your next h@h client update can provide more context about network related stuff

auguhhhhhhh

service port also unstable(while icmp ping has no issue)

Not seeing any issues on our end or with H@H itself, but I think there may be some internet backbone issues going on somewhere, since there has been a pretty significant drop in average quality for Asia in general.

H@H already provides all available network troubleshooting information in the debug logs, but by its nature it's limited to stuff like "could not connect" or "the download timed out", and it's impossible for H@H to know in general *why* those things are happening.

With the new rule,
faster upload speed does not mean more hathrate anymore?

With the new rule,
faster upload speed does not mean more hathrate anymore?

It should still give you a higher score for range promotions/assignments, which generally leads to more high-priority ranges = more traffic = more hath, assuming your client can handle it. Although you won't see an immediate effect if you just bumped it up recently.

Note that if your tested speed is lower than 30000 KB/s, that might directly affect (reduce) your hathrate:

CODE

Hathrate/day = 1 + 0.15 * hitrate + 0.01 * static_ranges * min(1, low_quality_factor)

Note that static_range is capped by the client's tested speed. The cap is set at tested_speed/5 (in KB/s). Example: For a client with 6000 static ranges assigned, but only 10000 KB/s tested speed, its static_range for hathrate purposes will only be at 2000.

https://ehwiki.org/wiki/Hentai@Home#Rewards

P1 = 44, P2 = 54, P3 = 101, P4 = 127, P5 = 2694

If P5 remains hugely superior to the rest, is it the sign it would be more efficient to decrease storage allocated to H@H?