linuxdcpp-team team mailing list archive

[MusicLover <musiclovr@xxxxxxxxx>]

Hey - much thanks for the follow-up, and only an hour after the file post, 
too!
We will definitely give it a try, and let you know, if the occasional 
infinite transfer still occurs.  Might be some time, though, as I have only 
seen it twice, since my report.

As far as we can tell, adding chunking hasn't broken anything, in unchunked 
mode ;-p  We switched it off, as soon as it showed-up (and thanks for 
providing that switch!).  We will be one of your unchunked testers ;) 
Here's the problem, with it:  remember, we do only single source transfers, 
world-wide, with some users still dial-up.  Depending on the speeds, and 
even more, upon the provider's smoothing algorithms and strategies, 
segmenting can increase transfer times by as much as 10-20 times, or more. 
Yes, under good conditions, segmenting may only drop transfer efficiency (on 
1-1 transfers) by a few percent (the overhead of a couple seconds for each 
chunk, to reconnect and reinitiate transfer).  However this is not so, in 
the worst case: the situation, for instance, where bandwidth looks like a 
comb.  In other words, as an example, the person who has 1mip service, but 
that comes as a 1 second burst of 10 mips, every 10 seconds.  This situation 
(and perhaps others), can cause someone with 1mip (average) to drop to under 
1kb chunk size, so:  wait for burst - re-connect - wait for 10 - request a 
chunk - wait 10 seconds (for next burst) - wait a couple more seconds for 
sender end to get chunk ready - wait for next burst - get tiny chunk - 
repeat.  I've seen 1mip users slide down to under 1k chunks, and get only a 
few k.  Flip off segmenting, and transfers return to 100k.  I'm sure it's 
great, for multiple source transfers (and smooth, constant bandwidth), but 
please keep that switch!  Ya just never know what some crazy end-user may 
want to try ;)

Thanks again, for the tool, the support, and the excellent feedback!
--------------------------------------------------
From: "poy" <poy@xxxxxxxxxx>
Sent: Sunday, May 16, 2010 12:01 PM
To: <musiclovr@xxxxxxxxx>
Subject: [Bug 572408] Re: sometimes,uploads continue forever - 1000s of % 
complete

> DC++ 0.762 is out, although still in testing stage. you should get your 
> people to grab it and see if it solves your issues.
> i would also recommend keeping segmented downloading on, as DC++ isn't 
> much tested with that setting off (if at all). DC++ automatically adjusts 
> the size of its segments, so there shouldn't be any problem with this.
>
> -- 
> sometimes, uploads continue forever - 1000s of % complete
> https://bugs.launchpad.net/bugs/572408
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in DC++: Invalid
>
> Bug description:
> All too frequently, uploads continue running past 100% complete. 
> Essentially, forever, until downloader clears queue, and cache, and 
> re-queues the files.  Server and client ,761.  Bug has existed for some 
> time, though.  Win7, on the server end (me) - but was same under XP. 
> Snap of 'finished uploads' included.
>
> I gotta wonder if the coder might not have typed ==, when he/she meant to 
> type >= ?  As in a compare to 100%, when the calculated % complete, for 
> example, might go from 98.77% to 100.01%.  That would make a forever 
> upload.
>
> tia, for looking into this...
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/dcplusplus/+bug/572408/+subscribe

-- 
sometimes, uploads continue forever - 1000s of % complete
https://bugs.launchpad.net/bugs/572408
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.

Status in DC++: Invalid

Bug description:
All too frequently, uploads continue running past 100% complete.  Essentially, forever, until downloader clears queue, and cache, and re-queues the files.  Server and client ,761.  Bug has existed for some time, though.  Win7, on the server end (me) - but was same under XP.   Snap of 'finished uploads' included.

I gotta wonder if the coder might not have typed ==, when he/she meant to type >= ?  As in a compare to 100%, when the calculated % complete, for example, might go from 98.77% to 100.01%.  That would make a forever upload.

tia, for looking into this...