The speed of each simultaneous DCC to Bob won't drop below 25 KB/s until I've added enough connections to saturate my local upstream bandwidth limit or his local downstream bandwidth limit. test.zip.000, test.zip.001, test.zip.002, etc.) and DCC those pieces simultaneously (as separate DCC transfers) to one of those same individuals, I can double, triple, or even quadruple my aggregate transfer speed to him.įor example, with internet lag/congestion somewhere between myself and 'Bob' capping my transfer of "test.zip" to him at, say, 25 KB/s, I can instead send it to him at the combined speed of 75 KB/s by sending it in three pieces with simultaneous parallel DCCs (25 KB/s each, 75 KB/s total). If I first split a large file into pieces (e.g. I have a 96 KB/s upwards pipe, yet even when it's completely unused by anything except mIRC, I generally experience only 20-30 KB/s DCC send speeds (per DCC) to friends in Europe (me = North America). But something else that slows DCCs down is simply international distance and internet congestion. mIRC nicely addresses this with /fsend and /pdcc, and user-controllable packet sizes. The speeds of DCC transfers have always suffered because of DCC's redundant ACK system. Maybe one more extension would be worth it? But I've hit on something that appears to give significant benefits. Considering the mess extensions have made of the DCC protocol in their competing attempts to compensate for its shortcomings, I almost hate proposing yet another extension.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |