Problem
When writing large files to shares, it is noticeable that the transfer rate is high for a while, then collapses, then goes up again, then collapses again, etc.
Analysis
This is due to the underlying storage (HDD, NSA, SAN) and is not directly related to UCS.
The storage used has 32GB of RAM.
Data that is written to the device is first stored there in a cache and written internally to the hard disks when there is less load.
If small files are written, they end up in the cache and the client receives immediate feedback that the file has been written. This means almost full network performance. If, on the other hand, a file is written that is larger than the cache, the system must write the cache to the hard disks in the meantime (because it is full). This rate is limited by the interface speed (in this case 6 Gbit/s) and the actual speed of the hard disks (usually well below 6 Gbit/s). So as long as the data is written from the cache to the disks, the performance of the transfer is limited by the hard disks. Until the cache has been successfully emptied and is free again for the new data. It then accepts this data at full speed. Yes, until it is full again and then the game starts all over again. This causes the clearly recognizable fluctuations in the transfer rate.
Solution
The observed behavior is normal and to be expected. With files of this size, the full network speed cannot be expected if the storage is slower than the network.