C200 crashes at high speed downloads.

[JasC]

Hi guys,

I am using the pch200 quite often for downloading torrents and nzb files.

The problem I am facing for months already (basicly since I got my pchc200) is that my PCH-C200 will crash when downloading at high speed.

I have been searching this forum and found a thread of people reporting the same issue, I just don't know if there is a fix already for this? Or maybe some kind of app?

I use the 'normal' standard programs which came with the pch200 to download nzb's and torrents (nzbget and for torrents to program which uses this url http://ipadres:8883/torrent/bt.cgi ). When I restrict my downloads to 750kb/s and upload to 750/kb/s I won't crash.

My connection is 120mbit.

Hope anyone can clarify something here

[DathRarhek]

Known problem. Known fix.

What versions of the torrent downloader and nzb downloader are you using? Most newer versions of the custom usenet and torrent apps execute this:

Code:

    echo 524288 > /proc/sys/net/core/rmem_default
    echo 524288 > /proc/sys/net/core/rmem_max
    echo "16384 87380 87380" > /proc/sys/net/ipv4/tcp_rmem

You can also execute that manually via telnet. Required on each boot.

[JasC]

Thanks for reply.

I am using NZBGet version 0.6.0 and torrent downloader version I can't see anywhere

Other details are:

Firmware version: 03-04-110530-21-POP-408-000
Kernel version: 21-POP
NMT Version: 03-04-110520-21-POP-408

Which pops up another question, does a firmware update (if available) fix this? And when I update my firmware and nmt apps, do i lose my data? All my apps are installed on same disc as all my files (internal 2tb drive)

Every time my system reboots I need to execute those commands you mean? Do you maybe have tips on which apps I could use to replace my current torrent downloader/nzb downloader?

I never used telnet actually, what to do? Can you maybe type in the commands here?

I guess I have to open the telnet port first (believe its port 23?)

Sorry for all the questions, I really want to get this fixed

---

I just opened the port and connected via o ipadres 23

sh-3.00# is what I see.. now what to do? Looks like unix commands work here, have some experience with that, but not much.

If this can be fixed simpler, by means of updating something then that might a better idea i think

---

Update:

I just installed latest version of transmission, v2.42, will this fix the crashing when downloading high speed torrents?

I will also download the latest nzb get, v0.8 i believe.

[DathRarhek]

No, no firmware update will fix this. It's not present in the latest firmware.

Having installed Transmission-2.42 should fix it. The commands are then executed when Transmission is started. Not only for torrent downloads but for all high speed transfers.

You can double check whether the commands are executed by typing this at the telnet command line:

Code:

cat /proc/sys/net/ipv4/tcp_rmem

You should see the values I listed in the other commands. You can also double check the other parameters by catting those.

Of course the real check is actually performing a high speed download. I'm unfortunately no longer on my 100mbit connection but rather have a poormans 10mbit connection, so I have no experience with the crashing.

[Cherek]

Besides that, the PCH isn't designed as a high speed downloading machine. It's a know fact that high speed downloading can cause stability issues.
My nzbget is currently topped to 2850KB eventhoug 3200KB is possible. Better safe than sorry.

[JasC]

Don't think it is working, got 2 crashed already

Yea I guess I should limit my PCH to a certain download/upload speed.

Or I should get myself a synology NAS.

[Disney]

I'm having the same problem with nzbget. Unit (C200) freezes if I download at 2000+ KB/s.

I have transmission 2.42 and nzbget 0.8 installed through CSI.

After startup when both are running my /proc/sys/net/ipv4/tcp_rmem values are 16384 87380 1040384.

If I manually stop and start Transmission the values are 16384 87380 87380.

I seems that the values are changed after Transmission is started but I haven't found out by which process... I have manually stopped and started all NMT applications, but none of them change the values to 16384 87380 1040384 after starting.

Anyone have an idea about where the values are changed after starting Transmission and on how I can assure the correct values are used automatically after reboot/startup?

[DathRarhek]

(01-19-2012 08:55 PM)Disney Wrote:  I'm having the same problem with nzbget. Unit (C200) freezes if I download at 2000+ KB/s.

I have transmission 2.42 and nzbget 0.8 installed through CSI.

After startup when both are running my /proc/sys/net/ipv4/tcp_rmem values are 16384 87380 1040384.

If I manually stop and start Transmission the values are 16384 87380 87380.

I seems that the values are changed after Transmission is started but I haven't found out by which process... I have manually stopped and started all NMT applications, but none of them change the values to 16384 87380 1040384 after starting.

Anyone have an idea about where the values are changed after starting Transmission and on how I can assure the correct values are used automatically after reboot/startup?

Hmm.. that's interesting behaviour that I can confirm also happening here. The commands are executed by Apps/Transmission/daemon.sh. Something during boot is either overwriting those values again, or the commands can't be executed. Maybe /proc isn't mounted at that point (likely), or the echo command isn't available (unlikely). I'll try to investigate this.

@JasC
Can you confirm this also being the case for you? And do the crashes disappear if the receive buffer is set lower? I think that's been confirmed a few times, so I was already surprised this wasn't working for you.

[JasC]

Will check it out tomorrow, and post findings here.

---

Ok checked it out quickly, didnt feel like waiting I can also confirm this behaviour! The crashes/freezes are gone when i limit my download speed, as Disney also posted!

[DathRarhek]

@JasC
I would also be interested if the crashes are gone at high speed but with the receive buffer limited.

Can someone with the LTU package check if they have the same thing happening?

After checking the value of tcp_rmem during boot constantly it seems it set correctly for a short while but then reset again. I figured out that /etc/init.d/S07network call to "ipmonitor reset" is probably resetting it. As far as I know ipmonitor is syabas program, so I'm not sure how to go from here.

I haven't delved to deep in how the Apps startup mechanism works, but if we can somehow assure that the startup of Apps is after S07network finishes then we're good.

[JasC]

(01-21-2012 11:08 AM)DathRarhek Wrote:  @JasC
I would also be interested if the crashes are gone at high speed but with the receive buffer limited.

Can someone with the LTU package check if they have the same thing happening?

After checking the value of tcp_rmem during boot constantly it seems it set correctly for a short while but then reset again. I figured out that /etc/init.d/S07network call to "ipmonitor reset" is probably resetting it. As far as I know ipmonitor is syabas program, so I'm not sure how to go from here.

I haven't delved to deep in how the Apps startup mechanism works, but if we can somehow assure that the startup of Apps is after S07network finishes then we're good.

What do you mean with receive buffer? Low upload or limited amount of torrents?

[DathRarhek]

(01-21-2012 12:12 PM)JasC Wrote:  What do you mean with receive buffer? Low upload or limited amount of torrents?

Sorry.. tcp receive window I mean. You do this by the commands I've posted before:

Code:

echo 524288 > /proc/sys/net/core/rmem_default
    echo 524288 > /proc/sys/net/core/rmem_max
    echo "16384 87380 87380" > /proc/sys/net/ipv4/tcp_rmem

Just execute these through telnet. You can check whether the values (before you set them) are wrong by executing:

Code:

cat /proc/sys/net/ipv4/tcp_rmem

Change to the other paths to check the values of those parameters.

[JasC]

When I connect with telnet and first do this command:

cat /proc/sys/net/ipv4/tcp_rmem

I get: 16384 87380 1040384

(this is ofcourse with all apps running with latest version)

Then I did:

echo 524288 > /proc/sys/net/core/rmem_default
echo 524288 > /proc/sys/net/core/rmem_max
echo "16384 87380 87380" > /proc/sys/net/ipv4/tcp_rmem

And afterwards did cat /proc/sys/net/ipv4/tcp_rmem

with this as result:

16384 87380 87380

I will now start downloading some large torrent file with transmission to see what happens.

[JasC]

Still downloading at unlimited speed without crashes here..

[Disney]

(01-21-2012 11:08 AM)DathRarhek Wrote:  @JasC
I would also be interested if the crashes are gone at high speed but with the receive buffer limited.

Can someone with the LTU package check if they have the same thing happening?

After checking the value of tcp_rmem during boot constantly it seems it set correctly for a short while but then reset again. I figured out that /etc/init.d/S07network call to "ipmonitor reset" is probably resetting it. As far as I know ipmonitor is syabas program, so I'm not sure how to go from here.

I haven't delved to deep in how the Apps startup mechanism works, but if we can somehow assure that the startup of Apps is after S07network finishes then we're good.

Ok, so I started a usenet download with all apps running and manually setting /proc/sys/net/ipv4/tcp_rmem. While monitoring the value during download the values change back to 16384 87380 1040384 after about 20 minutes...

I reset the value and will monitor again.

update: this time the values were reset after 20-25 minutes. I'm just letting it run now waiting for the freeze...