I am wondering if anyone else has had this issue and found a solution. I’ve been attempting to use the S-1 Slice Assembly on two GRD products. It has taken nearly 4 hours to get to ~50%. Two days ago, I did the same thing with the process taking less than a minute. The problem seems to lie in the write speed. If I cancel the operation, and try again with the same parameters, it will quickly jump to the ~50% within 30 seconds, and then it stagnates once again. With my disk speed sitting at around 1 mb/s (the processor just seems to be chilling, it doesn’t go above 1% at this point). This is split about evenly between read/write. Watching the values as SNAP over-writes the old file, the processor jumps to about 100% and the disk speed also jumps to 100-300 mb/s. This might also be because the old file is still in memory? If I change the file name it will also jump up to around 50%. I don’t really know how the read/write process is supposed to work, so feel free to enlighten me.
While doing a performance computation with SNAP Configuration Optimiser, the disk speed hovers around 100 mb/s and the calibration takes a standard amount of time. If I do a similar calibration within the SNAP toolbox, the disk reads similar values of less than 1 mb/s.
With SNAP closed, moving large files around isn’t an issue and the disk speed is again at around 100 mb/s. I only seem to encounter low disk speeds in the write process of SNAP. Otherwise, I would say its a problem with my hard drive. What also baffles me is that I had this problem about a week ago, and then one day everything seemed to go back to normal. As mentioned earlier, slice assembly was no problem, taking less than a minute. Now yesterday, the problem has returned and it seems to be even worse than before.
