-1

I would like to get some things clear, once and for all, so that I can rest in peace and share this knowledge with others without making fool of myself :)

My internet provider states that its UL speed is up to 3 Mb/s. I have read that network speed (capacity) of 3 Mb/s(3072 kb/s) equals to ~384 KB/s as a result of 3*1024/8 since 1 byte = 8 bits. Now here come the questions:

  1. Why do net providers define the network capacity in bits/s, when what we really care about are the actual bytes uploaded/downloaded?
  2. Are there any protocols faster than FTP for sending large files to/from a remote server?

I hope I made myself clear, I will elaborate on my thoughts if needed

EDIT I have made some research and it reveals that I must have made some mistakes in calculation due to the units misunderstanding, therefore first two questions regarding UL speed are pointless. Yet remaining two still bug me

17
  • 2
    @jacek_podwysocki Mb/s and Mbps are the same thing. / and p are two different and common ways of abbreviating per.
    – 8bittree
    Mar 11, 2016 at 21:22
  • 2
    @DavidSchwartz Do you have a source for that difference?
    – 8bittree
    Mar 11, 2016 at 21:26
  • 3
    @DavidSchwartz Line speed and data rate distinction is new to me and so is the difference between Mb/s and Mbps but posting a good reference article describing that 1 Mb/s is 1.048576 Mbps would be handy for all of us I guess Mar 11, 2016 at 21:38
  • 2
    @DavidSchwartz I remain unconvinced that p and / are widely understood as distinguishing between decimal and binary prefixes. Please provide a reference for such usage. Again, everything I've found has treated them as interchangeable. Wikipedia does acknowledge common inconsistent usage of decimal prefixes in place of binary prefixes, still considers p and / interchangeable.
    – 8bittree
    Mar 11, 2016 at 21:50
  • 3
    @DavidSchwartz It seems there are people who will use 1 Mbps to mean 1048576 bps. Again, could you please provide a source that supports your claim of a widely used and intentional difference in meaning between Mbps and Mb/s?
    – 8bittree
    Mar 11, 2016 at 23:06

4 Answers 4

2

Specifying capacity in bits/s -

David Schwartz is right that bits/s predate the Internet - and this is part of the answer - old systems did not always use 8 bits to represent data - For example, ASCII is only 7 bits (Extended ASCII is 8 bits).

Additionally, serial devices (and thus modems - which is how data was transmitted over long distance initially), had different ways of representing data (for example N81 - No parity, 8 data bits, 1 stop bit, so a "byte" of data was 9 bits in this example).

Then, of-course, there is compression. If you were/are sending standard text, you could get a lot more bytes through the line then the stated bit rate.

Then along came the Internet and grouped data into packets - with additional overheads for each packet. Depending on the size of the packet and encapsulation, the packet overhead can be significant.

Thus BPS is a truer reflection of what is being sold then bytes/kilobytes per second.

Faster protocols for sending large files

There is no single correct answer to this question. If the file can't be compressed, and the channel is not congested and distances are short, FTP is pretty good.

Once you need to deal with congestion, the game changes - Congestion usually means packet loss, which signals the system to slow down. Protocols which break up into multiple streams will provide better throughput (eg bittorrent, some implementations of HTTP downloads), and, of-course compression.

That said, there is also tuning which can sometimes make a significant difference which sits below the TCP level at which FTP works. (This is an expert topic, but includes things like larger MTU's, more packet buffering, QoS tagging etc - and the performance will only be as good as these underlying optimisations will allow.

4

There are two different things that you can measure. One is the line speed, typically measured in decimal bits per second. The other is the effective data rate, usually measured in binary bytes per second.

For example what is "gigabit Ethernet"? It is Ethernet with a line speed of one billion bits per second. How fast will data flow over gigabit Ethernet? Well, 1,000,000,000 bits = 1,000,000,000/8 bytes. So 125,000,000 bytes per second will flow each second. Since there are 1,024 bytes in a kilobyte, that's 122,070 KB per second. Dividing by 1,024 again, we get 119.2 MB/s.

This distinction long predates ISPs. ISPs provides lines and followed the existing convention for specifying line rates.

4
  • 1
    Isn't it slightly more than just a convention? A "bit" is the single standard Shannon unit and all/most information systems papers uses this as the unit, but a byte is not, by any necessity 8 bits? I thought it is codified now, but was long considered merely a a "de facto standard" and some C implementations (for example) store a byte with more bits? I am not an expert.
    – Yorik
    Mar 11, 2016 at 21:30
  • 3
    It would be worth noting that this "line speed" differs from actual bitrate due to 8/10b encoding where a larger number of bits are used to reliably encode a smaller number of bits. It is this encoding that "wastes" effective bandwidth and reduces actual data received speed from effective "line speed".
    – Mokubai
    Mar 11, 2016 at 21:31
  • 1
    @Yorik How is a byte not 8 bits in nearly every modern computer architecture?
    – Ramhound
    Mar 11, 2016 at 22:46
  • @ramhound: it pretty much is, except in very specialized scenarios, but the point I am making is that it is plausible and, in the recent past, not unheard of. On the technical side of bandwidth: the descriptions, the math, the foundation is bits, and a bit is absolutely unambiguous. Bytes were not. "Modern" in computer terms is measured in 5-10 year increments.
    – Yorik
    Mar 15, 2016 at 15:19
1

Are you sure that you're getting 3 megabytes per second on your torrent? That would be impossible on a 3 megabit connection without some really good compression. I suspect your torrent program is reporting in 3 megabits (Mb/MBit/Mbit) per second. If you aren't sure, divide the file size in megabytes by the time it took to download, which should match your average download speed.

Providers measure speed in bits because there are a bunch of different ways you can use encode bits to get your bytes - some more efficiently than others. The best you can hope for uncompressed is 8 bits per byte, but there is usually some overhead which can vary depending on multiple factors. Some download protocols have more error correction, which uses up more bits per byte. Some people are using VPNs which requires putting data inside of other data. Some protocols check status more frequently than others, which adds to the overhead as well.

Regardless of how efficiently or inefficiently the bytes are encoded, the maximum speed is determined by how many bits can go down the pipe at a time, so that's what the providers use.

Think of it like when you're buying a 32 oz. fountain drink at the gas station. They sell you a cup which holds only so much. Some people use a lot of ice, and some people use little or none. Think of the soda as your data, and the ice as overhead. There are good reasons to use ice, and good reasons to skip it, but the fact is that the more you use, the less soda you fit in the cup. It's not in the store's best interest to charge you based on what you put in the cup. It's going to be some combination of soda, ice, and air which won't exceed 32 fluid ounces.

1

Why do net providers define the network capacity in bits/s, when what we really care about are the actual bytes uploaded/downloaded?

  • Network hardware (and all hardware really) fundamentally works on the bit level. Any digital communication method is concerned with transmitting a string of ones and zeroes, and anything more abstract than that (e.g. 8 bits = 1 byte, etc.) is up to the sender and receiver to care about. So from the point of view of network hardware designers looking at things as a stream of bits is more important than how potential applications will look at it.

  • All protocols have overhead. You can transmit 4Kbytes via TCP, but due to protocol headers, etc. the actual data transferred is more than 4Kbytes. To get 4 real, meaningful Kbytes/sec. to you via TCP, the actual speed has to be slightly more than 4Kbytes a second. With the variety of protocols in use (TCP, FTP which adds more overhead, HTTP which adds more overhead, SSL which adds a little more overhead, etc.) it's difficult to simply answer this to non-technical users.

  • Also, it looks better for ISPs to tell bigger numbers to the non-technically oriented - "this connection is 3 million bits per second" than "3 megabytes per second"

Are there any protocols faster than FTP for sending large files to/from a remote server?

  • Bittorrent is faster if multiple hosts have the file, because it can download from multiple sources simultaneously. If only one host has the file it will not give you a speed advantage, but will be very robust.

  • Compress your files.

  • Use protocols that send only delta information where possible if you are doing something like synchronizing files. rsync does this.

  • FTP relies on TCP which emphasizes reliability over performance. UDP, due to the way it works, emphasizes performance over reliability. There is not a common well-supported UDP-based file transfer method other than TFTP which you should not use over the Internet. You may look into this though, but it's not something I've tried (EDIT: looking into this a bit further not sure if command-line or other tools exist for this, it seems to be a library.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .