[X] My Assistant

A new Quality metric was added to Hentai@Home. This is basically a value between 0 and 10000 that measures the long-term overall stability and reliability of a client, and is now used together with raw speed and proximity to prioritize clients for file requests.

There is a readout for this on the Hentai@Home status page. New clients and clients that haven't been used for the last couple of days will start out with 0 quality, and it will take several days for it to stabilize at the baseline value.

Note that while 10000 could be read as "no issues whatsoever" and 0 could be read as "ass", what constitutes a decent quality rating could vary between parts of the world. This will have no overall effect on usage, as the system will still always prioritize clients within the same country or region.

Addendum: Due to browser blocking issues, the following ports are no longer considered valid for H@H use: 2049, 3659, 4045, 6000, 6665, 6666, 6667, 6668, 6669 and 65535.

Addendum #2: Fixed a bug where the quality wouldn't get properly reinitialized after a client restart.

Addendum #3: Added some improvements to how clients that fail other clients unreasonably often are handled.

So the Quality doesn't affect a server's base Hath/day (determined by upload speed), only it's Hath/click/day?

EDIT:
I mean...Average clicks per day, that's a parameter for overall Hath/day, I suppose.

And what will happen to quality if the H@H client is offline.

This post has been edited by penuser0: Mar 9 2013, 11:11

Now there is a long string of decimals for trust, I wonder if it should be rounded up.

(IMG:[i48.tinypic.com] http://i48.tinypic.com/3468eo8.png)

Now there is a long string of decimals for trust, I wonder if it should be rounded up.

Are you saying you don't need to know the Trust with 14 digits of precision? :3

(fixed)

Does clicking on the not-loading link for clients using [src.chromium.org] a [www-archive.mozilla.org] blacklisted [bugs.webkit.org] port have any effect on quality? Or just trust? (Or both?!)

Does clicking on the not-loading link for clients using [src.chromium.org] a [www-archive.mozilla.org] blacklisted [bugs.webkit.org] port have any effect on quality? Or just trust? (Or both?!)

Clients can only use port 80 and 1024-65535, but I wasn't aware that some high ports were also being blocked by some browsers, so I've added exceptions for those as well.

Neat, that was quick. Guess that question doesn't need to be answered now (IMG:[invalid] style_emoticons/default/tongue.gif)

Not in the pages I linked: 65535 is blocked in Webkit (Chrome/Safari), but not Firefox.

Not in the pages I linked: 65535 is blocked in Webkit (Chrome/Safari), but not Firefox.

Really? Hm..

Error 312 (net::ERR_UNSAFE_PORT): Unknown error.

Yup. Why would they do that?

Cool. Now I can tell better if a VPS is rubbish and needs to be killed (IMG:[invalid] style_emoticons/default/happy.gif)

That gives us, common "Discussion, Help & Feedback" posters, another evaluation value to undersatnd what newbies starting with H@H are actually doing. Good grief.

Also, that:

Cool. Now I can tell better if a VPS is rubbish and needs to be killed

Not for Itchy (IMG:[invalid] style_emoticons/default/smile.gif) but for the newbies again.

Um, does this mean that I will receive a quality drop if I don't use my pc for most of the day?

Addendum #2: Fixed a bug where the quality wouldn't get properly reinitialized after a client restart.

So it means whenever a client is restarted, the quality resets to 0?

Hopefully this resolves -- or helps alleviate -- the sudden, massive trust drops that some of us have been experiencing.

Hopefully this resolves -- or helps alleviate -- the sudden, massive trust drops that some of us have been experiencing.

No out of ordinary Trust drops for me.

So it means whenever a client is restarted, the quality resets to 0?

The fix was to make it not reset. As was intended. Considering it takes several days to settle, not having it save over restarts would be a major issue.

Hopefully this resolves -- or helps alleviate -- the sudden, massive trust drops that some of us have been experiencing.

Those are more than likely due to temporary network issues on your or your ISP's end. Hell, my ISP has several very short partial routing outages every day, usually lasting less than half a minute. If I wasn't running realtime monitors I would hardly notice, but it's enough for Trust to take a hit.

Can we know how this new metric is computed please ?

My client's trust is almost always equal to +1000, yet its quality measure dropped bellow 6000 this night, and the number of hits/s it gets dropped consequently. Even though its "quality" is slowly raising since then, its number of hits/s is stuck to 10 hits/s, while it used to handle 25 hits/s before yesterday.


(On a side note, the "Continue Without Uploading" button of the images upload form doesn't seem to work anymore.)

This post has been edited by Hairs Fan: Mar 10 2013, 16:14

Can we know how this new metric is computed please ? My client's trust is almost always equal to +1000, yet its quality measure dropped bellow 6000 this night, and the number of hits/s it gets dropped consequently.

Quality is calculated by comparing your average failure rate with your average hit rate - meaning it's largely independent of raw speed - together with some additional conditions if trust is low. This gets averaged over a long period of time, with the actual fractional gain or loss depending on whether the current quality is higher or lower than the averaged quality. (Basically, you drop quality much faster than you gain it, to avoid an oscillating load effect.)

~6000 is slightly lower than the average quality (currently ~6800), which means you probably had a period of many files being dropped. If there weren't any network interruptions, the client probably had a period of being overloaded in some way.

Quality is calculated by comparing your average failure rate with your average hit rate - meaning it's largely independent of raw speed - together with some additional conditions if trust is low. This gets averaged over a long period of time, with the actual fractional gain or loss depending on whether the current quality is higher or lower than the averaged quality. (Basically, you drop quality much faster than you gain it, to avoid an oscillating load effect.)

~6000 is slightly lower than the average quality (currently ~6800), which means you probably had a period of many files being dropped. If there weren't any network interruptions, the client probably had a period of being overloaded in some way.

Would having a client running at a pc with low priority traffic out of all the PCs in a network cause stuff like that?

This post has been edited by Bunker Buster: Mar 10 2013, 18:41

Would having a client running at a pc with low priority traffic out of all the PCs in a network cause stuff like that?

Possibly, if the network is overloaded. But assuming it's just using QoS to prevent bursts from causing slowdowns, it shouldn't really affect it.

Hi there!

@Hairs Fan: Where can I get these fancy graphs? I need moar stats (IMG:[invalid] style_emoticons/default/smile.gif)

@Tenboro: Thanks for the new quality measurement! YaY moar stats (IMG:[invalid] style_emoticons/default/biggrin.gif)

There is a small thing I was asking myself for some time though:
While watching my H@H client I notice that files sometimes take more than 5 or in rare cases even 10 seconds to get transmitted with speeds like 20kB/s. My burst speed is set to 95 kB/s atm. Can the connection limit be decreased (or is this (convenience) problem not even caused by my side)? Because I would as sure as hell not want to wait this long for an image to load.