Re: [Mldonkey-users] Excessive outgoing traffic

[Goswin Brederlow]

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