Open extra slot

Bug #1402176 reported by steve72
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AirDC++
Confirmed
Undecided
Unassigned

Bug Description

You can make airdc++ to automatically open a extra slot if your upload speed is less than a set value even if all your upload slots are taken. This will make sure your upload speed is fully used even if slow users is taking up all your slots.

This function does not work any more and havn't been working for a long time.
Perhaps even as long back as when the multiconnection slot function was introduced.

Revision history for this message
maksis (maksis) wrote :

I can't reproduce this issue

maksis (maksis)
Changed in airdcpp:
status: New → Incomplete
Revision history for this message
steve72 (steve72) wrote :

Well, here is some update.

I've seen that the client indeed opens some extra slot, but not as many as it should.
I've included some logging in my special build and can see that clients wants more slots
but won't get any.

I have also tested to change some conditions when a slot should be granted and then it will open more,
but it's not working 100%.
It's hard to understand the code because i don't have the deeper knowledge about the slottypes and how it's intended to work.

I've tried the dc++ client and it opend up slots all the way to my set upload limit for extra slots.

Revision history for this message
steve72 (steve72) wrote :

I now have found out why it's not working as I think it should.
Users that is downloading with a mcnslot cant get any additional slots even if my bandwidth usage is below my set upload.
A new user can get a slot on the other hand. The client should give an extra slot to any user who wants it, as long as my bandwidth use is lower than my set upload speed.

Let's say i have 8 slots for uploading, Then i can have 8 users using 1 mcn slot each. If i have unused bandwidth the client will never open an extra slot.

Revision history for this message
maksis (maksis) wrote :

Yeah, things stay a bit simpler this way... Testing this kind of changes is currently a bit hard for me.

Changed in airdcpp:
status: Incomplete → Opinion
status: Opinion → Confirmed
Revision history for this message
steve72 (steve72) wrote :

Patch from Night

Revision history for this message
maksis (maksis) wrote :

I don't understand the first change because that condition is to check slot checks for users with a permanent slot - now users can lose their slots because the condition is always true. Your other changes means that the extra slots are always counted into available slots without even checking the speed limits and other conditions...

Revision history for this message
steve72 (steve72) wrote :

You're correct. I was wrong, but i was on the right track :)

I found out that the problem is that the setLastGrant(GET_TICK()) is set for all types of uploads.
If you have a fast upload speed many users downloads partial file lists and tth values from you and each upload is marked as a slot granted.

If you have bandwidth unused and set a speed limit when you want extra slots to be granted. If a slot can be granted this is checked in the getAutoSlot() function. However, an extra slot will never be granted unless 30 seconds pass between since the last slot was granted.
If users continuously download many small files/tth/partials the extra slots will never be granted.

Either the time 30s should be lowered or the setLastGrant(GET_TICK()) should only be set for real file uploads, probably the last.
I'm not even sure why the limit is there in the first place. Perhaps to even out fast changing speeds?

Revision history for this message
maksis (maksis) wrote :

True, setLastGrant should probably only be set when a permanent slot is granted. I think that the limit itself is good so the client doesn't grant several extra slots on the same second without letting the speed to be counted with each granted extra slot (or if there's a temporary drops in the speed and so on...).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.