I have a 1.5mbit/s cable connection, however my max upload is 14kbit/s.
This poses a problem, a problem I think allot of users may experiance, for uploads can greatly slow downloads, even with 'small send buffer' on.
Would it somehow be possible to integrate a 'soft' upload limter into DC ++. This would be one where the DC++ client decides (not the user) what the upload limit is, on a basis of the most efficient upload/download ratio.
I have seen that when certain people upload form me they somehow leach my upload to the max, as a result my dowlnload speed drastically falles form 80kb/s to 564bit/s. However what I have noticed is that if aprox. 14% (2kbit/s) of my upload limit is free for my download to use then there is no reduction in download speed.
Taking a look at this, lets say 3 people are uploading from me then they would share a total bandwidth of 14kbit/s, however my downloads would be greatly slowed. With a 'soft' upload limiter the shared upload speed would only fall from 14kbit/s to 12kbit/s being a decrease of only 0.66kbit/s per user, this without comprimising my download speed. In the end it is a win-win situation, I get to download more fatster thus enabling me to share more. Which in turn means that there more files avalible for others to upload. Multiply this by all the users who have the same problem as me.
A possible way for DC++ to calculate the upload limit it should impose, is find how many uploaded bits are need for however many downloaded bits. This can then be converted into a ratio. From this ratio one can calculate how much upload bandwith needs to be reserved for downloads, and how much can be set free for uploaders.
A 'soft' integrated Upload Limiter for DC ++
Moderator: Moderators
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
What happens when someone has no downloads in DC++?
In that case, the best outcome would be having DC++ learn what your upload capacity is and adapt. It can collect data about speeds every second, but then don't you have to worry about statistical analysis on it - at least filtering out bad data so it doesn't skew results.
Add into the mix the fact that some people use their upload capacity for other things (like sendin files via email), or other P2P applications, and you have some complication if you want to handle every case correctly.
Another complication is the "quality" of the line. My 768/128kbit DSL is much better than my girlfriend's 768/128kbit cable, in that I'm able to upload at 13 or 14kbyte/s and download at full speed, but to get anywhere near full speed on her connection I had to limit to 8-10kbyte/s.
This seems like a complicated problem to solve "correctly" to me, and I've coded a throttling patch to DC++.
In that case, the best outcome would be having DC++ learn what your upload capacity is and adapt. It can collect data about speeds every second, but then don't you have to worry about statistical analysis on it - at least filtering out bad data so it doesn't skew results.
Add into the mix the fact that some people use their upload capacity for other things (like sendin files via email), or other P2P applications, and you have some complication if you want to handle every case correctly.
Another complication is the "quality" of the line. My 768/128kbit DSL is much better than my girlfriend's 768/128kbit cable, in that I'm able to upload at 13 or 14kbyte/s and download at full speed, but to get anywhere near full speed on her connection I had to limit to 8-10kbyte/s.
This seems like a complicated problem to solve "correctly" to me, and I've coded a throttling patch to DC++.
GargoyleMT-
I am not very sure how plausiable this is to actually code, because I am not sure how much control you have looking at the packet size of network trafic in windows.....
You could setup a priority queue for network trafic that allows... say 75% of packets in a minute to be at max 512 bytes (including the data-link headers) and then the rest of thh 25% of the time any packets over that can go through. Of course, say, you don't have that many small packets than you can let more of the big ones through, and vice versa...
Depending on the connection speed this scheme should effectively throttle down uploads while keeping downloads fast and stable (the small packets are ACKs and such just to keep downloads going). Of course, the ratio's I specify probably should be adjusted... Infact, it might be better to have a higher percentage on the big packet end inless you want to force throttling of uploads to be pretty significant when you have a bunch of downloading going on.
The only problem I really see is that this might have to be beyond the scope of the actual DC++ code, especially if you want to have it take in account other P2P apps and any servers on the computer, etc.... (Just like you already mentioned).
Since I have a linux box acting as a router, I just setup packet shaping to do the very prioritizing of packets based on size and it works WONDERS on all my connections. Of course, you can extend the method I mentioned and not base it on percentages but actuall bandwidth usage... as in, you could allow a total of 10k/s upload for big packets and then the rest goes to small packets. However, you run into the problem you mentioned earlier (not knowing the quality of the connection), but if you use the precentages then after a few seconds of running it should balance the throttle, automatically, very nicely.
What do you think?
~Moch
I am not very sure how plausiable this is to actually code, because I am not sure how much control you have looking at the packet size of network trafic in windows.....
You could setup a priority queue for network trafic that allows... say 75% of packets in a minute to be at max 512 bytes (including the data-link headers) and then the rest of thh 25% of the time any packets over that can go through. Of course, say, you don't have that many small packets than you can let more of the big ones through, and vice versa...
Depending on the connection speed this scheme should effectively throttle down uploads while keeping downloads fast and stable (the small packets are ACKs and such just to keep downloads going). Of course, the ratio's I specify probably should be adjusted... Infact, it might be better to have a higher percentage on the big packet end inless you want to force throttling of uploads to be pretty significant when you have a bunch of downloading going on.
The only problem I really see is that this might have to be beyond the scope of the actual DC++ code, especially if you want to have it take in account other P2P apps and any servers on the computer, etc.... (Just like you already mentioned).
Since I have a linux box acting as a router, I just setup packet shaping to do the very prioritizing of packets based on size and it works WONDERS on all my connections. Of course, you can extend the method I mentioned and not base it on percentages but actuall bandwidth usage... as in, you could allow a total of 10k/s upload for big packets and then the rest goes to small packets. However, you run into the problem you mentioned earlier (not knowing the quality of the connection), but if you use the precentages then after a few seconds of running it should balance the throttle, automatically, very nicely.
What do you think?
~Moch
What do I think? That I need to get off my ass and build a linux router. Since I have such limited upstream I need to manage every byte of it 
Personally, I don't think that this can be accomplished with software alone. DC++ is only an application and it's limited to one PC on a network. It's just to far removed from the "real" network that it will never have enough information to make decisions about throttling.
btw, Windows 2000 and beyond have the same access to the network layer like Linux does. At least with Raw Winsock support, but not entirely sure on network drivers. I haven't really seen many people take advantage of it yet though, unless I'm looking in the wrong places. I would love to find something for win32 that could do QoS and traffic shaping.
Personally, I don't think that this can be accomplished with software alone. DC++ is only an application and it's limited to one PC on a network. It's just to far removed from the "real" network that it will never have enough information to make decisions about throttling.
btw, Windows 2000 and beyond have the same access to the network layer like Linux does. At least with Raw Winsock support, but not entirely sure on network drivers. I haven't really seen many people take advantage of it yet though, unless I'm looking in the wrong places. I would love to find something for win32 that could do QoS and traffic shaping.
Inless you are using the server editions of NT 4/2000 I am not sure you are going find good QoS support for the non-server editions. However, Win XP (Profesional/Corprate at least) has a QoS IP service. I haven't really messed with it any, but I think there are some additional QoS utilities you can install from the XP CD to configure the QoS service. I really don't know though for sure, any other takers that know how to configure QoS in XP?
-
Kenneth-Chile
- Posts: 80
- Joined: 2003-03-21 10:17
- Location: Concepcion, Chile.
ADSL is 2 channel, the channels are different sizes: upload is usually quite a low speed.
The main reason upload slows download and vice versa is that downloading at full speed takes some of the upload channel for ack packets. Not a lot, but some. About one small ack packet for every 2 large data packets.. With really unbalanced ADSL speeds, like 1500/128, this small up traffic of acks is actually quite a chunk of your 128..
The bigger problem, that people have observed about, is to do with TCP throttling down when there are delays in ack packets.. as would happen if you were hammering your upload channel.. the end result is that you cannot optimally use full speed in both directions, even on SDSL lines, for TCP protocol (used for FTP/http etc) although you can for UDP traffic (streaming video)..
The main reason upload slows download and vice versa is that downloading at full speed takes some of the upload channel for ack packets. Not a lot, but some. About one small ack packet for every 2 large data packets.. With really unbalanced ADSL speeds, like 1500/128, this small up traffic of acks is actually quite a chunk of your 128..
The bigger problem, that people have observed about, is to do with TCP throttling down when there are delays in ack packets.. as would happen if you were hammering your upload channel.. the end result is that you cannot optimally use full speed in both directions, even on SDSL lines, for TCP protocol (used for FTP/http etc) although you can for UDP traffic (streaming video)..
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
GargoyleMT, yes, you're right. It is great practice for a router.. I was just thinking that using the same logic one could apply it to throttling code for a P2P, like DC. I agree though, that it prob is impractible, if at all possible, for DC++ to implement a software based QoS of that sort.
Thanks for the response GargoyleMT, I always enjoy reading posts and learning the input of those who actually have a hand in coding for DC++ (like you and all your patches heh).
~Moch
Thanks for the response GargoyleMT, I always enjoy reading posts and learning the input of those who actually have a hand in coding for DC++ (like you and all your patches heh).
~Moch
-
GargoyleMT
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
You're certainly welcome. I think it is possible, in some form (pretty much everything is), but that it would be hard to handle correctly in most of the end cases....
As for something similar, you might look at eMule, there's a patch for a feature called AMUC, automatic maximal upload capacity, which measures ping time (?) to some servers to gauge how much of your upload stream is used. I haven't seen the source, but if we implement something similar, it might work.
I'm not sure Arne is a fan of any type of upload limiting in the client, as it could be adapted more easily for abuse. But I'm Todd, not Jacek, so it's all speculation!
As for something similar, you might look at eMule, there's a patch for a feature called AMUC, automatic maximal upload capacity, which measures ping time (?) to some servers to gauge how much of your upload stream is used. I haven't seen the source, but if we implement something similar, it might work.
I'm not sure Arne is a fan of any type of upload limiting in the client, as it could be adapted more easily for abuse. But I'm Todd, not Jacek, so it's all speculation!