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, September 02, 2005

Debugging, and we need a new ChunkSelector(tm)

Yesterday, I finished testing some of the patches that might have had side-effects for ed2k module, namely changes in PartData and SharedFile classes, which were required for the BT wrapper classes (basically just making some methods protected/virtual, but as well some functions splitting and added signals). So far, no regressions were detected, so the patches are now in SVN, and bget utility should be fully compilable/runnable.

Today I spent quality time further debugging and improving the BT module. Namely, .torrent file parser got some fixes into it, it now properly handles files in subdirs, and recognizes various other hashes for the files as well (ed2k, sha1, md4, md5). Also, in files.cpp, the forwarders were rather broken in some cases, which was fixed today as well.

However, BT exposed a weakness in PartData api, namely in ChunkSelector(tm), which, as the name says, decies which chunk should be downloaded next. The problem is the performance of the ChunkSelector - it was built while implementing ed2k, and was performing sufficiently fast for <100 chunks. However, in BT, we'r dealing with thousands of chunks - even a 150mb torrent with 256kb chunksize is already nearly 600 chunks. Hence, we need a LOT faster chunk-selector. And performance isn't the only concern - the new BT code also exposed that the chunkselector isn't actually working as good as it was thought to be - the selection of chunks it does isn't what I had in mind.

Also, I found one tracker that tells me to "upgrade your client". No info is yet known what exactly didn't it like about my Client <-> Tracker communication implementation, but I'm guessing some things mentioned "optional" in protocol specs aren't so much "optional" after-all.

On other news, some of you might have noticed a considerable increase in CPU usage between 0.1.1 and 0.1.2 releases (my personal tests show ~2x higher cpu usage in the latter version). I was somewhat concerned about it, but couldn't pin-point it's location. Today I did some tracing, and tracked the problem down to write() syscall, which increased from 38% to 87% time between 0.1.1 and 0.1.2. My first guess was PartData::flushBuffer() method, most likely the recently-added explicit fsync() call in there, but it doesn't seem to be the case. So the issue is still open, but we'r one step closer to actually getting it fixed.

Madcat, ZzZz

Comments: Post a Comment

<< Home

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