Original subject: Upload Speed Calculated Wrong

Posted: Apr 2 2003

Disclaimer: I haven't checked the code.

I did some performance monitor run with eMule running. I logged several items with Windows Performance Monitor (Win2k), our of which the most interesting in this case is NIC bytes sent / second stat.

With upload limit 800, the graph was nice - upload 800 flat, for a long period. However, performance monitor shows about 660kBps sent packet rate - and remember that this includes the surfing, irc, and especially all overhead - TCP/UDP packet headers and so on. Also, eMule shows a lot lower effective rate - ~580kBps - when I calculated from the statistics "uploaded data / session" and time running.

Where does the disparity come from? Now I'm just guessing, but..
Upload slot timer is 100ms. The timer invokes a function that checks all the slots, writes data to sockets, possibly adds a new slot and starts connection to the client, and in the end sets the timer again for 100ms.
Assuming upload speed stat is calculated within that function, and is assumed to be ten times the data written, and the function takes any time at all to run, it of course shows way too high a value. If the function runs 20ms, we already see 100/(100+20) of the stat as real. And even assuming 10% overhead (which would be very bad), 580/800 is about 0.725, or about 100/(100+38), indicating 38/138 = 27.5% CPU time spent within that function. As my mule takes easily 40% of the CPU time, and I'm uploading a lot more than downloading, I can believe that that particular function is the biggest CPU hog here.

Ways to correct the problem:
set new timer when entering the function
- causes even more CPU load
longer timer period (eg. 250ms)
- should help in CPU load, and the OS has multilevel buffering for network anyway, so nothing lost here
Optimizing the timer function
- standard optimization techniques, of course probably most basic optimizations have been applied already


Other profiling ideas:
- have a traffic stats structure
- in each place where data is written or read from the socket, update the traffic stats structure
- separate stats for TCP/up TCP/down and UDP/up UDP/down, at the very least - if at that socket read/write level more is known, of course that can be applied here, too.
- log stats periodically (10 minutes?)