clocking your download speed before file transfers

wing-wang · Post by **wing-wang** » 2003-07-09 15:46

A good feature (in my mind) to add would be some sort of way to clock your transfer rate from clients before downloading. I've ran into this almost 80% of the time i try to dl something; mr i have a dual t3 and 6/6 open slots gives me 456b/s when mr waaaa i have a 28.8kbps dial up gives me 3k/s.. and then some random dude with 768x128 adsl gives me 20k/s but other mr dude with same 6/6 open slots and con. gives me 3b/s, then there's all this talk about cable being the 'l337' way to go.. right.. i have yet to find anyone with a good cable connection(assuming that's what they really have).... it'll take me 5days4hours blah blah blah to finish a 3mb file, but i just found this out after spending 20 minutes looking at their list queing up all sorts of stuff to find... the booty transfer rate of death!%$!#% ahhhhhhh... derp! If that isn't bad enough, i/we then have to find more sources (that may not even have sfv's[bleh]) until finally someone comes up with a somewhat decent transfer rate.(which takes awhile for some reason) If there was a way to add a command to check transfer rates it would save myself and others (i'm sure) a lot of time queueing up 10 gigs to find mr i supposedly have t1 really only has a 14.4. thanks for your time, consideration and trying to take over the irc crowd (i've been waiting for something worthy enough to replace it) to ensure that things still remain free. keep up the tedious coding.

qqzm · Post by **qqzm** » 2003-07-09 15:53

And the Oscar for longest sentence ever goes to....wing-wang!

How exactly do you suppose the client calculates the trasfer rate before it starts the transfer? This won't be possible to implement until those new psychic routers are available that Cisco are working on...

TheParanoidOne · Post by **TheParanoidOne** » 2003-07-09 17:46

The only part of that post that is a feature request is the first sentence. The rest just seems to be some sort of rant.

I seem to remember something like this being discussed recently but I can't remember an which thread it was in. I suggest you search for it, as there has already been a discussion on the pros and cons of this.

Post by **GargoyleMT** » 2003-07-09 18:41

Yup, there are at least two real possible solutions to the "problem" that downloading from person A isn't as fast as downloading from person B:

Multisource Downloading
Dropping sources below a certain speed
Rotating among alternate sources, and settling for the fastest (thread by Wisp - this is only a specialized case of the above)

W00T W00T. Keep the redundant feature requests coming! <-- heh

wing-wang · Post by **wing-wang** » 2003-07-09 18:50

dude... i need to get me one of those psychic cisco routers

Post by **GargoyleMT** » 2003-07-09 18:57

wing-wang wrote:dude... i need to get me one of those psychic cisco routers

Now if only they would merge functionality with PeerCache...

dominyx · Post by **dominyx** » 2003-07-12 22:16

The program already keeps track of the current up/download, why can't it just display that for each user? That might not be perfect, but it could give you a good picture of the real speed of their connection... just my two cents.

jbyrd · Post by **jbyrd** » 2003-07-14 07:15

The program already keeps track of the current up/download, why can't it just display that for each user?

You would want dc++ to send small transfers to each user and display it (If I understand you correctly).

This, I believe, would sacrifice too much bandwidth to justify the benefit...and it would make search results take MUCH longer to load.

Wisp · Post by **Wisp** » 2003-07-14 10:42

dc could download a test-file of 300kb, then checks the time it took and calculate the transfer speed

wouldn't this be an option?

I mostly download the filelist to check the speed, but sometimes the filelist is too small to see it transferring

jbyrd · Post by **jbyrd** » 2003-07-14 10:58

One problem is that many times, depending on the upload and/or download connection types, the download could start fast and then drop off to almost nothing.

The method is not truthful.

Wisp · Post by **Wisp** » 2003-07-14 10:59

jbyrd wrote:One problem is that many times, depending on the upload and/or download connection types, the download could start fast and then drop off to almost nothing.

The method is not truthful.

dc could measure the average rate, and offcourse it's not 100% reliable, but it's better than nothing

jbyrd · Post by **jbyrd** » 2003-07-14 11:45

A feature that is not reliable and misleading won't be included in the main dc++ code. Your best chance is one of the modded ones.

Wisp · Post by **Wisp** » 2003-07-14 11:59

jbyrd wrote:A feature that is not reliable and misleading won't be included in the main dc++ code. Your best chance is one of the modded ones.

the option "Maximum download speed to start new downloads" is also not 100% reliable, but it's still added in DC

dominyx · Post by **dominyx** » 2003-07-15 00:19

Hmm, that was not what I was getting at. When your running DC, it displays your current upload and download on the statusbar. I'm not sure how the DC server works, but perhaps the server could update a list of the current up/down every 20-30 minutes from every user. I don't know, just kicking ideas around...

jbyrd · Post by **jbyrd** » 2003-07-15 08:53

The actual amount that each user has uploaded/downloaded? Or the speed? The download statistics wouldn't benefit anyone.
Again, the upload statistics would use bandwidth.

You may want to bring it up in the DCH++ forum.

dominyx · Post by **dominyx** » 2003-07-15 10:17

Yeah, I don't know what I was thinking about the downloads. But I don't see why the bandwidth would be such a problem, if the speed is only updated every 30 minutes or so. It can't be that difficult to append the filelist with some short speed statistics...

SirPlus · Post by **SirPlus** » 2003-07-15 10:26

Are we making it too complicated?

How about a much more simple solution

If we have multiple sources and we are not happy with the current one then we double click on the unsatisfatory download and it goes to the next source. It could even try the next one and so on back to the first if the new one is one is below the speed of the first.

There could be an timer delay of say 2 minutes minimum on the one source to allow it to settle down again and stop everyone from becomming too click happy. It could stop once it found something -say 50% (or more) better. If this process were manually initiated I don't think it would bog things down too much.

I know if you had this working on more than 5 sources and it took more than 10 minutes to get back to the first that you might have to wait for the source again but that would be a considered risk you would balance against being impatient. Perhaps if you double clicked again it woiuld end the process and zap you back to the fastest connection discovered.

It would also mean I might get my slot quicker if I were patient!

jbyrd · Post by **jbyrd** » 2003-07-15 10:57

It can't be that difficult to append the filelist with some short speed statistics...

Just download the filelist...check in the finished download folder and it will tell you the average speed of the download.

What I thought you were saying was displaying the upload speed in the search window. By having to update every 30 minutes, in a hub with 1200 users, the increase may be appreciable. If it were accurate, it may be worth it, but since it's not...it's not.

If you want a fast upload speed, your best bet would be to find a user that reports a 56k connection. Chances are he is running a T3 and no one is using his slots.

Post by **GargoyleMT** » 2003-07-19 14:11

dominyx wrote:I'm not sure how the DC server works, but perhaps the server could update a list of the current up/down every 20-30 minutes from every user. I don't know, just kicking ideas around...

The hubs don't know anything about transfers, nor speeds from user to user.

Having them collect these statistics is not a sane idea.

Please, enough speculation about how to implement this (or any) feature, unless you're going to pick up a copy of Visual Studio and code it.

You tell us how you want the feature to behave, and we tell you if it's possible or not. That's how it's supposed to work.