Print

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

[btkaos]

Good job Stu! This was indeed a hard bug to catch!

You mean a windows installation, and not Wine, right?
No, but i have a windows XP CD, so i can install it, of course...
Is that what you are suggesting?
If so, should i do it in a specific way?

eMule is fully supported under wine, so I think you may try eMule in this order (from less effort and less fidelity to the original windows stack)

• Install it using Wine, it works flawlessly. (In fact some people prefer this setup to native aMule, let's hope we can fix that)
• Install windows using a virtual machine like virtual box, then install eMule there
• Install windows native. Note that when you do that, it may destroy your Linux installation or at least overwrite the boot sector, then you surely need to boot with a rescue CD and run grub. Proceed with care.

[btkaos]

Anyways, if I understand the issue correctly, this bug was exposed by an incorrect configuration on RRM's part.

That is to say, your upload setting was bigger than the real upload capacity of the network, this is the cause of the packets queuing up. Now the Stu patch checks that the socket has finished.

The current code may have a small issue, however, it is, it doesn't allow to queue any data in the socket, I wonder if this will have some negative impact in upload throughput. Maybe the upload thread should keep queueing packets to upload up to a certain limit (2 or 3 packets already in queue)

Maybe the eMule guys don't support this scenario (upload > real upload capacity)

[RRM]

Im running eMule using Wine.
Using the same settings.
It takes a while before all files are hashed...

[Stu Redman]

Anyways, if I understand the issue correctly, this bug was exposed by an incorrect configuration on RRM's part.

Not really. If we allow upload speed "0" for max, it is supposed to work. And the bug would also occur if a correct max up speed is configured, but the downloaders are unable to download at that speed (improbable, but possible).

I wonder if this will have some negative impact in upload throughput.

My tests showed that the set upload speed is still reached exactly, and at 0 it meets something close to my physical max up speed. The bottleneck is not how fast you provide the data to the slots, but rather the physical speed of your line. And if the upload bandwidth throttler can't assign enough data in one cycle it is saved for the next so it averages out.

Im running eMule using Wine.

Now this promises to be interesting. 

[btkaos]

Not really. If we allow upload speed "0" for max, it is supposed to work. And the bug would also occur if a correct max up speed is configured, but the downloaders are unable to download at that speed (improbable, but possible).

Anyways if the socket signals when it's ready to send more data, a fully event based throttler could be implemented. Of course I don't know what level of source compatibility with eMule is desirable.

I recall to see another aMule out of memory crash when losing temporal connectivity (such as failure of wireless LAN) The backtrace was this, I'll test your change and see if it helps:

Code: [Select]

#0  0x005dc422 in __kernel_vsyscall ()
#1  0x004394d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x0043c932 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x0832191d in OnUnhandledException () at MuleDebug.cpp:103
#4  0x003d7415 in ?? () from /usr/lib/libstdc++.so.6
#5  0x003d7452 in std::terminate() () from /usr/lib/libstdc++.so.6
#6  0x003d7591 in __cxa_throw () from /usr/lib/libstdc++.so.6
#7  0x003d7c0f in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#8  0x001d3463 in wxObjectList::CreateNode(wxNodeBase*, wxNodeBase*, void*, wxListKey const&)
    () from /usr/lib/libwx_baseu-2.8.so.0
#9  0x001e5d4b in wxListBase::Append(void*) () from /usr/lib/libwx_baseu-2.8.so.0
#10 0x0023f8e0 in wxEvtHandler::AddPendingEvent(wxEvent&) () from /usr/lib/libwx_baseu-2.8.so.0
#11 0x00b0f920 in wxSocketBase::OnRequest(wxSocketNotify) ()
   from /usr/lib/libwx_baseu_net-2.8.so.0
#12 0x00b0fa14 in wx_socket_callback () from /usr/lib/libwx_baseu_net-2.8.so.0
#13 0x00b14a8b in GSocket::Detected_Write() () from /usr/lib/libwx_baseu_net-2.8.so.0
#14 0x010b1427 in ?? () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#15 0x009e9f7c in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#16 0x0134adab in ?? () from /lib/libglib-2.0.so.0
#17 0x01313e88 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#18 0x01317730 in ?? () from /lib/libglib-2.0.so.0
#19 0x01317b9f in g_main_loop_run () from /lib/libglib-2.0.so.0
#20 0x07586419 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#21 0x010afc78 in wxEventLoop::Run() () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#22 0x01142e3e in wxAppBase::MainLoop() () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#23 0x01142a31 in wxAppBase::OnRun() () from /usr/lib/libwx_gtk2u_core-2.8.so.0
#24 0x001da7aa in wxEntry(int&, wchar_t**) () from /usr/lib/libwx_baseu-2.8.so.0
#25 0x001da987 in wxEntry(int&, char**) () from /usr/lib/libwx_baseu-2.8.so.0
#26 0x08229dfb in main (argc=1, argv=0xbffff4f4) at amule-gui.cpp:94


[RRM]

It may well be however that the underlying networking layer in Windows behaves differently than wxWidgets/Linux, so eMule may not be involved.

You must be right, because eMule (E) under Wine is still running
in exactly the same conditions (all the popular uploads etc; "foot on the gaspedal" settings)
as they were when running aMule (A).

There is something strange going on though:
Both in A and E "clients on queue" is 0,
but in A everybody waits for 0 sec,
whereas in E, a whole bunch (about 50%) "waited" 1 sec,
and the other half "waited" anything between 6 minutes and 9 hours...
I guess E's "waited" is screwed as A's was?
(There is no slot-reallocation after every 10 MB or so (continuous uploading), btw)

I have another system with XP only.
You want me to try that one running E?

[RRM]

since i experienced the same issues when i still used eMule,
and with me many other users,

Im sorry, that was a false/incomplete recollection.
Before service packet 2, E under XP crashed often, but i cannot recall how often.
Since service packet 2, by default Windows allows only 10 simultaneous connections.
Installing a special patch, one can raise that to 50 max, (which needs to be reinstalled after every W update)
but that naturally still severely limits up- and downloading capacity.

Given those limitations, it doesnt make sense to test E under XP, right?
When i buy a new system (coming with Windows 7), i will test eMule under W7
before installing Ubuntu.
...
Hmm, it seems that W7 also allows 10 simultaneous connections max.
Thats a big + for Wine then... (no such limitations)

[Stu Redman]

Since service packet 2, by default Windows allows only 10 simultaneous connections.
Installing a special patch, one can raise that to 50 max, (which needs to be reinstalled after every W update)
but that naturally still severely limits up- and downloading capacity.

IIRC only half open connections are limited, so you can't ask sources as fast as you could otherwise. But eMule (and aMule) take care of that. I'm running aMule on Windows most of the time and have no problems, even without a patch.

If eMule doesn't exhaust memory under WinE then it doesn't have the problem. Good for them.  I don't think it's necessary to run it under XP too.

[RRM]

Ah, ok.
And that the "waited" is screwed in eMule,
should that be mentioned?

Btw, i used to use 'the old eMule' this user refers to in your "notification thread"
in the eMule forum

The newer eMule versions still suck if you compare their upload to the old (non-Kad, non-threaded) ones though I fail to understand the reason behind that.

I thought that the decrease in uploadcapacity was due to Windows Service Pack 2,
but i guess i was wrong.
Anyway, i have my full upload capacity back with aMule!  

[Stu Redman]

And that the "waited" is screwed in eMule, should that be mentioned?

I'm sure they have given their upload queue handling some thought, I won't interfere there.

Btw, i used to use 'the old eMule' this user refers to

Hmm - what version? I thought of course you had used latest stable 0.49c.

[RRM]

OK, i understand.

what version? I thought of course you had used latest stable 0.49c.

I dont mean the one i tested under wine (which indeed was 0.49c)
I was referring to before i started using aMule.
Back then i upgraded eMule with each new version available.
At a certain point the upload capacity decreased significantly.
I thought that was to blame on Windows (service pack 2),
but it may have been something else, of course.

Now that ive noticed that Ubuntu-aMule and WinE-eMule perform equally well,
it may be interesting to see how well XP-eMule performs,
in comparison...

[RRM]

      WHAT WAS I THINKING ??    

Testing WinE/eMule in comparison to the Ubuntu/aMule combo was fun, with good results.
So, i thought i would give XP/eMule another chance too...

Obviously i had forgotten the reason why i switched to Ubuntu: pure frustration.
Frustration that XP/eMule could never utilize the available bandwidth.
Testing it yesterday and today (with the same setting and files, naturally)
it made me frustrated once again:
It takes sooooo long before XP/eMule has reached peak upload,
and the results are sooooo disappointing: 430 kB/s max!!!

Switching back to sweet aMule,
the very first client accelerates from 150 to 400 to 890 kB/s download speed within seconds,
and the next couple of clients start consuming as well.
Its so good to be back and watch aMule running....  

[Stu Redman]

Would you like to test sweet aMule on XP for comparison? 
You can get one from http://amule.jimdo.com/
Now this could become really interesting...

[GonoszTopi]

Would you like to test sweet aMule on XP for comparison? 
You can get one from http://amule.jimdo.com/
Now this could become really interesting...

For that you should first provide an executable from r9913 or later 

[Stu Redman]

Pre-9913 fails only after a few hours, while the speed is visible instantly. 
And actually I'd like to see if it exhausts its memory on Windows too.