Hello!

I am running Slackware64 14.1 on a dedicated server that I lease each month. Up until December 28th, everything was great and had been since I started using it about 2 years ago.

I went to reboot the server and upon rebooting, things seemed to have changed in download speeds. I have tried doing a traceroute to the server from various locations(U.K., Kansas City, MO, USA, My Home(USA)) and everything comes out ok. I checked the logs, nothing seems to have changed anywhere. When I do a speed test out of the server, I get fantastic speeds (500 Mbps up and down), when I update the server with Slackpkg, I get decents speeds (2 Mbps), when I redownloaded the Slackware Torrents, I get 200-300 Mbps...but when I try to use SCP, SFTP or just download files through a browser, I am lucky if I get 4 Mbps. I used to get up to two or three files downloading at once through SFTP or SCP at 200 Mbps without a problem.

I also copy files to a service via WEBDAV, and I get great speeds to it (60Mbps), but now it seems there are errors. It never completes sending the file. It'll send 500 MB, then restart, send 400MB, then restart, send 600MB, then restart...it'll do that 15 times before it gives up sending it.

I've checked for errors with the NIC, nothing seems to be there. Nothing is in the logs that stand out...

My guess is it has something to do with the Secure part in SFTP, SCP and WEBDAV using HTTPS. Is it possible something with SSHD or some other secure config or setup is messed up? How would you check that?

Any ideas to troubleshoot this would be great, thank you.

James

Is the CPU maxing out during secure transfers?
If the number of bits that the SSL / SSH keys were generated with was very high, it could in theory slow down the transfers. Not sure why it would only become apparent after a reboot though.

You can check an rsa key with something like;
(Or whatever you named your ssh key.)

The SSL private cert can be checked in the same way.
You can check the SSL public cert with something like;
Public-Key: (2048 bit)

If the keys have nothing to do with it, the only other thing I can think of right now is if there are some weirdy firewall processing rules that only apply to SSH/SCP/HTTPS.

There's also a "Compression" option for sshd_config that can be good for slower connections but can slow down faster connections.

Check the detected duplex of the eth interfaces on the server and nearest switch. I have seen one lock to full, and the other lock to half, and it worked just fine: with tons of error packet resends and sharply reduced throughput.

try disabling ipv6.

I will just throw this out there... some time back I experienced a similar effect, I never figured it out and ended up reloading... however, I did notice an oddity when troubleshooting, if I logged on as root my speeds were normal, if I logged on as a regular user it was painfully slow.

Anyway, just throwing that against the wall

Nope.

That might be. I will check that as I used this: http://docs.slackware.com/howtos:security:ssh

to set it all up, except for changing the ports.

I didn't fool with that, but I checked and there is nothing in there for compression being on.

Thank you!

There's only 1 eth interface, and it's on full. :/

That didn't have a noticeable effect.

I'll give that whirl and see what happens.

Quite wrong, actually. That eth interface has a CAT5/CAT5e jumper connecting it to ANOTHER eth interface on some device that gives it access to the rest of the network (and, I assume, internet). Is it also on full?


That asked, I rather suspect it is just fine and there is a different cause. The error count on that interface would climb were it the duplex issue.
You might see if there is an update to OpenSSH, zlib, or OpenSSL in the chain that addresses

Did you try to turn off Autonegotiation for Ethernet? When cable or Ethernet card degrading, testing different speed help to identify this problem.

Here is a test you can try:
If possible, run an FTP listener (in a private chroot with limited resources and permissions for security, if you are, like me, not very trusting). Then do a file transfer of a file on the order of the common size, the size that has been displaying the performance hit.
The performance under FTP will depend upon the underlying infrastructure and networking, not OpenSSH. This will either confirm or disprove the software application component.
If it is slow, it will leave hardware, Kernel, and drivers only to be considered.
If it is fast, then you have an OpenSSH issue (or one of the libraries it depends upon) and can focus on the real cause of the problem.

Either way, disable ftp when you have completed the test, and let us know what you find.

Looks like this may have been a culmination of many things just happening at once.

A couple days later, without any other changes, my speed improved to all my typical locations except home. I could download at full speed from my work, from my UK VPS, from my Kansas City VPS...everywhere but home. In checking my speed(should be 100 down/4 up), I was only getting 7 down and 3 up. I reset the modem and router to no change.

I checked the router for an update, and it had several. I updated them and upon resetting the router, my speeds went back to normal. In downloading from my server, I am back to getting my regular download speeds.