On all my devices and all my cards, when I copy files from the device to the card, the transfer starts out slow and slowly builds up speed. It may start at a few hundred kilobytes per second, move to 1 MB/s, then 2 MB/s, etc. If the files are large enough, it reaches 8 MB/s to 12 MB/s by the end. This seems unintuitive to me—it isn’t like it is a spinning disk that needs to get p to speed, there is no inertia to fight against. So why not all speed, all the time?
If the speed measured is the overall average and there’s some nonzero startup time, you might see something like this.
There’s also the device you’re copying from. Is that a spinning disk? The transfer speed is going to be limited by the read speed as well as the write speed.
Also never underestimate the possibility that the progress bar is… mostly fake. Lots of them are. A common case is that it starts out really slow due to startup cost, then almost immediately goes to the top speed, but the progress readout itself updates slowly because users don’t like seeing the speed jump around like crazy. If it takes long enough you could integrate over the speed displayed and see if it’s actually accurate.
No. By “device” I meant smartphone or tablet.
Tom Scott on why this is:
But if the OP is looking at the MB/s readout I would have expected that to be at least truthy.
I am a software developer and have personally written progress displays that are like… 70% nonsense. Progress bars are mostly psychological management of the user and as long as the progress bar
- Stops when something really has stopped
- Keeps moving as long as things are still progressing (the rate is not that important)
- Doesn’t anger users
It’s good enough. #3 suggests that you want a progress bar that underestimates until things are almost done. If you show them a progress bar that quickly goes to 90% because the early stuff was fast but the last part has some bits that sometimes go really slow, they will be angry. I thought it was going to take 2 seconds but it took 7! 
If you show them something that underestimates by a lot and then speeds way up at the end, they will be happy! I thought I was going to have to wait 20 seconds but it only took 10! 
That is… pretty consistent with what is going on here, so I think our first assumption should be that the progress and status are nonsense.
+1 to iamthewalrus_3’s post. I have also scrapped a progress bar that was actually putting effort into being accurate, and replaced it with one that made the customer “feel better”. All for an install that rarely happened, you were unlikely to see (you had to have your TV on at 4:00 AM to see it, and if you were watching TV at 4:00 AM we would happily let you postpone the install), and took about 20 seconds all told anyway.
I think the OP is talking about a file copying dialog that actually graphs the transfer speed though - like this one:
I don’t believe there is any hoodwinkery or management of user psychology in these - the size of the task is known - the amount of completion is known, the rate of transfer is measured. The estimated time remaining - sure - it’s an estimate, but the progress bar - it’s documenting what happened with moving data.
Okay, here is an example of a file transfer. Between the first two images, the transfer speed dropped from the 3.6-3.7 to below 2.0 for a while, so the appearance of a steady pace is deceptive. (Big drops early in the transfer aren’t uncommon.) I attempted a shot just before the end of the transfer, but missed. (I actually copied that file from the card to the phone so that I could copy it back. During transfer to the phone, it was showing 14-15 the entire time.)
I suspect what’s happening here is that there is some level of negotiation that needs to happen between the card and the PC. The card reader needs to read the disk index to figure out where on the card it is allowed to write, etc… Gathering this information takes some time, so the OS starts writing data as soon as it has any info but it doesn’t have much to go on so the transfer is slow. As it gathers more info, it can write faster, eventually maxing out the channel.
I think the progress and “instantaneous transfer rate” is actually a moving-window average (“number of bytes transferred in the last x seconds divided by x”) and they’re including the time before transfer started in the first x seconds’ computation.
I believe for flash storage devices, the OS doesn’t decide where the data will be stored - that is managed by the controller onboard the storage device (this is how it is possible for the capacity of flash storage to be faked in the case of those ubiquitous ‘2TB’ USB devices at unfeasibly low prices all over Wish, eBay, Amazon, etc.)
There is still some organisation and negotiation going on though, so you’re right - that creates some overhead that impedes the transfer happening at maximum capacity straight away.