Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[KingFish]

Hi Devs!

Well, off to another, at least possible, bug. I say possible as I don't know if it really is one. It could also be possible the error lies on my side. If that's the case, please excuse this thread/post!
Ok, as aMule 1.2.3 got released I grapped the source and compiled myself as there was no Debian package available. Compilation ran smooth. Everything worked. I released some stuff on ed2k, which noone else had, so I was the only source. After letting the client run for hours/days and successfully uploaded several GB (aMule stats told me so) I had the first few complaints from users that they weren't able to get any chunk complete from me. I was really confused as I wasn't able to see anything that gone wrong from my side. Well, first I thought I made a mistake with the compilation. So, I used the then available official Debian package for 1.2.3. Same problem. So I downgraded to 1.2.1. And see, it works.
So.. I can't really explain this behaviour, I just thought to let you know about. Sorry I can't give you any logs/traces or so, but as I told you, the error can't be seen on aMule's side.
Hope you take this post serious as bad uploading is one of the worst bugs a share client can have imo! GBs of bandwidth wasted, on both (uploaders and downloaders) side.
Hope I could be of any help!

Keep up your great work!

[edit]This isn't a bug, just some code changing which resulted in "unstable" transfers if upload limit is set to close to line limit. Anyway, as this is not a real bug (in my opinion) I close this bug report myself. Btw, I really think you should compile a FAQ or something with those things explained in it.[/edit]

[deltaHF]

hi,

i also work for a release group and we have tested amule a lot ..
one user had probs with aMule 1.1.2 (long time ago) but till now we didn't noticed anything wrong..
dunno, but maybe there's something wrong with the file u release ?!?
if u want, we can do a test next time (2 diff files) to see what happen..

greets
delta

[KingFish]

Hmm.. I would like to test the behaviour for myself. Is it somehow possible to run two aMules on the same machine? I tried to, with different users and ports, works well, but I can't find myself as source then. I guess aMule rejects the same IP.. Any solution for this? (I only have this machine, so..)
Also, might it help if I turn on those verbose (debug) reporting?

[Citroklar]

I can create a home network and run some tests here. I will use aMule on one side and eMule 0.30e on the other. I will do this tomorrow and then report here.

Greetings,
  Citroklar

[KingFish]

Geez.. I don't know why, but aMule refuses to work for me (at least if I compile it myself).
First, I mainly use the official debian package for 1.2.1 as I know it works (upload also, verfied by 100+ leechers ). Prior to that I always compiled aMule myself, and it always worked also.
Now, in order to make a debugable version so I can give you a backtrace (for the other bug I reported) I tried to compile 1.2.4 and 1.2.1 (as I hoped it would work). Compilation ran smooth, except the usual minor warnings. But either a comilation against the patched gsocket or not against it resulted in binaries which are working fine it seems at first, but nearly no data transfer is happening. I absolutely don't know why! As I start the precompiled binary 1.2.1 everything works. And both run on the same setup, same temp files, same shared files.
I guess you will say it's a problem with my glib/gtk/wx.. but, I have the debian packages installed and the normal runtimes versions matches the dev packages. Also I'm quite sure they haven't changed since the day my compilation still resulted in usable binaries.
Nevertheless, here's my output from get-info.sh, if you need any other output/information feel free to ask. (Btw, using Debian SID/unstable, most recent packages.)

I.   Development Environment

     A. Compiler Info
        Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.3/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux Thread model: posix gcc version 3.3.3 20040110 (prerelease) (Debian)

     B. wxWindows Info
        Version: 2.4.2
        -pthread -lwx_gtk-2.4

     C. GTK Info
        GTK 1: 1.2.10
        GTK 2: 2.2.4

II.  System Environment

     A. CPU Info
        Type:  GenuineIntel
        Model: Pentium II (Deschutes)
        Speed: 398.778
        BMips: 796.26
        Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr

     B. Memory Info
        Total:   257168 kB
        Unused:  136532 kB

     C. Kernel Info
        Version: 2.4.23

     D. Library Info
        wxWindows library: libwx_gtk_gl-2.4.so (libc6) => /usr/lib/libwx_gtk_gl-2.4.so libwx_gtk-2.4.so (libc6) => /usr/lib/libwx_gtk-2.4.so libwx_base-2.4.so (libc6) => /usr/lib/libwx_base-2.4.so

[seneca]

Originally posted by KingFish
Is it somehow possible to run two aMules on the same machine? I tried to, with different users and ports, works well, but I can't find myself as source then. I guess aMule rejects the same IP.. Any solution for this? (I only have this machine, so..)

Well, a sort of solution. We can make a file with random data - maybe  20 or 30 MB big - and share this via ED2K. Posting the link here is no problem and we'll be able to check upload chunk behaviour with each other's clients.

[KingFish]

Hi all again,
I just tried the out the latest CVS code (checked out January, 18th, 2004 ~09:00 am CET). Compilation ran smooth, also a lot faster than before! Thanks for speeding this up. Anyway, the resulting binary still seems fishy to me. I also ran it under gdb in order to catch crashs. None happened.
Well, uploads are working but are very unstable, no constant transfer rates, "kicking" of clients after short amount of time (I have an average upload time of ~1:30 mins then), as far as I've seen those "kicking" results in positive counting of 'Successfull transfers' in Upload statistics (About several hunderds to several tens of unsuccessfulls after short amount of time). That's exact the same behaviour I have since 1.2.3 and which people report me as not working because chunks aren't transfered completely or invalid (don't know though if they're really corrupted, people just reported me they won't complete). Before you ask: Yes, I have the 'Transfer full chunks to all uploads' option enabled. And my Slot selection is at 6kB, which should result in about 30 mins per complete chunk.
Now, to give you the stats with my fully stable working 1.2.1 build (official Debian package from your site): average upload time >20 mins (6kB per slot selected), totally stable transfer rates, no "kicking" of clients happening.
Both aMules ran on the same setup, temp files, shared files, same server connected to, same active internet connection. Also, my libraries match the development versions (wx* = 2.4.2, GTK = 1.2.10).
Please, please, pretty please, look into this behaviour! Don't know how you people see it, but I think uploading bugs are the most important as the whole network suffers from it.
So far, thanks for aMule and if you need any other information feel free to ask!

[Kry]

We're trying to fix. Thanks for the report 1.2.1 works.

[deltaHF]

hi KingFish,

tell me plz what connection do u have (max up speed) and what is your up limit in amule ?

[KingFish]

I have a SDSL line from http://www.qsc.de with 1024kbit down / 256kbit up (128/32 kB). I limit my upload speed to 30kB in total in aMule, 6kB per slot.

[deltaHF]

and your up capacity is set to..?

[KingFish]

To 30 kB also, not 32, because this way I can select 30 again from the systray without the need to go into preferences if I limited it down for a short amount of time.

[deltaHF]

so.. then up capacity & up limit both 30 kb/s .. right ?
works in 1.2.1 but doesn't work in cvs (or > 1.2.3) ?

what if u set your up limit a bit smaller than your up cap., lemme think.. to 28..

[KingFish]

So.. had to compile it again due to very fast fingers *cough*rm -rf amule-cvs/*cough*
Well, I have to test it for a while, but after about 15 minutes running the uploads seem much more stable to me. I've currently set line capacities of 115/30 and limit to 115/25 with 5 kB slot allocation. But the transfer rate calculation is much faster than in 1.2.1, maybe a little bit too fast (looks then like one client gets all, every others none.. But after a few updates it's balanced out).
If this really was the "bug".. What's the cause for this client kicking then? What's the best setting for me then (with line capacity/upload limit) as I want to upload as much as possible
And, is such (and maybe other "problems") documented anywhere? Would be bad if there are bug reports for non-existing bugs..

[deltaHF]

well, i w'll not call it as a bug .. seems it happens if ur trying to upload more than u can..
28kb/s limit and 4kb/s / client should be ok (and u have still some kb/s free for other things)

i have sdsl too (not qsc) and had my problems with upload too.. today i saw it wasn't amule related.. my provider cut my up speed from 150 kb/s to ~60 kb/s and i had still my old settings.. amule was trying to upload with ~100kb/s but i could give only 50 ..