1

we are on a debian system and are trying to tune the tcp/ip stack to our needs. We all know that you can set the maximum tcp buffer size with some kernel parameters like this:

  net.ipv4.tcp_wmem = 4096  16384   4194304
  net.ipv4.udp_wmem_min = 4096
  net.core.wmem_max = 261071

To calculate the maximum buffer size for your needs you "just" have to calculate it. (see http://fasterdata.es.net/TCP-tuning/ )

But as we do not know the round-trip-time of our users, it is quite difficult. It might be ok to assume something between 20 and 60 ms. But for an mobile network it is something like 100-300 ms (tested with my phone). So it is quite difficult to know how many data might be "on the line".

We would like to see the actual buffer size and the utilization of it.

Does anybody know how to sneek into the actual tcp write and receive buffers?

Janning
  • 1,421
  • 2
  • 21
  • 38
  • 1
    Sounds like you need to profile your specific application and determine bottlenecks in performance before simply taking the performance sledgehammer to random parts of the system. Just my 2 cents. – Chris S Aug 24 '10 at 12:47
  • 1
    Are you sure you need to worry about these things? Linux, *BSD etc. have supported window/buffer size autotuning for more than half a decade already, as even stated by your link: "Linux, FreeBSD, Windows, and OSX all now support TCP autotuning, so you no longer need to worry about setting the default buffer sizes.". If you are absolutely, positively sure you need to do this AND you can outsmart the OS, then you need to profile your application. But remember, this kind of low-level tinkering can actually lower the performance, not make it better. – Janne Pikkarainen Aug 24 '10 at 12:55
  • 1
    Both comments are correct and i would recommend it too to anybody else. But my question was: How to see the actual tcp buffer size per socket? We are not stupid guys fiddling aroung with some kernel parameters. As you can see here: http://serverfault.com/questions/165596 There are tuning oppertunities if you want to serve 2000 images per second. We are running a high volume website with lots of peak traffic. So it is worth to tune some tcp parameters to fit our needs. – Janning Aug 26 '10 at 09:02

2 Answers2

1

But as we do not know the round-trip-time of our users

Then what's the point in trying to measure another part of the equation?

(read the man pages for lsof (-T flag) also netstat).

But trust me, the TCP system is quite smart - and the guys who wrote it are smarter than both you and I - and know a lot more about this stuff. The only thing to be concerned about is the window-scaling (these days should be disabled by default) although unless you are transferring very large files across a very high speed WAN you probably don't need it - if the files are not huge, or the bandwidth is low, then there's no beneift over using the default scale.

symcbean
  • 21,009
  • 1
  • 31
  • 52
0

As they said it's useless to do something like that. It may be useful if you had a wired network with constant traffic, but even then it's not suggested. What you could propably do is to define another tcp implementation (Vegas , Tahoe, Reno etc are some implementation).

Each one of them is focused on improving some aspect of tcp. For example one is trying to improve delay, another try to import jitter etc.

Nikolaidis Fotis
  • 2,032
  • 11
  • 13