Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[emnops]

What's the upload and download overhead of ed2k protocol? I thought that the "overhead" statistics shows that, but it does not seem to be so in fact. Once I have ordered only the rare files and there was only the uploading for two or three hours - something near 200 MB were uploaded. I have checked the provider's stats and have discovered the several MB of incoming traffic unaccounted for - there was something like 10 MB, of which only 3 was actually downloaded by aMule.

Well for me this is HUGE! I have extremely high incoming traffic costs here. I think I'll have to limit outgoing cps then .. but really interesting thing is then, are there any formulae for the REAL overhead incoming traffic calculation? And shouldn't aMule show it? I mean it said something about less than 1 MB overhead traffic, which would be fine by me if it were true... I suspect now that currently it only includes the negotiation traffic, while I want the overhead that includes the traffic caused by transfer receipt acknowledge packets etc., ie by the actual transfer protocol.

I have just done somewhat more preceise experiment -

somewhat near 1 hour of uploading,
rate limit 50kb
uploaded: 53.30MB
total overhead: 22KB(1K)
downloaded: 0
total overhead: 24KB(886)

provider stat:
down 1.488MB up 55.645MB

well this 1.488 does include some web traffic, but I have made sure that at least 1MB is the amule traffic. What is more than desirable is the more preceise method of overhead calculation.

Any ideas?

[skolnick]

There are some reasons why this may be. Maybe aMule stats count 1MB = 1024kB = 1048576 Bytes, but your provider counts 1MB = 1000000 Bytes. It may be a little difference on 1MB, but with many MBs it really can make difference. Another problem is that your provider can be counting traffic on lower layers or protocols (maybe as low as Ethernet /PPPoE) but aMule cannot take this into account. It can only count upper layers (Maybe transport and up? i.e. TCP/UDP?) and packets in lower layers are bigger than in upper layers (of course, lower ones contain upper ones _plus_ a header). Also, is difficult to know the exact size of an ACK packet, for example. It could also be that your ISP is not being very honest with you.

Regards.

[lfroen]

aMule stats count 1MB = 1024kB = 1048576 Bytes, but your provider counts 1MB = 1000000

Just FYI, in communications nobody counts byte-per-second, instead bit-per second. So, this is what you provider counts.
Leave alone PPPoE overhead: it's < 10bytes on packet.

rate limit 50kb
uploaded: 53.30MB
total overhead: 22KB(1K)
downloaded: 0
total overhead: 24KB(886)

provider stat:
down 1.488MB up 55.645MB

Provider stats looks very real: 1.5MB of downstream in hour is ed2k protocol control messages + TCP acks (you have one-way stream for each client downloading from you, so there's no piggybacking here and TCP sends acks in separate packet)

aMule stats are missleading: it counts only data aMule send (aka payload), which in control packets can be only 50% of total data actually send to the network.
Run ethereal, choose "io graphs" in menu and see real thing.