0000443: Upload rate is wrong under heavy load

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000443

aMule

Transfer

public

2005-05-19 14:29

2005-06-14 23:48

Reporter

eyalzo

Assigned To

Xaignar

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

open

Platform

OS Version

Product Version

SVN

Target Version

Fixed in Version

Summary

0000443: Upload rate is wrong under heavy load

Description

This bug in minor only because it happens to people with very-very fast network.
When upload speed is very high (1000K+), some sockets are busy (?) and many "sent" bytes actually don't get through.
The problem is where total speed is calculated. It thinks that all bytes are out, and speed is higher than it is in reality, so it reduces the speed (according to the limit).
What I see there is numbers like 8000K when it's supposed to be "only" 1000K.

Additional Information

The fix I tried (and it works) is in CUpDownClient::SendBlockData
See the 3 lines with "bytesSent"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    uint32 bytesSent = 0;

    while (!m_BlockSend_queue.IsEmpty()
        && m_BlockSend_queue.GetHead()->GetRealPacketSize() <= m_nMaxSendAllowed){

        CPacket* tosend = m_BlockSend_queue.RemoveHead();
        uint32 nBlockSize = tosend->GetRealPacketSize();
        m_nMaxSendAllowed -= nBlockSize;
        SendPacket(tosend,true,false);
        m_nTransferedUp += nBlockSize;
        bytesSent += nBlockSize;
        theApp.statistics->UpdateSentBytes(nBlockSize);
        credits->AddUploaded(nBlockSize, GetIP());
        if (m_BlockSend_queue.IsEmpty())
            CreateNextBlockPackage();
    }
    kBpsUp += kBpsToSend*(1.0-lambdaAvg); // 2nd part of averaging filter
    return bytesSent;

Tags

No tags attached.

Fixed in Revision

Operating System

Attached Files

Relationships

Notes
(0000984) Xaignar (manager) 2005-05-19 19:36	You've written "CVS" for version, but that cant be. Current CVS uses a completely different upload-scheduling (UBT from eMule) code than what you've pasted. Could you test it with a CVS build and see if the problem is still there?

(0000996) eyalzo (reporter) 2005-05-24 08:47	I had to choose "CVS" as version because 2.0.1 wasn't on the version list, and 2.0.1 was just released. So my comment is related to 2.0.1. I won't be able to check CVS now, but I'll do that one day. Thanks.

(0001066) Xaignar (manager) 2005-06-14 23:48	Closing until that "one day" arrives.

Issue History
Date Modified	Username	Field	Change
2005-05-19 14:29	eyalzo	New Issue
2005-05-19 19:36	Xaignar	Note Added: 0000984
2005-05-20 02:03	Kry	Status	new => assigned
2005-05-20 02:03	Kry	Assigned To	=> Xaignar
2005-05-24 08:47	eyalzo	Note Added: 0000996
2005-06-14 23:48	Xaignar	Status	assigned => closed
2005-06-14 23:48	Xaignar	Note Added: 0001066