[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mldonkey-users] Excessive outgoing traffic
From: |
Goswin Brederlow |
Subject: |
Re: [Mldonkey-users] Excessive outgoing traffic |
Date: |
30 Jan 2003 10:52:45 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Military Intelligence) |
MLdonkey <address@hidden> writes:
> > I'm running the latest cvs version for 20 hours now and the bandwith
> > limiting of outgoing traffic is completly screwed.
> > [2003/01/26: Simon (tag unstable-2-02-8)]
> >
> > My upload limit is 2, mldonkey says it uploads 2050 byte/s but the
> > outgoing rate is 11.8 KByte/s even though everything above 8KB/s gets
> > shaped at the router.
>
> 11.8 Kbytes/s of what ? data ? TCP packets to resend lost data ? There
> is some bandwidth which is belong the control of mldonkey. It
> also depends on your download rate too: if you are downloading at
> 50 KBytes/s, you need at least 5 KBytes/s just for acknowledgments
> of received packets (in the TCP layer).
11.8KB/s of raw data. Incoming rates are between 1 and 10 KB/s (also
raw data). Packet loss should not make up for 5 times the allowed
traffic.
> > Something is just sending out traffic without accounting for it.
> > So whats not getting counted? Querying for sources maybe?
>
> Everything read or written is counted. But packets headers, TCP
> packets and things like that are not...
Is the "tcpip_packet_size = 40" option used to account for the
overhead each send packet creates?
Sniffing the data streams I see a lot of 5 to 10 byte packets being
send. Given 5 byte payload and 40 byte header that could explain for a
lot of excess traffic.
Some short datagrams for example:
93 46 22 8e 91 be ac 6d a6 33
8a e7 49 c5 72 5e 8e 4a 0f 00
20 5b 52 61 74 7a 6b 65 5d 2e
8d 46 5c d0 3e
e3 01 00 00 00 54
e3 01 00 00 00 54
d5 7c e1 c4 56
e3 01 00 00 00 54
e3 29 00 00 00
66 ed 63 6c 3d
Actually I see a lot of small packets in general and only a few full
ones:
----------------------------------------------------------------------
IPTraf
Packet Distribution by Size
Packet size brackets for interface eth0
Packet Size (bytes) Count Packet Size (bytes) Count
1 to 75: 38081 751 to 825: 51
76 to 150: 7847 826 to 900: 32
151 to 225: 1889 901 to 975: 100
226 to 300: 6952 976 to 1050: 27
301 to 375: 5338 1051 to 1125: 92
376 to 450: 831 1126 to 1200: 12
451 to 525: 289 1201 to 1275: 380
526 to 600: 192 1276 to 1350: 10
601 to 675: 99 1351 to 1425: 1057
676 to 750: 63 1426 to 1500+: 2229
Interface MTU is 1500 bytes, not counting the data-link header
Maximum packet size is the MTU plus the data-link header length
Packet size computations include data-link headers, if any
Elapsed time: 0:14
----------------------------------------------------------------------
The small packets are needed for control data, connects, etc. The big
packets should be actual downloads. The medium packets seem wastefull.
Wouldn't it be a good idea to save some upload bandwith and then send
out a full size packet on a stream instead of sending a few bytes
here, a few bytes there? Even control data could be delayed most of
the time until a packet size amount collects for a client. E.g. when
doing source propagation collect all the sources we are going to send
and then send them in one go instead of 20 small packets.
Just some thoughts.
Goswin