When MLDonkey is working (even if the downloads are very slow) it causes any Internet browser to work really slow. To be more exact, the original connect to any site that is not in cache takes 20-40 seconds, or forever. Someone tried to observe the trafic and found (on his machine) a significant packet loss (up to 90%): http://forums.gentoo.org/viewtopic.php?t=149947&highlight=mldonkey+network+loss Anyway, I have this effect on both of my computers. root@screamer $ emerge info Portage 2.0.50-r6 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.5) ================================================================= System uname: 2.6.5 i686 AMD Athlon(TM) MP 2400+ Gentoo Base System version 1.4.11 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-mp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X aim alsa amd apache2 apm arts autofs avantgo avi berkdb cddb cdr client crypt cups dga directfb dvd dvdr encode esd fax fbdev ffmpeg flac fltk foomaticdb freetype fs gd gdbm gif glut gnome gpm gtk gtk2 icq imap imlib informix jabber java javascript joystick jpeg kde lesstif libg++ libwww mad maildir mbox mcal mdb mikmod mmx mng motif mozcalendar mozilla mpeg mpeg4 msn music mysql ncurses neXt net netcdf nls nvidia oci8 offensive oggvorbis opengl oss pam pcap pda pdflib perl php png postgres ppds pthreads python qt quicktime readline rplay samba scanner sdl slang snmp spell ssl svga tcltk tcpd tiff transcode truetype type1 usb virus-scan wmf x86 xine xml2 xmms xv xvid yahoo zlib zvbi"
Cannot duplicate this bug. Have you tried reducing the max number of connections or the number of connections per second? The problem is most likely with your MLDonkey configuration.
Yes, it does work little bit better with the # of connections as 100. But effect still stays, just not that serious
i had the same problem with my mldonkey but it occured after the 24h-disconnect of my ADSL-connection. i have a /etc/init.d/mldonkey restart in my ip-up. After a restart with the init script the mldonkey core leaves many connections opened and the will stay in the kernel ip_conntrack table until next restart. Try to add wget --spider ${BASE}/submit?q=close_all_sockets -q And reboot. this is working for me.
Have you made sure that there is enough upload bandwidth available for your browser? If you use up all the upload capacity of your connection with mldonkey, other tcp connections over the same line will be very slow, since TCP/IP is a two-way protocol. This effect does not only apply to mldonkey, but to any application that uses a lot of upload bandwith. You should have a reserve of at least 4-5 kbytes/s for your browser. Another thing that could be a problem is that DSL routers often have a maximum capacity of incoming / outgoing connections; because of the "IP masquerading" they need to reserve a little space for every TCP connection that is made through them, and space is a costly resource. So you might try to reduce the maximum number of simultaneous connections, too. Maybe you can find the values of your router in its data sheet / documentation.
Yeah, I already found out that decreasing the number of outgoing connections to 50 does it.
I added ewarn to reduce the maximum number of connections if network problem occurs. Thanks for the bug report.
I think this bug was assigned to the wrong herd, it should be assigned to the Gentoo net-p2p team <net-p2p@gentoo.org>. I think it would make more sense to remove the ewarn from the app-emacs/mldonkey ebuilds and add it to the net-p2p/mldonkey ebuilds. app-emacs/mldonkey cannot cause the slowdowns because it's only a GUI for net-p2p/mldonkey.
