force check seems slow, and what was my surprise when renaming an avi file to force redownload, first starting got error, normal I thought, saying recheck ; I forced recheck, and by a sort of "miracle" 31.6% of the file was already downloaded!?? the most likely is bogus hascheck routine giving random results from time to time ; it can do lot of harm to download rate, forcing chunks to be drop with false "corrupted status"... Edit :Oh boy, the file was only a part of the torrent, so, there was actually 31.6% already downloaded!!! hum, what about the ramping of UL rate? It took 10-12 minutes to get a cruising speed for UL, that was lower than 2.2.1 speed (UL) ; after three quarters of an hour, UL rate decline to 15% of it's former value ; it took 20 minutes to ramp up to the "quite good" speed ; DL speed dropped down every 20 seconds, and could not overcome 500 KBps, I think it comes from too slow UL rate? with 2.2.1 I used to put an UL cap 10 KBps above my UL bandwidth, in order to assume better sharing ratio (important on private trackers) ; with 3.0, I can put the cap twice above the UL bandwidth, it works all the same than 0 (= nolimit) ; no trick to force UL rate to reach a prechoiced value! I guess new ramping algorythm is aiming at a fast free up of bandwidth for other applications, but a "cross-fader", a glider like this poping up when clicking on the speaker icon nearby the system-clock, would allow a user to tune ramping throttle very fine, from 2.2.1 like settings, to 3.0 like settings ; and by the way, reporting the average rates of ul and dl to a server (with the corresponding tuning settings), one could then do some statistics analyse to find out if a peculiar setting gives a maximum of DL/day!