upload

[flitox]

hi,

anyone experiencing weird upload behavior from 2.6??

since i've reinstalled 2.6, i'm noticing that shareaza is taking more upload bandwidth than it should. if i look at my load speed, shareaza says it sends a 1.83 KB/s (i've set limiter at 20) but actually shareaza is taking nearly 40KB/s from the total bandwidth. i also seems not to have that many people in the queue but keeps on sending for only a small period of time and then i'm sending to someone else, still at a shitty speed while using plenty of upload.

i've also tried to reinstall but it remains the same

[flitox]

still getting those wreird upload usage by shareaza while sending nothing!!
do i have to reinstall it over ver 2.5.5 like i did the first time in order to work???

also i'm again getting the so annoying 'your behind a firewall or a router' on the shareaza's home page, despite not behind both of them, ports have been opened for my router, firewall rules are to allow any connection for shareaza and of course the connection test is good.

and also i cant use the 2.6.0.1 debug version on my computer, it just took ages to load, close with a very high cpu usage making it unusable. this is an fact the reason why i had to reinstall 2.6 in the 1st place

[flitox]

so you guys have nothing to say about this????

[old_death]

Well... how did you measure the bandwidth? I've never seen such a difference between the actual settings and what Shareaza really uses.

[brov]

Most likely you're in Hub mode.

[flitox]

i use cfosspeed software, so i have a number for the total used bandwidth.

i've been using shareaza for like 10 yrs + and too i've never seen something like that. usually the problem with upload was that shareaza was going over the set limit and upload faster that it was asked too but here, i can get 40 KB/s upload traffic while having no transfert going on (and barely no transfert down)!!!

nope i'm not in hub mode, i've set it to leaf mode anyway

[flitox]

let's bump, cuz i'm still having this behavior each time i use shareaza.

so let's recap:
shareaza using plenty of upload bandwith (a bit more than X2 the actual limiter) despite having not much activities here. when it does emule clients get connected for only a couple sec, saying things are send at around 4/5 Kbps but still getting credited a couple Mo (which is surprising, how could i send so much data in such a short with that speed!!!)
G2 client seems to behave normally but i have the impression i just send data to some not that very often now.

happened since i reinstall 2.6. 1st install was over 2.5 last version > no problem but because of the download now i decide to try the back then latest test version which hardly worked here so deleted it and did a clean reinstall 2.6 and since the upload is fucked up no matter if i disinstall/reinstall.

i'm even considering to put back 2.5 and try to install 2.6 over it to see if it changes something...

[old_death]

How many connections do show up in your neighbours tab? If there are more than 3 lines starting with blue icons in there, you're probably in hub mode, which means your client has been selected to do network maintenance duties. Have you by chance recently gotten a new computer or a better internet connection?

[flitox]

hi old_death,

nope i'm not in hub mode, 1 have 2 G2 connection, 3 G1 and 1 edonkey, as usual i should say.
internet connection is still the same speed and i didn't got a new computer.

[ailurophobe]

I am seeing something similar, but maybe even weirder... Shareaza is uploading to ED2K (I can see that on the networks tab... and network congestion), but the ED2K transfers are not visible on the transfers tab and the bandwidth used for them is not included in the total upload. Don't know if that is related, but I'd check the ED2K for the extra upload if I were you.

[flitox]

yep ailurophobe, i agree with you, it's most likely edonkey related.
one other werid thing i can see is that i don't have people in the donkey queue, when i send data to someone, when i have the time to expand the list (not always the case), he is the only one in the list!

and of course like you, the xtra bandwidth usage is not shown by shareaza, since i apparently don't send data, it's moving from 0.01KB/s to ~0.4/0.5 KB/s but cfosspeed is telling me that the upload bandwidth usage is around 14 up to 20/25 KB/s.
if i run utorrent at the same time, i've always around that number missing from max upload and as soon as i close shareaza, i can upload with utorrent at max speed set.

quite annoying but at least i'm happy i'm not alone here

[old_death]

You could try what happens if you completely disconnect from eD2k... If the weired behavior were to stop afterwards, this would be proof for what you and ailurophobe are suspecting.

[flitox]

i'll try what you suggest Old_death. right now, only one files downloading and no extra upload (with edonkey enable) but that just because nobody seems to be interested in downloading it so i'm going to add some more popular files and see what happen.

can you tell me what that advance setting is for: uploads.throttlemode
it is set to false and i cant put it back to default (well i can but as soon as i close/reopen the setting windows it goes back to false)
i'm here trying to understand why my edonkey uploads only last a couple sec when being seen in the download window. i just saw someone getting some file i have in my library and again it disappeared as soon as it arrived!

[flitox]

so i did try to disconnect some network

only g2> no excess upload usage
only g2+ g1>no excess upload usage
only edonkey > excess upload usage

all connected but i disconnect from edonkey> the excess upload usage continue but stop after a while

also the excess upload doesn't appear as soon as you connect with edonkey but nearly as soon as you as you start uploading files.

now i don't know how this is accurate as since i got that fucked up behaviour, i barely see any upload done on g2 so i cant be sure it doesn't happen with the other networks

and by the way, the message on the shareaza's front page saying i'm firewalled or behind a router (despite i'm not) only appears if i connect to g2!

[ailurophobe]

Shareaza firewall detection uses G2 hubs so it does not work if you are not connected to G2.

I also had a lowID (due to ISP changing some stuff without telling me, they'll happily send ads for services I can't use though..) and fixing that helped performance a lot as much of the "excess" seemed to be push connections to ED2K clients. It also solved a BitTorrent upload problem I hadn't noticed I had.

But ED2K upload still doesn't work. Clients connect properly, three pipelined requests are uploaded just fine, and then the connection is dropped for unknown reason. This is obviously inefficient in the extreme and keeps the queue empty since uploading three frames doesn't take much time.

[flitox]

thanks for the explanation for the firewall detection.
with edonkey, i'm getting a high id

[ailurophobe]

Got ED2K upload working. The problem is that the default value for eDonkey.FrameSize is too high. It is now 512kiB, when the old value was 90kiB. I set it back to the old value and ed2k upload started working.

@ryo:
Can you confirm this is not some weird installation failure on my system and, if not, fix this in debug?

[flitox]

i can confirm what ailurophobe said in his last post.

i changed the setting for edonkey.framesize back to 90 and miracle uploads work at it was before

[raspopov]

Shareaza uses same code to limit bandwidth in all supported protocols. "eDonkey.FrameSize" option used only for initial dividing of whole uploading file by chunks (as required by eD2K protocol). After that all chunks transmits via TCP-connection sequentially together. So this option has no effect on bandwidth.

[ailurophobe]

[raspopov]

Fixed. That was wrong: ticket #195.

[ailurophobe]

LOL. So in a roundabout way it was all MY fault...

Anyway, I am running with framesize of 90kiB just fine, so I doubt it needs to be 10kiB to work. I did some testing and turns out the 90kiB value I used because I wrongly remembered that was the previous default is the highest value that works. This is probably because that happens to be the default request size used on ED2K. (That is where I got the number, I confused the two settings and didn't notice it, because it happened to work...)

So I am guessing the actual rule is that the frame size has to be smaller than the eMule default request size, which is 90kiB, or eMule will assume the download was corrupted and drop the connection. I guess the check was added after the guy who made the feature request tested with the 510kiB value... So higher values used to work, but no longer do.

EDIT: So values that work are probably: 10, 30, and 90. Maybe 15 and 45, as well.

[raspopov]

Yep, its strange. BTW RequestSize (how much data client requests per single request) and FrameSize (how actual data transmitted as ed2k-packets) are different options.

[sharebare]

Thanks for the info. I was having this problem as well. I have been using Shareaza for over 10 years and have never seen this occur before. I did not change the frame size on my pc. I have just installed Windows 8 64 and dual boot with Windows7 64. I installed the newsest build of Shareaza 64 and immediately had this problem where edonkey connected to upload for about 3 seconds then disappeared, and new peers would connect for me to upload to them and would disapear. DC++ would connect for 3 seconds then freeze. G2 would connect and after 3 seconds would slowly taper off to 0kb uploading and freeze. I tried everything I could think of. It would work fine when I booted to Windows 7. I finally got fed up with trying to troubleshoot it myself and did a internet search, and viola you cured my woes. It is very strange that an edonkey framesize setting affects Edonkey, DC++, and G2 upload connections. Also this was a fresh install of operating system and shareaza, so it was either the default setting for the install, or querying Discovery and loading DC++ hublists changed settings. I have not changed any default advanced Shareaza settings untill just now setting the edonkey.framesize from 512 to 90. Anyway, I am glad it is fixed now.

Thanks again,

Tom

[drstuckforhelp]

I also changed the setting for edonkey.framesize back to 90 and uploads started working again.

But my upload connections are still aborting after a short time, as described here.
viewtopic.php?f=7&t=1569

[raspopov]

Answer is here.