aMule Forum
English => en_Bugs => Topic started by: yoyoio on March 22, 2005, 08:57:28 PM
-
First of all, thanks to all amule developpers, good work:)
My settings. UL 50 kb/s DL 120 kb/s max sources per file 1000, max connections 500
OS gentoo with iptables.
I'm testing amuled and these are the bugs that I've found.
Upload works very well with default speed value for client connection (3kb), but if I set to a higher value (8kb for example), the upload seems to be very unstable, no upload at all (clients in upload but showing 0kb/s) or uploading only two clients at 20kb/s and the other ones 0 kb/s or 0.5 kb/s...I mean, graphs not showing a straight line.
When I put something to download, the active connections start growing until they reach their limit showing a straight line at 500, and not accepting new connections, after a few days, there are no clients in the upload queue and downloads stops (no connection with clients), but the active connections graph still show a straight line at 500.
netstat shows stablished connections (500 more or less from amuled tcp port)
I think that this is the same problem http://forum.amule.org/thread.php?threadid=5530&sid=
BTW, amule works fine with these settings.
aMule-CVS-20050320 and older.
P.S: sorry for my English.
-
well 1st of all max sources per file 1000 and max connections (overall) 500 does not make a lot of sence dont you think?
so maybe switch that and see if it does any better
-
I would like to know ethereal evidence for this case.
How match of actual upload/download stream is taking place ? How many syn+ack packets are coming out (i.e. number of accepted connections) ?
-
Thanks for the reply Stefanero.
I set to 1020 a few hours ago and still growing.
stats shows:
aMulecmd$ stats
> Conectado a Razorback 2 [195.245.244.243:4661] con IDAlta
> Descargado: 22 KB/seg
> Subida: 50 KB/seg
> Clients in queue: 3000
> Total sources: 301
aMulecmd$
BTW, the files that I am downloading only have 20 sources more or less.
14 / 15 (0)+10
9 (1)+10
6 / 7 (1)+22
32 / 33 (1)+12
40 / 45 (1)+1
24 / 25 (0)+1
22 / 25 (0)+7
27 / 29 (0)+13
38 / 42 (0)+1
65 / 68 (1)+1
With amule (not amuled), the graphs shows 200 con. more or less, only reach 500 conn. when amule starts, and never reach limit for a long time
and
netstat -an|grep MyIP:aMulePort|grep ESTABL|wc -l
638
only uploading this behaviour doesn't happen.
I hope this information help.
-
lfroen, i still don't have ethereal emerged.
-
This seems to be the same thing I posted and I would like to help. I've just installed ethereal but I never used before. What exactly do you need? A log file of what it captures?
-
Well, I want to know: doesn all connection are in "established" state ? Or it is some "wait" like CLOSE_WAIT ?
Regarding ethereal: I want trace itself, but you can limit data in each packet to let's say 64 bytes.
Than send it together with you ip to lfroen@gmail.com and I will try to see what's wrong with daemon. Thank you for report.
-
Here you have what netstat says about connections:
# netstat -putan | grep amuled | wc -l
330
# netstat -putan | grep amuled | grep ESTABLISHED | wc -l
326
# netstat -putan | grep amuled | grep CLOSE_WAIT | wc -l
2This time is taking longer to reach the limit but it is very close. Now I'm gonna try with ethereal.
-
Originally posted by stefanero
well 1st of all max sources per file 1000 and max connections (overall) 500 does not make a lot of sence dont you think?
so maybe switch that and see if it does any better
Uhm, why not? Depending on the number of files he is downloading (and the _total_ number of sources found and used) this setup can make quite some sense ;)
-
think about it, it does not make any sence.
how can you have more sources per file, then the overall amount of sources?
and teh more files you dontload the worse it gets, since the "last" files will have no sources left at all
-
number of used sources != number of connections used at any given moment.
If I find a source I connect to it, say "hello, here I am, I want this file, which is my queue number?", get the answer from the other client and then the connection is being closed. And only after x minutes (~30 minutes in emule IIRC, no idea about amule) I reconnect to this source and say "Hi, I'm still there, this file, which is my QR?" and disconnect again after getting these infos...
As a real life example:
I have max sources per file = 400, max connections = 230 and 30 files in my download.
This makes a total of ~3500 sources in my case (some quite rare files) and I have an average concurrent connections of ~100...
-
and teh more files you dontload the worse it gets
stefanero is right. max number of total sources should be > sources per file. Otherwize this configuration have no sense.
-
I think I fixed the bug now. Check next tarball (not yet available).
-
You're more faster than speed of light :baby:, I've just returned from work and the bug is fixed 8o
Ethereal emerged in case of need it again.
Thank you to all amule developpers.
Kry, parece que te sabes el codigo de memoria :)
-
Originally posted by yoyoio
Kry, parece que te sabes el codigo de memoria :)
That's because it's true :P
-
I sent the ethereal log to lfroen a few hours ago, but you're faster coding than ethereal capturing ^_^
Thank you very much.
-
Still happening with 20050325, it's been running for a day and is almost reaching my limit.
-
Reaching of the limit is normal if you have many sources but it shouldn't happend every second :D
cu
Mr Faber
-
Is this supposed to be solved? It is still happening here, anyone else?
-
BeFalou, me too :(
I've changed my settings to 1000 conn. and 200 sources/file (only 1 file downloading), and after a couple of days the limit is reached. And it happends every second...
With this settings normal amule works very fine.
BTW, Does the udp port still need to be disabled?
Thanks
-
With this settings normal amule works very fine.
Reaching connection limit is ok (that's what limit is for). If those connections are "ESTABLISHED" and you have up/down streams, I would say it's ok.
BeFalou: i see nothing unusual in trace you sent me.
-
Reaching the limit from time to time is okay but not all the time, it works fine for a day or so, although connections keep growing, and then amuled gets slower. I don't know what would happen after 2 days or more because I often change to current cvs.
Thing is, if this is normal, why is not happening with aMule? Seems to be more efficient managing connections than amuled.
Regards.
-
Thing is, if this is normal, why is not happening with aMule? Seems to be more efficient managing connections than amuled.
point is right. they must behave almost same. Can you say what's a status of connections? How match is "EXTABLISHED", "CLOSE_WAIT" etc. You can see it with "netstat -nap | grep amuled"
-
Originally posted by BeFalou
Here you have what netstat says about connections:
# netstat -putan | grep amuled | wc -l
330
# netstat -putan | grep amuled | grep ESTABLISHED | wc -l
326
# netstat -putan | grep amuled | grep CLOSE_WAIT | wc -l
2This time is taking longer to reach the limit but it is very close. Now I'm gonna try with ethereal.
I already posted it :]
-
Sorry, the first post is wrong. Only uploading the problem happens as well.
I think I found out some interesting relationship between ESTABLISHED connections and total failed upload sessions. I've been taking values for ESTABLISHED connections from amuled and number of total failed upload sessions since a few hours.
failed-upload:established:established - failed
260 300 40
269 320 51
283 334 51
317 370 63
340 370 30
348 395 47
So, established = failed + ~50 , perhaps it's only a coincidence
Uptime: 1 Days 21 hours (only uploading)
863 619 -244
So, the behavior has changed and it was only a coincidence, or linux is closing old connections.
BeFalou, is the same for you?.
I'll put something to download later to see what happens.
Regards
-
amuled uptime: 21h, it's not reaching my limit yet, I`ll update this when it does.
failed-upload:established:established - failed
55 276 221
EDIT: After 1D 22h, (my limit is 400)
161 401 360
-
Now
Established 986 (My limit is 1000)
Estadísticas
Uptime: 3 Days 00 hours
Transferencia
Session UL:DL Ratio (Total): Not available
Subidas
Uploaded Data (Session (Total)): 9,98 GB (55,62 GB)
Total Overhead (Packets): 166,21 MB (2,36M)
File Request Overhead (Packets): 73,74 MB (847K)
Source Exchange Overhead (Packets): 15,39 MB (38K)
Server Overhead (Packets): 134 KB (31K)
Subidas activas: 17
Subidas en espera: 4000
Total de subidas satisfactorias: 10409
Total de subidas erróneas: 1720
Average upload time: 5:40 mins
Descargas
Downloaded Data (Session (Total)): 0 Bytes (11,72 GB)
eMule: 0 Bytes
aMule: 0 Bytes
eDonkey: 0 Bytes
eDonkeyHybrid: 0 Bytes
Shareaza: 0 Bytes
MLDonkey: 0 Bytes
(l/x)Mule: 0 Bytes
Other: 0 Bytes
Total Overhead (Packets): 98,31 MB (2,35M)
File Request Overhead (Packets): 33,05 MB (1,55M)
Source Exchange Overhead (Packets): 953 KB (61K)
Server Overhead (Packets): 3 KB (35)
Fuentes encontradas: 0
Descargas activas (partes): 0
-
no download at all?! 8o
in 3days???
-
That's because I didn't put anything to download :)
I'm testing the problem with active connections.
Now, running 3 days 1hour and amuled is starting to drop clients from queue because there's no room for new connections.
Estadísticas
Uptime: 3 Days 01 hours
Transferencia
Session UL:DL Ratio (Total): Not available
Subidas
Uploaded Data (Session (Total)): 10,12 GB (55,76 GB)
Total Overhead (Packets): 167,70 MB (2,38M)
File Request Overhead (Packets): 74,39 MB (854K)
Source Exchange Overhead (Packets): 15,50 MB (38K)
Server Overhead (Packets): 136 KB (31K)
Subidas activas: 17
Subidas en espera: 3862
Total de subidas satisfactorias: 10580
Total de subidas erróneas: 1750
Average upload time: 5:39 mins
.......
......
Conexión
Velocidad media descarga (Sesión): 0,00 kB/s
Velocidad media subida (Sesión): 40,16 kB/s
Promedio de descarga máx. (Sesión): 0,00 kB/s
Descarga máxima (Sesión): 0,00 kB/s
Reconexiones: 0
Time Since First Transfer: 3 Days 01 hours
Connected To Server Since: 3 Days 01 hours
Active Connections (estimate): 997
Max Connection Limit Reached: 1673 : 2005-04-11 23:28:59
Average Connections (estimate): 999,437317
Peak Connections (estimate): 1003.
....
....
Archivos compartidos
Nº de archivos compartidos: 267
Total size of Shared Files: 101,06 GB
Average filesize: 387,60 MB
So, there's something wrong with amuled.
-
yoyoio: ok, connection limit is reached. No dload 'cause there's nothing in queue. But upload ? I don't see it in stats. Or you telling that there's no upload as well ?
-
There are uploads in my previous posts.
first:
Subidas activas: 17 (uploading)
Subidas en espera: 4000 (clients in upload queue)
Total de subidas satisfactorias: 10409 (uploads ok)
Total de subidas erróneas: 1720 (failed uploads)
second:
Subidas activas: 17
Subidas en espera: 3862
Total de subidas satisfactorias: 10580
Total de subidas erróneas: 1750
Average upload time: 5:39 mins
...
Velocidad media subida (Sesión): 40,16 kB/s (average upload)
....
Archivos compartidos
Nº de archivos compartidos: 267 (number of shared files)
Total size of Shared Files: 101,06 GB
Average filesize: 387,60 MB
now:
Uptime: 3 Days 18 hours
......
......
Subidas activas: 14
Subidas en espera: 1
Total de subidas satisfactorias: 11735
Total de subidas erróneas: 2139
Average upload time: 6:30 mins
...
...
Conexión
Velocidad media descarga (Sesión): 0,00 kB/s
Velocidad media subida (Sesión): 41,99 kB/s
....
active Connections (estimate): 1001
So, there is only 1 client in queue, 14 active uploads, (upload speed=50kb/s),but there are 1000 active connections.
-
So, there is only 1 client in queue, 14 active uploads, (upload speed=50kb/s),but there are 1000 active connections.
This makes no sense. If you have no (or 1) clients in queue, how do you have 50kbps upload rate on 14 uploads ?
What OS / kernel do you using ?
-
OS: Gentoo on AMD K6-3D
Kernel 2.6.10-gentoo-r6
each upload at 3kb/s
When an upload finish, one more client enter the queue and starts upload (i think so)
aMulecmd$ stats
> Connected to Razorback 2 [195.245.244.243:4661] con IDAlta
> Download: 0 Bytes/sec
> Upload: 50 KB/sec
> Clients in queue: 0
> Total sources: 0
aMulecmd$
Full statistics:
aMulecmd$ statistics
> Estadísticas
> Uptime: 3 Days 22 hours
> Transferencia
> Session UL:DL Ratio (Total): Not available
> Subidas
> Uploaded Data (Session (Total)): 13,78 GB (59,42 GB)
> Total Overhead (Packets): 171,59 MB (2,45M)
> File Request Overhead (Packets): 76,11 MB (877K)
> Source Exchange Overhead (Packets): 15,65 MB (38K)
> Server Overhead (Packets): 164 KB (39K)
> Subidas activas: 15
> Subidas en espera: 0
> Total de subidas satisfactorias: 11873
> Total de subidas erróneas: 2142
> Average upload time: 6:44 mins
> Descargas
> Downloaded Data (Session (Total)): 0 Bytes (11,72 GB)
> eMule: 0 Bytes
> aMule: 0 Bytes
> eDonkey: 0 Bytes
> eDonkeyHybrid: 0 Bytes
> Shareaza: 0 Bytes
> MLDonkey: 0 Bytes
> (l/x)Mule: 0 Bytes
> Other: 0 Bytes
> Total Overhead (Packets): 102,52 MB (2,45M)
> File Request Overhead (Packets): 34,96 MB (1,62M)
> Source Exchange Overhead (Packets): 1008 KB (65K)
> Server Overhead (Packets): 3 KB (35)
> Fuentes encontradas: 0
> Descargas activas (partes): 0
> Conexión
> Velocidad media descarga (Sesión): 0,00 kB/s
> Velocidad media subida (Sesión): 42,32 kB/s
> Promedio de descarga máx. (Sesión): 0,00 kB/s
> Descarga máxima (Sesión): 0,00 kB/s
> Reconexiones: 0
> Time Since First Transfer: 3 Days 22 hours
> Connected To Server Since: 3 Days 22 hours
> Active Connections (estimate): 996
> Max Connection Limit Reached: 3140 : 2005-04-12 20:21:09
> Average Connections (estimate): 996,003052
> Peak Connections (estimate): 1010
> Clientes
> Total: 397 Known: 397
> eMule: 334 (84,1%)
> v0.45b: 198 (59,3%)
> v0.45a: 3 (0,9%)
> v0.44d: 52 (15,6%)
> v0.44c: 1 (0,3%)
> aMule: 3 (0,8%)
> Versión
> v2.0.0: 3 (100,0%)
> Operative System
> Not Received: 3 (100,0%)
> lMule/xMule: 0 (0,0%)
> eDonkeyHybrid: 5 (1,3%)
> v1.0.0: 1 (20,0%)
> v0.52.0: 1 (20,0%)
> v0.50.1: 1 (20,0%)
> v0.10.3: 2 (40,0%)
> eDonkey: 0 (0,0%)
> v462.8.0: 1 (100,0%)
> cDonkey: 0 (0,0%)
> MLDonkey Antiguo: 0 (0,0%)
> MLDonkey Nuevo: 8 (2,0%)
> Shareaza: 45 (11,3%)
> lphant: 2 (0,5%)
> Compatible: 0 (0,0%)
> Desconocido: 0
> LowID: 148 (37,28% Total 37,28% Known)
> IdentSeg On/Off: 112 (33,23%) : 212 (62,91%)
> Filtrado: 0
> Servidores
> Servidores activos: 31
> Servidores caídos: 69
> Total: 100
> Servidores eliminados: 0
> Usuarios en servidores activos: 3087072
> Archivos en servidores activos: 351115647
> Usuarios totales: 4658227
> Archivos totales: 528062359
> Ocupación de Servidores: 18,62%
> Archivos compartidos
> Nº de archivos compartidos: 267
> Total size of Shared Files: 101,06 GB
> Average filesize: 387,60 MB
-
I will try to reproduce it at home and debug it in deep.
-
Hey,
Did you find anything new about this? This is the most annoying thing in amuled right now as I have to restart it every two days or so. If you need any more info just ask for it.
Oh, and... Congrats for aMule-2.0.0! :)
-
No. I could not reproduce it. So the only way is to debug it at YOUR machine with your condition. Please confirm the following:
1. You did not tweaked any tcp/ip kernel settings
2. You do not using bandwidth control (tc command).
3. You do not observing this behavior with "regular" amule.
After that, at the time problem is being observed please provide the following:
1. Result of "netstat -nap | grep amuled"
2. Result of "netstat -i"
3. Result of "/sbin/ifconfig"
4. Run ethereal on your outgoing interface and provide resulting trace for several minutes. Send it as attachment to lfroen@gmail.com .
5. Amule settings.
6. Result of amulecmd -c stats (with english strings if possible).
I will make my best to find a source of this weird problem. Sorry for long list of requests, but I have run out of guesses.
-
I sent you an email with all the info you requested, however, I still have to try with regular aMule.
-
Mhmm, I think I have the same problem. I have many downloads but that can't be the reason of the constant increment of active connections until the limit is reached.
I use tc but I am not the only one with this problem. Maybe aMuled or the wxLibs does not kill some old connections so after two days the limit gets reached.
By the way thanks for the great aMule 2.0 release. It is very stable.
cu
Mr Faber
-
BeFalou, Mr Faber: I would like ask you again to confirm:
1. Problem only in amuled. Regular amule work fine.
2. You do not using tc. If you do, please disable it for testing time. It's complicated thing and can easy break your setup if incorrectly configured.
BeFalou: thanks for detailed info you sent. Now I've noticed that one thing is missing in my request:
* Your network setup
Since your IP is 10.0.0.2 - you must be using private/home lan. Please tell me (or send me) how your setup looks like. What kind of router is it ? Or switch ? Or both ?
Don't get me wrong - I really want to solve this problem. However, it seems that problem happens in specific setup (yours in particular). I'm still trying to figure out what exactly your setup is.
-
Theoretically tc is disabled because aMule only works fine if it not reaches the upload limit of tc. I always limit the upload of aMule to prevent this special behaviour.
I have a public IP and the ports open so it shouldn't be the problem for me. But with the new CVS amuled 20050504 the connections seems very stable like expected after 14 hours of running. Maybe it changes later. In old versions I have to restart at least after three days because the limit of 500 connections was always reached and the download stucks. But the upload still works :) .
Except of my first runs of aMule I always use the daemon so I can't confirm it.
cu
Mr Faber
-
Everything MrFaber said is what happens here, but for me 14h is not too much, after 1 day or more is when the limit is reached.
@lfroen: I sent you my network setup.
-
BeFalou: I still want to know whether it is amuled specific problem, and amule works fine.
-
Ok, if I have the connection problem again or have to restart I will compile amule instead of amuled and check it.
cu
Mr Faber
-
I had to install wxGTK and amule monolithic so it took me longer to test it. After 6h30min my active connections are 83 right now and the graph seems to be very pretty stable.
-
Definitely it is not happening with regular amule. Uptime: 18h5min, amuled would have ~300 connections by now.
-
After exactly 2 days my connection limit was reached and never goes down again so I decided to compile the new CVS aMule and not the daemon.
The connection seems after over 13 hours stable but this has nothing to say since the daemon acts equal at this time. But I found another interesting thing.
With the daemon I have had only and average upload time of 10-20 mins in most cases (I have made no long tests so it may only happens some times). With normal aMule I have 41:30 minutes which seems quite stable. The total failed upload sessions are with 13 very low vs 225 total successful upload sessions.
cu
Mr Faber
-
Please test following patch to amule cvs code. I would like to know if it changes things.
-
+ if ( idle_count > 360000 ) {Shouldn't the 360000 be 12000, otherwise you'll wait for 360000 * 50ms, which would be 300 minutes, whereas 12000 * 50ms is 10 minutes exactly.
-
Point taken. Patch corrected.
if ( m_socket->WaitForRead(0, 100) ) {
if ( m_socket->RecievePending() ) {
Sleep(50);
idle_count++;
This will take from 50 to 150 ms depending how match time WaitForRead took. So, 10000 translates to range 10000*(50ms ... 150ms) => 500sec ... 1500sec. I think it's enough time.
-
Is this patch for aMuled or aMule? At first I will check aMule for at least 2 days to confirm that this has something to do with the daemon and not the monlith.
cu
Mr Faber
-
Patch have nothing to do with monolitic amule. It affects only daemon code.
-
Since aMule crashes without user interaction I can't confirm definatly that aMule hasn't the problem but after over 20 hours the connection graph was still stable.
After that I have downloaded CVS 20050508 and compiled the daemon with your patch.
cu
Mr Faber
-
I can confirm that aMule hasn't the problem.
Now, I have compiled amule & amuled with wxGTK 2.6, amule is very stable and works very fine, but amuled don't upload neither donwload anything, or only 1 client uploading a few seconds a few bytes and nobody in queue.
amule: active connections 60 more or less.
aMule CVS using wxGTK2 v2.6.0 (Unicoded) (Snapshot: Sat May 7 07:01:19 CEST 2005) (OS: Linux)
aMule Daemon CVS using wxGTK2 v2.6.0 (Unicoded) (Snapshot: Sat May 7 07:01:19 CEST 2005) (OS: Linux)
-
amuled is unable to run for a long time, it crashes, so I can't reproduce this. I've posted the BT here: http://forum.amule.org/thread.php?threadid=6080&sid=
It's with today's CVS and lfroen's patch.
-
I'm sorry to say that the patch is not working. The image attached is the connection graph after 1D 3h. It hasn't reached the top yet but it's a lot more compared to amule monolithic graphs (posted before).
-
Hmmmm ... I will check uploading code as well, but this code is shared between amule and amuled, so I would be very surprized to find a difference :)
-
Another point that makes me think it is an upload thing is that all established connections are from my amuled port to others, while when we download from others this connections are made with other ports.
Maybe this thinking is stupid but I had to say it :rolleyes:
-
amuled network code has been reworked. Please feel free to test cvs versions !
[Kry - Edit (fill free?)]
-
Thanks for the hard work, but by now I can't test it for long, it crashes. BT -> http://forum.amule.org/thread.php?threadid=6347&sid=
Regards.