Forums Connection Issues Slow Data Rate of DCC Sends and Gets

Hi everyone,

I have been working on this issue for a day or so and thought I would ask it of the group.

Here is the situation, while running an Fserver I noticed the total upload rate, regardless of number of connectons, totalled to approximately 56KB/s. Given that the upload rate of my connection is 256KB/s and verified through http://nitro.ucsc.edu I am curious what steps I can take to identify possible bottlenecks. The fact that limiting number is 56KB/s makes me think it is a constraint that isn't a result of network congestion... too convenient.

What additional debug steps would one conduct to improve the rate of transfer for a DCC upload (or download) assuming the following:

All Linksys NAT ports are forwarded correctly, can both send and recieve.
Max CPS is set to 0
/fsend is set to on
Time Warner Cable modem connection

Any suggestions would be greatly appreciated as I have found very little treatment of this subject on the web.

/pdcc ?
Also, what's your /dcc packetsize ?


Network wise, how far away is the recipient, and what sort of latency do they have (traceroute and ping)?

Is your upload speed 256kbit or 256kB?

Thank you for the quick replies...

I believe it is bits, not bytes and I probably shouldn't have used the uppercase B. Here is an output from Nitro, the Upload value is a little low because the server is currently on.. varies from 260-365 on the upload (depending on distance to the test server):

TCP/Web100 Network Diagnostic Tool v5.4.12
click START to begin
Connected to: nitro.ucsc.edu -- Using IPv4 address
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client-to-server [C2S]) . . . . . 280.0kb/s
running 10s inbound test (server-to-client [S2C]) . . . . . . 3.51Mb/s
Your PC is connected to a Cable/DSL modem


/pdcc is on

and packet size is set to 8192


Might I be missing the forest for all the tree's here in that these values are in bits, not Bytes and I just need to pony up the cash for a faster connection? 365Kbps ~> 45KBps

Thank you again

Yeah, that's what was confusing you. You can estimate average speed in kB/s as kbits divided by 10, and max as kbits divided by 8. That doesn't mean you can't get faster than the "max" because your speed from your ISP isn't really a solid barrier, if you get my meaning.

So, 256kbit will give you about 26kB/s to 32kb/s most of the time. If you can get more than that all of the time, then you're doing good or else have a faster connection than you think. You mentioned getting 56kB/s, so your connection may actually be about 512kbit.

Btw, don't trust those speed test sites. Depending on the site, you can find your connection speeds showing at half what you really have up to 3-4 times what you really have. Just check with your ISP and you'll know what you really have for speeds. Also keep in mind that speed is also based on the compression of the file(s) being sent/received. Text sends really fast because it's not compressed at all. A ZIP or RAR will send slower in general. Basically, you have a better chance of sending a text file at faster than your "max" than you are of a ZIP or RAR. As an example, I shouldn't be able to top 100kB/s, but I've sent files at around a sustained 200kB/s when it was just uncompressed text and such. Certain picture formats are also uncompressed and can send fast as well. Note that this doesn't mean you'll always get those speeds. And, it can also be a matter of how compression is handled by your modem and/or ISP, whether or not you get the increased speeds for uncompressed files. I think the speed differences are getting less as connections are improving.

Thats totally false they're just bits whether its RAR or .TXT doesn't matter. Even SSL is handled on both ends of the line. TCP/IP just carries bytes, it doesn't care about the content of what its carrying.

Then why are there internal compressions to speed up transfers?

What do you mean by "internal compressions?" The DCC protocol (and hence mIRC) sends files as-is, and performs no additional compression. The underlying TCP/IP protocol doesn't, either.

You can use: fsend on and also try pdcc on and pdcc 99999