When copying ~80Gb data from one USB 3.2 stick to another, i noticed that the GUI of the transfer speed had clear periodicity. Out of curiosity, what could be the reason for this? No other active programs were running that, to my awareness, should put a periodic load on the system.
Here's a possibility: Every transfer copies one megabyte and takes 0.4 seconds. The display is updated every second. The counter for "data transferred" is updated when a transfer is complete.
So 50% of the time the display is updated after 2 transfers with 2.0 megabyte completed, and 50% of the time it is updated after 3 transfers with 3.0 megabyte completed. That explains the "periodic" behaviour quite nicely.
In your case, your USB stick might be quite slow, so my numbers are actually realistic. In case of a hard drive: Hard drives have caches. So your computer can write say 100MB per second to the hard drive, but actually only 80MB get written and 20MB fill up the cache. Until the cache is full, and then your hard drive doesn't accept new data until say 100MB of the cache are written to the actual hard drive. That will look to your computer as if write speed wasn't constant.
But since you posted on CS, it's now your duty to explain exactly what happened :-) For example, you could write a program that logs reading and writing with the exact times when they happen.
The transfer is DMA so it isn't really the other programs which create periodicity. It is more like bus-mastering and the speed with which the device answers the read and write commands. I assume you are on Windows desktop with an x86-64 CPU. On these desktops an xHCI is used to transfer data. I actually wrote a partial xHCI driver which I have not finished yet.
I can tell the xHCI supports MSI-X. The xHCI thus can trigger interrupts directly to the local APIC of one specific CPU core. The currently running program on the core is interrupted and the TSS is used to switch the stacks if there was a ring 3 to ring 0 transition. Otherwise, the interrupts are simply nested on the same stack. The interrupts are short lived because they don't do the main work. They simply do some work to add the interrupt to the queue of programs that the OS will then switch on using the scheduler. The data Transfer Event TRB is probably also read by the driver and it pushes the data of the TRB to some other place. This is called Bottom-Half Interrupt Processing. The TRB informs software of the size of the transfer (for more info see When are a controller's registers loaded and ready to inform an I/O Operation?).
The periodicity can be created by file switching. One file can be "programmed" to be read/written to a USB stick to a specific address at once whatever the file's size) but you cannot tell the xHCI to just write to a device with five different addresses and tell it to read the files from 5 different addresses. There is some processing involved by software on file switch that can create periodicity in the transfer.
The scatter gather operations can create periodicity because the virtual memory is contiguous but not physical memory. The physical memory is separated in chunks of 4KB so the buffer allocated to your program (the built-in file explorer) may be bigger than a page and be scathered around RAM. To avoid that you can use one buffer of 4KB but that makes the operation slower because you need to schedule the operation several times to read into the buffer. Instead, file explorer probably makes the buffer much bigger and let the OS do the scather gather by putting several TDs on the Transfer Ring of the endpoint for that device. The TDs contain TRBs and specify physical addresses so the OS must make sure that the transfer doesn't overwrite parts of the address space of another process. It must also pin the pages to physical memory instead of swap because DMA transfers are writing directly to it. If the OS swaps the page-frame to the hard-disk and give the page-frame to another process, the DMA engine is writing to another process's address space. This is very dangerous and could be a potential vulnerability. There have been some vulnerabilites known in the past so this is actually something that can happen in a recent OS (because it happened in recent years but I don't know if there are current vulnerabilities).
A lot of other things can create periodicity. It is a very complex operation which involves bringing the data to RAM and then sending the data back to the other device.
Also, I didn't read the xHCI spec for the bulk transfer part. Bulk transfers seem to be the way to transfer data from a mass storage device to RAM or vice-versa. Maybe start to read the spec and you'll have all the info you need. The spec is linked on my answer that I linked above.
