[X] My Assistant

This is a small patch that makes various adjustments of H@H hath gain rates to make them better reflect the actual contribution the client makes to the network. If you don't run a H@H client, this patch will be completely uninteresting for you.

The base formula has been rebalanced to de-emphasize raw speed, make the cap linear with the number of files transferred, and add the client's number of static ranges as a factor. Note that since static ranges are now a fairly large factor, this means that disk space is more important than before. It also means that new clients will take longer to build a decent hath rate. And, if you're one of the few people who have yet to upgrade from the 1.0 branch, now is the time to do so.

For the base value, Hath is calculated from your client's speed, capped to 1 + 0.1x your average hits per minute.

For static ranges, an effective number of static ranges is computed as the actual number of static ranges capped to one per 2 KB/s. You gain 1 Hath for every 50 effective ranges, also capped to 1 + 0.1x your average hits per minute.

These numbers are added together, and caps to 20 like before. Overall, the average number of hath hasn't changed from before (+/- 5%), but it's been shifted somewhat towards higher-contributing clients and clients that have a large cache of files.

Additionally, the system now discourages throwing up several junk clients on the same server by reducing the base hath factor under certain conditions when there are several other clients on the same IP range. This reduction factor depends on the individual average number of hits for each client. If a client has a very low average number of hits, its rate will be adjusted so that all the clients combined will only gain slightly more than a single client with the same aggregate stats. For clients that serve a decent number of files, there is no reduction at all. Note that this won't be reflected on the H@H page, as it is computed dynamically by the control script.

Finally, the system now gives a 25% bonus to Asia-based clients, due to the lower coverage and relatively higher cost of hosting there.

If you don't run a H@H client, this patch will be completely uninteresting for you.

Awww (IMG:[invalid] style_emoticons/default/sad.gif)

Nice work nonetheless.

7-8 -> 10
3-4 ->2

10-11 -> 17

Thanks Tenbro!

And I'm only using ~39% of cache right now, so maybe I can hit 20 haths via static ranges. (IMG:[invalid] style_emoticons/default/wub.gif)

Awww (IMG:[invalid] style_emoticons/default/sad.gif)

Nice work nonetheless.

+1.

Sounds interesting when/if I finally give myself a kick in the butt and upgrade to an actual connection so that I can subscribe. Plenty of unused disk space for cache. Problem is connection speed and that might be solved soon. And here is extra motivation.

Even though I'm not using H@H right now, sounds like a good change. It probably won't discourage overall usage since (if I got that right) it rewards you for properly serving files more than it penalizes you for accidentally serving junk. Let's just wait for user feedback.

With image file sizes and the total size of the galleries tending to increase over time, the amount of bandwidth required to serve X hits per day and disk required to hold Y static ranges can be expected to increase. If that doesn't sufficiently match ongoing decreases in cost of bandwidth and disk space, would it be desirable to add an additional scaling factor to help stabilize the real-money to hath exchange rate? (IE, if hosting costs go down sharply over 6 months, the scaling factor increases so it costs about the same to produce the same number of hath per day)

That factor could be adjusted continually using some index of hosting cost and computed gallery statistics instead of needing to issue a patch every time to adjust the magic numbers.

This post has been edited by mechafujoshi: Aug 29 2014, 23:02

Valid point about image size increase over years, mechafujoshi. I stick to JPG75 (it's a trademark of mine as I have broken eyesight) on a small screen (well, not running 800x600, but almost that!) but people now use bigger monitors, absurd resolutions and tend to go with PNG format a lot more. (Oh the good old days of 2MB 500+ picture CG sets in 640x480 16-color GIF format.)

Maybe put total bandwidth usage (that isn't junk, for "rewards") into consideration as well?

wait, are you telling me there is a hard limit of 20hath per client no matter what?
I got it - so should I launch more clients on the same machine somehow now or what?

wait, are you telling me there is a hard limit of 20hath per client no matter what?

Well, it used to be 7, then it was 15, and now it's 20. Never been more than that, though.

Sounds like a good tweak to reflect actual contribution to the system.

Now if only my clients could accumulate static ranges faster.

My long running client is doing pretty much the same as before, but the newer one with only 34 ranges lost about 2 Hath/day.

I also notice it tends to use a lot more memory for cache buffers than my other server for some reason.

What governs how many hits a client will receive? It doesn't seem to be just a matter of upload speed, trust, and quality.

I've noticed that my VPS's don't get as many as a dedicated server although they have the same three parameters. Is it because they're limited in memory? I've noticed that java seems to automatically use very little memory when running on smaller systems. Not sure if that is actually affecting performance, even if the cache is on SSD.

What governs how many hits a client will receive? It doesn't seem to be just a matter of upload speed, trust, and quality.

I've noticed that my VPS's don't get as many as a dedicated server although they have the same three parameters. Is it because they're limited in memory? I've noticed that java seems to automatically use very little memory when running on smaller systems. Not sure if that is actually affecting performance, even if the cache is on SSD.

Location of your server and what galleries/files are in your cache can affect hits, i believe. A client with newer and more popular galleries would probably get more hits, as compared to a client with files from a couple of years back. For me, i also limit the max number of connections to my client, but i have no idea is if affects hits.

This post has been edited by Valkrey: Aug 30 2014, 04:14

Finally the hath price will rise again. Yay!

I only lost 1/h per day, not a problem (IMG:[invalid] style_emoticons/default/anime_cry.gif)

*various Hath generator control mechanism*

Controlling Hath supply by reducing Hath generation rate...? ...Way to go.
Now that's gonna squeeze my debt servicing... hopefully Hath's pricing goes up soon™ (IMG:[invalid] style_emoticons/default/cry.gif) (IMG:[invalid] style_emoticons/default/cry.gif) (IMG:[invalid] style_emoticons/default/cry.gif)

Additionally, the system now discourages throwing up several junk clients on the same server by reducing the base hath factor under certain conditions when there are several other clients on the same IP range. This reduction factor depends on the individual average number of hits for each client. If a client has a very low average number of hits, its rate will be adjusted so that all the clients combined will only gain slightly more than a single client with the same aggregate stats. For clients that serve a decent number of files, there is no reduction at all. Note that this won't be reflected on the H@H page, as it is computed dynamically by the control script.

Well, no more Hath inflation by hoarding IPv4 addresses at least... anyway, how many hits do both the client needs to have to bypass the reductions?

This post has been edited by LostLogia4: Aug 30 2014, 07:41

Controlling Hath supply by reducing Hath generation rate...? ...Way to go.

Not really.

Overall, the average number of hath hasn't changed from before (+/- 5%), but it's been shifted somewhat towards higher-contributing clients and clients that have a large cache of files.

Quality contributors get more, system abusers get less.

Not really.
Quality contributors get more, system abusers get less.

Oh, yeah, forgotten about that one. (IMG:[invalid] style_emoticons/default/tongue.gif)
You could also add that new clients gets less as well, because it takes awhile to get 100 static ranges.
And more importantly, is there any way to check the average hit rate?

This post has been edited by LostLogia4: Aug 30 2014, 07:41

And more importantly, is there any way to check the average hit rate?

You'll just have to watch how many files are sent over a period of time and divide them.