[X] My Assistant

This is a weird problem.

My H@H runs fine most of the time, but after an extended period of time running, like 80+hrs, suddenly my trust would plummet to the minuses and stay there until I restart the client.

The symptom seems to be endlessly searching for files to prune and prune 0 files.

I've already verify_cache.

This post has been edited by ChosenUno: Jan 10 2013, 17:20

I've been experiencing similar trust fluctuations over the past few weeks. Just a couple of days ago my trust dropped from around +950 to negative within a few hours. Reinstalled the JVM, switched from Oracle's JVM to the OpenJDK runtime, didn't help. Reverted to H@H v1.0.9 which reduced the worst of it. My trust is back up over 900 but it still drops sharply every few minutes.

The symptom seems to be endlessly searching for files to prune and prune 0 files.

I suck at Java, yet from the H@H code I can see that it is not a symptom, that's normal behaviour. Every 15 time ticks H@H will try to prune files and print: "Checking for old files to prune...", "Pruned " + pruneCount + " files.". If the H@H is doing nothing the 15 time ticks will pass quickly and the log will get full of these messages, whilst no other log messages are printed in between. The issue is that for H@H to do nothing it must be not receiving requests. And if the trust is going down on the e-hentai.org side it means that hentaiathome.org tries to contact the H@H with requests (and fails). Therefore, we have a connectivity issue.

e.g.
I had a similar problem when I started running H@H. In the end it turned out that my shitty router decided to reboot the DHCP server every 2 days and reassign all the IP's completelly ignoring the DHCP table of preassigned IPs. I just killed the DHCP server altogether and gave everyone a static IP.

I know it's not my router because I'm not using one. My H@H computer has a mostly unrestricted uplink and it's been solid for many months up until whenever this started, and then the whole thing fell to pieces for me over the weekend.

What I see in my logs are messages like these:

[459628.025010] TCP: Peer 94.99.95.190:63049/2501 unexpectedly shrunk window 833677845:833680749 (repaired)

They're all on port 2501 so it's definitely my H@H listener. The number of these per peer range from 5-6 to 15-20. They're typically spread apart by few seconds. There aren't nearly enough of them to be a denial of service attack -- dozens, not tens of thousands. These go back at least as far as 18 Feb. Maybe further but my system logs don't go back further than that.

There appears to be a correlation between when these occur and when my trust plummets. The 94.99.95.190 event occurred about 2 hours ago. A few minutes before that my trust was around 950. It's down to under 750 after having spent the past two hours climbing from whatever low it hit.

Any suggestions for dealing with these?

[459628.025010] TCP: Peer 94.99.95.190:63049/2501 unexpectedly shrunk window 833677845:833680749 (repaired)

It is not really much info, but we can check a few things:

Is that output from tcpdump? If so which flags do you use?
The host hentaiathome.net does resolve to 94.99.95.190 from your machine?

PS: If the trust just drops about 200 points and then starts going up again then that's normal, it's just a lack of syncronisation that sometimes happen (there was a more technical explanation somewhere around the forums, but I forgot where). I believe that the issue you have is that the trust, when drops, can reach negative numbers, yup?

Not tcpdump. That's what's the kernel puts into syslog and the dmesg log. None of the IPs that I've checked resolve to H@H servers known to me. I'm getting my DNS from Google so I'm reasonably confident that the host name lookups are accurate. traceroutes don't show any obvious correlation between source IPs -- the most recent events were from Arabia and Australia. These are either legitimate e-hentai users or illegitimate e-hentai abusers. I'm currently not sure which it is. Like I wrote before, this does not appear to be a denial of service attack.

What I suspect at this point is if enough of these events occur over several hours then the trust drops faster than it recovers. This plunges me into negatives.

I'm going to up my burst speed limit and see if that helps at all on recovery times.

Did you (or your package manager) update the kernel and/or the network drivers/modules recently?

Yes. Of course it did. That's the point of installing security updates.

The behavior that I'm seeing is not consistent with a general kernel or driver issue. I'd expect to see either more errors or more variety of errors (the node is doing more than just running the H@H server). These are very intermittent, unpredictable to the best of my ability to determine, and exclusively on the H@H listener. The IPs appear to be for actual e-hentai users. IPs that I see in my system logs are also in my log_out files and have successfully retrieved files from my cache.

Bumping my burst limit from 1.5MB/s to 10MB/s has not appreciably helped so far.

I'm going to put v1.0.10 back in, see what happens.

Edit: also just bumped the cache from 30GB to 80GB to hopefully actually use that bandwidth.

Edit 2: there is something BADLY broken in regards to version 1.0.10. My trust is dropping in bursts faster than it rises even without any network errors. Going back to 1.0.9 for now.

This post has been edited by colossol: Mar 6 2013, 18:42

At this time I can rule out the TCP peer window resize. I'm still seeing massive trust drops without any errors being reported.

I for one can say that this has also happened to me also. i have checked over the logs to see when or what interrupts occurred but can't find any large scale drops that would bring me to +300 or less! flipping weird lol

Confirmed to happen today, i had my normal internet speed and a random hath plummet to -89, when only just an hour ago it was at +985 after recovering from a system crash.

And again some time today. +1000 this morning. +250 now.

I am having a similar issue. I have no connection errors, or system failures, but my trust will drop randomly below positive integers making my average speed/sec very low. I have always maintained high trust up until recently. Now trust rarely exceeds 600. I can safely say it has nothing to do with anything on my end as nothing has changed with my system or my router. It has become a bit frustrating to say the least.

Update: Even as I wrote this post, my trust went down 250 points...with little to no change in connection speed.

This post has been edited by choostrawn: Mar 10 2013, 14:13

I am having a similar issue. I have no connection errors, or system failures, but my trust will drop randomly below positive integers making my average speed/sec very low. I have always maintained high trust up until recently. Now trust rarely exceeds 600. I can safely say it has nothing to do with anything on my end as nothing has changed with my system or my router. It has become a bit frustrating to say the least.

I had the chance to look at your specific testlog (they aren't stored very long), and in your case at least, the drop didn't seem to be caused by your client, but by some other clients that weren't doing a very good job as testers. I've made some system improvements to prevent this automatically in the future, but it'll take about a day and a half before we'll see the real effects from this change.

I've made some system improvements to prevent this automatically in the future, but it'll take about a day and a half before we'll see the real effects from this change.

It appears that this plus the trust/quality changes have had the desired effect. My H@H client has been solid (it seems) at +1000 since yesterday. Bad testers. No biscuit.

I'm also having a problem with my trust/quality going to crap suddenly.
The client will run for several hours, getting up to 700-800 trust and building a cache, then it
suddenly and instantly drop to -100. If I let it continue to run even after dropping to -100,
it'll move towards 0 trust and maybe get back to a very low positive number (less than 100)
before it happens again. The client has to be restarted to fix this. It's been doing this since
the beginning on the PC I'm trying to run it on.

I don't know if it matters but, I've used the client successfully on my main PC before in the
past and never had a problem, but recently I decided to run it on a different machine because I
can't keep this one running all the time without restarting. The PC I'm running it on
is...pretty old. 1.80 GHz processing speed with a single GB of RAM (no idea why anyone would
have only 1 GB on Vista..), though no other applications are running other than Windows
services. I was thinking it could be because of too low specs but, after a fresh restart it runs
well for 8-10 hours, then breaks down and stays that way. I'm not really sure what to do.

Vista..), though no other applications are running other than Windows services

If you're not actually using the computer for anything else, might I suggest some flavor of Linux? A minimum CLI-only install of a server distro like CentOS barely uses any RAM at all.

Regardless, if you're running the GUI version of H@H, you should probably try the CLI one, it takes up quite a bit less resources.

Regardless, if you're running the GUI version of H@H, you should probably try the CLI one, it takes up quite a bit less resources.

I'm running 64-bit Debian with 30GB cache and 1500KB/s. The Java CLI process has claimed ~3GB of virtual address space which isn't in active use (zero si/so). Resident size is a mere 112MB.

The Java CLI process has claimed ~3GB of virtual address space which isn't in active use (zero si/so).

That's not unusual for Java, shouldn't be a problem unless you're on a VPS that limits by virtual memory size.

Still having this problem, been running the CLI (I don't even know how to close it come to think of it) for days now and the trust still never recovers unless I restart (in which case it'll just crash again in 8 hours).

Is hardware really the issue here? It is a bit of a crappy PC..it's unfortunate but I guess I'll have to move the client back onto my main machine which I don't leave on all the time.