The bits vs bytes question is non trivial, especially when a rate - bits per second - is involved.

Understanding that it's all an academic question anyway I'd like to know just what the current progress bar indicates. It might be a count of bytes transferred via TCP/IP and it might include the overhead associated with packetizing and even receipt confirmations in the TCP part of the reliable connection.

But I think it's not. It's really just the count of bytes in a file as stored or otherwise processed by user software. The kind of thing one gets by stat-ing the file after a write.

But, if that's the case, is the count based on 1k = 1024 bytes or the NIST standard 1000 bytes? For storage, computer "scientists" use 1024 but for rates of delivery the general rule is 1000 as in kilohertz.

Folks asking for bits/sec are likely to be checking up on their internet connectivity and they really care about transmission bandwidth which must include the packet overhead for a fair comparison with what the serviceman gets with his test equipment.

Multiplying by 8, or 10 if start/stop bits are involved in a PPP connection, is not good enough. Curl would have to acquire more information from below the "application layer" and that would be system dependent and time consuming. It is not something curl should attempt.

I would like a definitive answer for the progress bar though. k=1000, k=1024, or k=whatever the system returns?

-- 
--> From the U S of A, the only socialist country that refuses to admit it. <--