Switeck Posted July 19, 2006 Report Share Posted July 19, 2006 µTorrent probably has no way of knowing how much TCP/IP overhead it really is using...it can only guess-timate it. Case in point:Uploading a 100 KB file might take 900 kilobits (note NO per-second time measure on this, as it isn't time based) of bandwidth over a cablemodem, 950 kilobits over a PPPoE DSL line, or 1000 kilobits over a 56k dial-up modem (with MTU at the 576 byte default). A speed test wouldn't reveal this, because the speed test is only checking how LONG a 100 KB file took to transfer -- not how many bits were sent/received doing it.BitTorrents protocol overheads COULD and pretty much are included in the download/upload speeds reported. This is actually a problem if you want to limit download speed pretty low so you can upload fast to get your ratios back up on a private torrent! What happens is with very low max download speed, your upload speed slows to a crawl as well because you're blocking incoming SYN-ACKs for your upload. The other peers can't quickly give you the "send more!" signals, because the download limiter blocks most of them! Link to comment Share on other sites More sharing options...
wyrmchild Posted July 22, 2006 Report Share Posted July 22, 2006 Then the modification is trivial, if only the BT protocol overhead is wanted. But I don't think the BT protocol uses much bandwidth anyways, as it's at most 17 bytes per message (except for bitfield), and there shouldn't be too many messages flying around unless you're connected to unnecessarily many peers or some client is rapidly changing status. Have messages should probably be the most common message type in the swarm.In-app net limiter hardly has any effect on TCP protocol things like receiving ACKs, unless you're accepting so much data the ACKs are having trouble getting through (which I find quite unlikely).. or again, using raw sockets, in which case you might have to handle the ACKs yourself).The only problem with ACKs that I can see is you filling your upstream too fast, so the ACKs get delayed because of full upstream buffer (the O/S one, not anything in the app itself), giving you good reason to either limit upstream or use "smart" packet scheduler in the O/S (which you probably can't change in Windows). Link to comment Share on other sites More sharing options...
Switeck Posted July 22, 2006 Report Share Posted July 22, 2006 SYN ACKs for uploads and downloads probably should have priority over bandwidth used for the download+upload file chunks and that should have priority over regular/optional BitTorrent protocol messages.If a connection is already maxed out, it does little good to be hitting DHT, Peer Exchange, or trackers for more sources. Even trying sources already in the cache list can wait if you're connected to more than 10 on a torrent. Link to comment Share on other sites More sharing options...
Helsie Posted July 22, 2006 Report Share Posted July 22, 2006 If you know how high your overhead is, you can tune down the speed yourself till it is okay, right? Link to comment Share on other sites More sharing options...
Switeck Posted July 23, 2006 Report Share Posted July 23, 2006 Helsie, not in the case you WANT to download slowly while uploading very quickly...possibly to get your ratios on a private tracker back up. Your upload speed will suffer IMMENSELY if you lower download speeds below what others would send to you at if you were unlimited. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.