knowing the bitrate of a specific TCP stream

Riccardo Manfrin

unread,

Dec 15, 2009, 8:26:48 AM12/15/09

to

Hi NG,
I hope not to be OT.
Given a TCP stream from node A to node B (in terms of [SRCIP:SRCPORT -
DSTIP:DSTPORT], I'd like to know at a given time T the number of bytes
sent (since the link setup time, up to time T) by querying some fs or
kernel struct.
Is this possible? (if so how?)
Thanks

Aragorn

unread,

Dec 15, 2009, 8:51:22 AM12/15/09

to

On Tuesday 15 December 2009 14:26 in comp.os.linux.networking, somebody
identifying as Riccardo Manfrin wrote...

I cannot tell you *how* exactly - as I've never had the need to
investigate this - but it is possible, yes. I distinctly remember from
a few years ago that the KDE System Guard for instance had the ability
to show you this graphically by querying its "network sensors", and as
such, there must be a hook into "/proc" somewhere to get that
information from.

--
*Aragorn*
(registered GNU/Linux user #223157)

Aragorn

unread,

Dec 15, 2009, 8:54:02 AM12/15/09

to

On Tuesday 15 December 2009 14:51 in comp.os.linux.networking, somebody
identifying as Aragorn wrote...

Addendum...: Check the output of...

/sbin/ifconfig

You need not be root in order to use this command for querying only.

Riccardo Manfrin

unread,

Dec 15, 2009, 9:44:24 AM12/15/09

to

Well if I peek on /proc/net/whatever (tcp, udp, unix)
I can get some information with the rxqueue/txqueue field information.
That is nevertheless not enough to determine rate in terms of "octets
over seconds" which is my goal.
I'm starting to track tcpick (http://tcpick.sourceforge.net/) code
(keeping an eye on the old good tcpdump boy).
I wonder if they do the same stuff and if I can replicate their
functionalities and adapt them to my needs without having 100% CPU usage..

Christophe Lohr

unread,

Dec 15, 2009, 10:03:03 AM12/15/09

to

Riccardo Manfrin a �crit :

> Well if I peek on /proc/net/whatever (tcp, udp, unix)
> I can get some information with the rxqueue/txqueue field information.
> That is nevertheless not enough to determine rate in terms of "octets
> over seconds" which is my goal.

Look at the tcp_probe module
http://www.linuxfoundation.org/collaborate/workgroups/networking/tcp_testing

You get time and sequence number.
This may be sufficient for your need.

Regards

David Schwartz

unread,

Dec 15, 2009, 11:57:38 AM12/15/09

to

On Dec 15, 5:26 am, Riccardo Manfrin <namesurn...@guesswhat.guesswhat>
wrote:

The last time I needed to do this, I had to make kernel modifications.
As I recall, I modified the structure that tracks a flow
(nf_conntrack?) to include the time the flow entry was created. That
way, you could divide the number of bytes in each direction by the
number of seconds the flow entry has been around.

DS

Joe Beanfish

unread,

Dec 15, 2009, 12:57:39 PM12/15/09

to

You can setup accounting rules with iptables. I don't know how because
someone else here did it.

pk

unread,

Dec 15, 2009, 3:16:05 PM12/15/09

to

Riccardo Manfrin wrote:

You should define more precisely what you mean. What do you do with, for
example, lost or retransmitted segments?

And, what do you include in the calculation? TCP header + payload, or
payload only? (or do you want to include lower level headers as well?)

Each side of the connection may have a different idea of how many bytes have
been "sent". And, btw, what is "sent" here? The number of bytes the
application wrote to the socket, or the bytes that have actually been sent
on the wire, or yet something else?