Alo Sarv
lead developer

Donate via
MoneyBookers

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
irc.hydranode.com/#hydranode

Friday, September 23, 2005

Testing

Been mainly testing-day, focused on win32 port. From what I can tell, everything's working on win32 as good as it does on linux. Interesting note tho - hydranode uses around 2-3 times less cpu on windows than on linux. And that's when built with GCC - rebuilding with MSVC adds another 30+% performance improvement :).

A thing about those speed-o-meters ... we'll need to lower the resolution - they'r too sensitive for anything right now. Currently their set to 100ms precision, 1-sec history, but this results in a lot of rate fluctuation, since in real world, network transfers are never stable, you get 5kb now, then 2kb in half a second later, and so on, so basically the trick is to average everything down to some level where it "stabilizes". For example, the statistics lines printed every 10 seconds (yes, you guessed it - 10sec averages) - show rather steady rates, while the rates on the "statusbar" fluctuate widely. Anyway, I think we should go somewhere along the lines of 2 or 3-sec averages, with 50ms precision. This will mean 20*3*4=240 bytes history data stored for each speedmeter - no mentionable overhead.

Other than that, I'v been thinking on how to design/implement the client/upload management in core. Basically, first we need some kind of BaseClient structure, that will incorporate various details about the client (network, ip addr, client soft et al). This will also be visible to user interfaces. Then we need some kind of UploadManager, to which modules wishing to upload to other peers register themselves, and the UploadManager will then open up upload slots (based on module priorities, current transfer rates et al) as needed. UploadManager will also need some kind of method for closing upload slots (when there are too many of them, or dead slots, or similar). DownloadManager, in turn, will need to act as global cross-reference table for file <-> client (again, needed by user interfaces). Then again, we might just merge UploadManager and DownloadManager into central ClientManager, which handles everything (in core).

Madcat, ZzZZ

PS: Updated builds are available at http://hydranode.bytez.org/r1942/
Edit: The win32 zip was broken, and was re-uploaded now. Re-download if it failed to unpack.



Comments:
Of course, remember to keep it compatible with networks that do uploading differently, for example DC where you must have a constant number of slots, and where you must open a slots for small transfers such as filelists and TTH trees
 
Any kind of protocol overheads (including things like fileslist and TTH trees) do not count towards upload slots (but they do count towards upload speed limits ofcourse). And yes, the API will need some way to handle explicit slot requests. I didn't know DC needed it (thanks for pointing that out), but I was thinking about FTP uploads and such.

Madcat.
 
And think about anonymous networks that don't specify packet destinations by IP but by some other identifier.
 
I hoped the BT module was included in the new test build....
Anyway, howto "move" ed2k downloads from MLDonkey to HN ? (without loss of not complete chunks of course)
 
There's no mldonkey import support yet. You can import them manually (if they aren't too many) by starting the same downloads with hydranode, and then copying over the .tmp file from mldonkey (don't know what extension mldonkey temp files have).

Madcat.
 
Thanks for the Linux build, Madcat!

TheSilva
 
The BT module is included, run bget [torrentfile]
 
r1942 runs good atm. And only ~10MB memory usage :D
 
Are you sure that .tmp files can be readed by HN? The problem is that I have 3000+ downloads in MLDonkey? It's possible to add support to import it in the future or is a too complex task? It could be nice for doing migration easier from different P2P apps...
 
BT module is not a module actually, it's bget. I hope it will be a module when all torrent support being mostly supported...
 
Why Hydranode is a lot faster in m$ windoz? Thinking about it mades me mad and scream all time...
 
Windows, as a platform, is considerably faster than Linux on lower levels; generally you don't notice it, because windows developers optimize their apps based on Windows performance, and Linux developers based on Linux performance, and both stop at roughly the same level, which means they perform roughly the same. However, in case of cross-platform apps, the difference becomes apparent - already ~6-8 months ago, when Hydranode was using ~20% CPU on linux, it was still using ~5% on Windows; as I kept optimizing it to get the CPU usage down to acceptable levels on Linux, the CPU usage on windows became near-zero as a result.

The biggest culprit in CPU usage is the f***ing gettimeofday() syscall; 60% of CPU time is spent in that syscall, but on Windows, it's not a syscall it seems, but rather simply returning some pre-set variable, which makes it considerably faster (especially if the compiler can inline most of the function calls).

Hydranode isn't the only application showing this trend; Firefox, for example, runs considerably faster on Windows compared to Linux as well.

Madcat.
 
Why that isn't fixed on linux then? It seems too crap thingie...
 
Post a Comment



<< Home

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