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.

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.

"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. "

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.

Quote:

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.