Ditch the slots...

A private forum for us Super-Humans, I even trust you to be able to edit your own posts =)

Moderator: Moderators

Locked
arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Ditch the slots...

Post by arnetheduck » 2003-02-26 05:16

Alright, I'm more and more seriously considering ditching the upload slots altogether (more or less), and only using the min upload speed instead. This makes a lot of sense, specially combined with multisource downloading. Then, even if more "slots" are taken, it doesn't really matter because it's the speed that's important...think about the consequences a bit and post your comments?

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: Ditch the slots...

Post by GargoyleMT » 2003-02-26 17:22

arnetheduck wrote:Alright, I'm more and more seriously considering ditching the upload slots altogether (more or less), and only using the min upload speed instead. This makes a lot of sense, specially combined with multisource downloading. Then, even if more "slots" are taken, it doesn't really matter because it's the speed that's important...think about the consequences a bit and post your comments?
I think this is a good idea. Mostly, I want to agree with it because it implies some other changes in the way that downloads and uploads are handled in DC++, which I think would be to the benefit of most, though it's not the traditional way that DC has operated.

I'm one of those people stuck on ADSL, 768/128kbit, (...) so the min upload speed for me (something reasonable, 8 or 10 kbyte) would likely be met out by a single user.

Hubs wouldn't particularly like this, because many might think that people in more than one hub wouldn't have "designated" space for users from their hub. A good queueing system would work around this (a queue weighted towards letting small files through first could wipe out the need for mini-slots as well).

There are more things that this change might imply, but I don't want to (further) sidetrack any subsequent posters...

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Re: Ditch the slots...

Post by sarf » 2003-02-28 11:11

Leave an option to report a certain number of slots, or people will never get into a hub at all (since they have no transfers going, they have no "slots free/used").

I am all in favor for ditching the slots, but then again, I usually have negative three to five with nine slots normal, so...

Sarf
---
Don't look now, but there is a multi-legged creature on your shoulder

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-03-01 00:13

I seem to be a little slow on this subject.

I'm not sure what the benefit of replacing slots with min upload speed is.

I see 2 main problems with the idea.
1) most hubs rate by slots (dc++ will be kicked from many of them)
2) the min upload speed could be sucked up by 1 person (when 3 could happily share it)

I think the best was to improve the way the queue is handled is to change it to something similar to IRC warez bots.
This scheme does not help with multisource downloads much, but does improve the way dc clients work currently.

aDe
Forum Moderator
Posts: 138
Joined: 2003-01-07 09:14
Location: SE
Contact:

Post by aDe » 2003-03-01 04:58

I think the current slot system works just fine. And the problem that mo pointed out, that one person could take all the bandwidth, is a rather bad one.

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-03-01 09:57

It would also be nice to have some way to see active people who are trying to get a slot from you at any given time

some sort of queue view
that way it would be easy to manipulate people in the waiting queue
grant slots, send messages, etc...

just a thought

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-03-01 17:30

IMO, ditching the slots is not a bad idea, but I'm pretty sure that many hubs wouldn't like it at all (you know all those hubs that require you to have n slots per each connected hub, with the minimum of q slots, etc.).

Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:

Post by Sedulus » 2003-03-01 22:25

well, hub(owner)s should not have a problem if we can make a good case for ditching the slots.
mo's second point however is a good one.
there will exist a need to leech that mp3 while someone is leeching a movie. either a nice queuing system could fix that, or some way to allow small(er) files through through an extra slot.

and one would always need some (high) cap to the number of sockets. I noticed >50 connections once when my inet was crappy (with O:300) ...that was the last time I used the O.
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)

Zc
Posts: 7
Joined: 2003-01-04 06:07

Post by Zc » 2003-03-02 03:47

ender wrote:you know all those hubs that require you to have n slots per each connected hub
Hub owners just want a mininum ressources allocated for their hubs ... now, slot or something else, who cares ...
I think a speed is better than slot but be careful at mo's point 2 (one person = all bandwith)
Queue system was largely discuss here and it's seems lot of ppl don't like that (if my memory and my english are enough good)

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2003-03-02 04:07

this is something i realy have to think on. I will try it in real-life a couple of days and see what happens..


i-think-there-will-be-lots-of-screams-from-conservative-hub-owners-and-i-can't-make-up-my-own-mind-until-i-have-tried-it-ly'ers
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-03-03 07:08

Well, mo's point is easily countered with that the person will take less time to finish the download, so it evens out over time...well, the order of connection becomes more interesting of course, specially for the modem user =)...but talk to your local hub owners and see...I guess I'll piss off a few just as a few still hang on to nmdc pure...but in the end, do I care if it works better for me (i e _all_ things considered, i get my stuff faster...)?

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-03-03 12:09

arnetheduck wrote: the person will take less time to finish the download, so it evens out over time
yes and no. there may be someone connected who is downloading a couple large movie file, while someone is waiting to get 1 file of insignificant size. (lets say 5 meg)

depending on the connection the person may have to wait a day or more to get this 5 meg file.

the person holding up the slot may be a leecher, or may be a friend.
either way, he's ruining it for everyone else
Sedulus wrote:I noticed >50 connections once when my inet was crappy (with O:300) ...that was the last time I used the O.
having a cable connection, I notice this also during peak hours.
if I want to do anything I need the least amount of people downloading from me when my connection is the worst.
using O:300 in this scenario gives you the exact opposite effect.

it may still be a good idea to limit the number of slots available.

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-03-03 12:17

I forgot to mention...

If packet latency, between clients, is very low, then multiple connections will probably not improve transfer speeds.
but multiple connections almost always means higher transfer rates, when packet latency is not low.

to my point...
there are programs out that will multi-connect to a http server and download a single file in chuncks to improve download speeds

Zc
Posts: 7
Joined: 2003-01-04 06:07

Post by Zc » 2003-03-03 12:54

mo wrote:depending on the connection the person may have to wait a day or more to get this 5 meg file
At this time, with the slot configuration too, you can wait a very long time before your download start ... but it's one problem, I agree.

yilard
Posts: 66
Joined: 2003-01-11 06:04
Location: Slovakia

Post by yilard » 2003-03-03 18:22

mo wrote: depending on the connection the person may have to wait a day or more to get this 5 meg file
Slow users will ruin whole thing. The multiple slot system is helpful in reducing possibility of queuing for a long time.

When you look at it from any point of view multiple downloads allow the most effiient resource utilization (bandwidth) at the uploading machine in the long run (It doesn't take other applications, with different needs into account, and that's why so many users are complaining about killing their connections with uploads).

Ditching slots would make sense in case of multisource downloading with queuing (instead of current hammering). Then one can develop and experiment with different scheduling strategies. I can imagine analogy with the way how operating system scheduler works. It doesn't let one single process to run for arbitrary time, but limits maximum time (timeslice) to certaing amount to retain interactivity (no process waits forever to be scheduled to run....... well in theory :)). It may even favor users asking for smaller files.

But still, I think multisource downloading and queuing is a provision to singleslot uploading and not vice-versa.
In the age of super-boredom/hype and mediocrity/celebrate relentlessness/menace to society --KMFDM

Moch
Posts: 71
Joined: 2003-03-21 22:29

Post by Moch » 2003-04-27 02:30

Ahh.. trying to catch up here in this forum.. here our my thoughts, sorry if I am repeating something I missed.

I think it would be a good idea if there was some kind of token bucket filter handling the bandwidths between users uploading.. Slots wouldn't exist in the concrete sense, but there would still have to be an actuall limit of the number of connections.

What I mean about token bucket... well.. Say I have an upper limit on my upload bandwidth of 500MBits... Perhaps there should be some kind of rule to determine what should be the "probaable guaranteed available bandwidth per user" that is uploading from me.. as in this could be determined by a hub rule. So.. there could be hubs that say, try to guarantee at least a 10Mbit connection per upload.. thus, initially, that would allow 50 upload users that could utilize the bandwidth (yes I know these numbers are irrational, but I am just trying to make example ;) )

But that isn't all.. what if one person can only download at 5Mbit/s then the bucket would still have bandwidth left and could be shared amoung whoever else is uploading. So, the bandwidth from users could be higher than 10Mbit because the bandwidth is still avail. Also, if x amount of time goes on and all the bandwidth isn't being used by all users and you have at least 10Mbit left you could go ahead and allow another user to download from you.

Hmm another words I think there would have to also be a lower limit constraint per user uploading. This would cause there to be a limit of the number of uploads, but this would be determine by the upload throttle limit. It would be kept in balanced by hubs requiring a minimal guaranteed bandwidth for uploaders.

I still see a major problem that people would just make there upload limit equal the guaranteed min bandwidth per uploader so they would only have to serve one person. Or, post it higher than there actuall internet connection so they can get into hubs with higher requirements Also, I think hubs would abuse the requirement and make it inpractical for slow connections to be able to even get into hubs anymore.

So.. hmm.. I might of changed my own mine here! What is more evil? Well surely the way I was thinking of the implementation. I Only post this now for a good way it shouldn't be thought of or done hehehe...

~Moch

Locked