Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Friday, December 16, 2005


Been a day full of really wierd things, none of which make any sense. Chemical has been complaining that Hydranode does extremely bad upload performance recently, like constantly failing to start uploads, or uploading only few hundred kbytes and then stopping and so on. Naturally, I took a deep look at the trace output, and looked at code, but couldn't determine any possible cause for this behaviour, and I was unable to reproduce it either. Even went as far as to test and run his Hydranode build on his box, and it worked perfectly when I was testing it. Oddness.

Another thing that's bothering me is that iptraf (a linux network traffic monitoring tool) actually reports about 10kb/s higher transfer rates (both for upstream and downstream) than Hydranode internally. At 10kb/s upload, 80kb/s download according to Hydranode, we seem to be doing 24kb/s upload and 95kb/s download rates. Naturally my first thought was that something else is using bandwidth, but as soon as I stopped Hydranode, traffic dropped to 1-2kb/s, so nothing else is using the traffic for sure. I tried to determine if our speed-o-meters are mis-calculating, but everything looks correct there as well. Even the 10s averages, which are calculated independantly from speed-o-meters agree with the speed-o-meters, but not with iptraf. Strangeness.

As for bounty/goal-based donations, as many have requested, I'll think about it. In general, I think it's a good idea (and has been under discussion before), but the actual implementation might be bit trickier. For now, I think it's sufficient to just drop me a mail or do a forum post a'la "Fix this bug, offering $xxx". Other people could also support the same bounty, adding offers. Actual money transfer happens when the bounty is completed, to whoever completes it. This will be based on the assumption that the bounty creator is a honest person and actually intends to keep the offer/promise. This also results in automatic "trust" system - someone who sets a fake bounty once won't be taken seriously the next time, so there's not much point in making false bounties. It's not that I'd think any of you around here would do something like that, but there's an evil world out there... Also those who have a reputation of setting and keeping bounties will most likely be taken seriously and bounties completed faster.

Anyway, been feeling kinda half-asleep the entire day (really crappy weather outside is probably the cause); did numerous attempts at various features/optimizations - automatic inter-module dependancy tracking (for example if BT module requires HTTP module, BT module loading would automatically trigger http module being loaded - similar to how Linux kernel does it), ed2k parser optimizations (lowering the amount of exceptions thrown); however for some reason, all those got screwed up around half-way when I realized I went completely wrong with the code - good idea but the implementation just sucked. So I guess I should get some rest instead.

Madcat, ZzZz

you can always try the open source bounties site
people can setup bounties and pledge money in a more trusted way
Have you tried with other traffic monitoring tools? Perhaps it's just a bug in that testing program.
Kitty, check your packet send/queue/etc. That was the bug on aMule (and btw, azureus have it) till we used the bandwith throttler to fix it. If you're recording your bandwith when qqueuing instead of when actual sending, you'll see that behaviour.

Notice I have nfc of your code, it just did sound familiar ;)
Sorry not a c++ guru here but following Kry's suggestion
what's the meaning of this (strangeness?) in doSend() in schedbase

*m_obj->m_upSpeed += ret;

Why does the first line even compile?
Kry: I am recording the speed on the values returned by ::send() syscall, e.g. how much was actully written to the underlying platform socket.

Anonymous: Yes, that's valid code. m_obj->m_upSpeed is actually a pointer, so with the additional parenthesis, the line would read:

*(m_obj->m_upSpeed) += ret;

However the extra parenthesis can be dropped, since there's only one element within them.

Could be overhead casue by transmission errors?? Control packets (Yes it is quite strange , too much difference)
The measurement can't be that much off. I have 24kb upload on my line (192kbit) and I set HN to upload at 22000 b/s and when maxed out it always showed something like 21,5kb/s. There is no way I could ever have much more than that as I always was able to use the web properly. I did not use any other software or stuff to measure the real speed, but I can't upload faster (tested with other programs)!
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?