transfer rate

[zomo]

Hi again !

I have another problem
I have dsl link with 8mbit download rate... when i try to download(on router) file from nearest server i'm getting transfers smthg about 168 kB/s?
I do this after pfctl -d and sysctl -w net.inet.ip.forwarding=0, becasue i have network behind router. I also have try to reebot, but nothing positive happen - speed didnt grow.

More...I enable pf and packet forwarding and station in network which have 4Mbit/s set in altq was downloading file with speed 400-500 kB/s

So I turned off once again pf and sysctl(to be sure the packets for internal network not blocking my link), and nothing change.

For test I use axel and wget...
Test file from http://noc.gts.pl/

Thanks for help !!!

Regards

[jggimi]

Originally Posted by zomo

...I have dsl link with 8mbit download rate... getting transfers smthg about 168 kB/s?

Y168 kilobytes/sec = 168 x 1024 X 8 = 1376256 bits/sec, approximately 17.2% of DSL bandwith, assuming the "Mbits" used by your DSL provider uses 1000000 rather than 1048576. If so, 8 Megabits is 8000000 bits/sec.

...station in network which have 4Mbit/s set in altq was downloading file with speed 400-500 kB/s

500 kilobytes/sec = 500 x 1024 x 8 = 4096000 bits/sec. That looks fine to me.

You probably have either a configuration error, or a hardware error. But you haven't posted any details of your configuration, so I won't guess. It could be something simple, such as needing a smaller MTU value for your DSL (very recent example from misc@: http://marc.info/?l=openbsd-misc&m=123111198112098&w=2). If you just want some direction, then use netstat -in to look for network hardware problems, or perhaps netstat -ss for protocol statistics can show you where the problem lies.

If you want us to diagnose your problem, you'll have to actually share details. See "How to create a problem report" in http://openbsd.rt.fm/report.html for guidelines.

[dutchopen]

@Zumo:

I've had the same "problem".

This worked for me:

From the FAQ:

"6.6.4 - How can I increase performance on really high-speed, high traffic links?
If you are seeing performance limitations when using a high-speed WAN connection transferring lots of data, you may see a performance gain by altering the following sysctls:
net.inet.tcp.recvspace
net.inet.tcp.sendspace

Try a value like 65536 instead of the default of 16384. Note that very few will see any benefit from this. Don't adjust this unless you are actually seeing performance below what you expect. "

[J65nko]

Note that the sysctls modifications, proposed by Dutchopen, have to be done on the system receiving or sending the files. On the router itself, it will have no benefit at all.

[zomo]

Hi everyone

Thanks for help dutchopen but I handle this myself this is my configuration:

# sysctl net.inet.tcp.recvspace
net.inet.tcp.recvspace=262144
# sysctl net.inet.tcp.sendspace
net.inet.tcp.sendspace=262144
#

This parameters lets me to download with speed above 1,5M/s ;]

Regards

[BSDfan666]

BSD supports TCP window scaling.. increasing the buffer space that high should not be necessary, and may actually have negative effects somewhere down the line.

I'll quote an article I bookmarked that outlines the possible side effects.

Originally Posted by http://www.networkcomputing.com/1013/1013ws1.html

When a window is too big, TCP can have difficulties trying to recover from lost data. For example, if a remote Web server sees a window size of 131 KB advertised by your client, then it eventually will try to send that exact amount of data--even if the bandwidth times delay for that connection only enables 4 KB of in-flight data. As a result, the remaining 127 KB would be queued in a router somewhere between the Web server and your client.

If any of that data is lost and retransmitted, the retransmitted data will have to sit in a router queue behind the rest of the data from the earlier transmission, while your system continues to receive (and reject) all the earlier segments. Eventually, the client will simply abort the connection because it will think that the connection cannot be recovered. Alternatively, the continuous stream of duplicate acknowledgements sent by your client back to the remote server may cause the server to abort the connection as well. Having an appropriately sized window would prevent these events from occurring.

If you have problems with the default 16384 window size, try 65536, avoid such unnecessarily large sizes.. as I said, BSD by default can dynamically resize the window if needed.

[zomo]

By default windows scaling is turned on:

net.inet.tcp.rfc1323=1

Why window is not scaling to higher value if it is physicaly possible to get much better speed, can you tell me?

[ai-danno]

Originally Posted by zomo

Why window is not scaling to higher value if it is physicaly possible to get much better speed, can you tell me?

errors?