Map out the exchanges your application needs
For each flow, note its starting point, its destination and the person who needs it. Add the chosen protocol, the direction in which the connection is opened, the frequency and the expected volume. An initial import, an administration connection and a continuously called service are not prepared with the same criteria. An unknown destination remains a point to be resolved, rather than a general authorization to open.
This list helps your team decide what should be accessible and what can remain closed. It also specifies who approves a change. Connectivity characteristics cannot be inferred from the GPU model: throughput, addresses, ports, and access methods must be recorded for the environment actually provided. The matrix below represents a fictional project, not services advertised as included.
| Flow | Criterion to specify | Owner |
|---|---|---|
| Administration workstation to environment | Protocol, destination, and authorized access | Access owner |
| Data intake to GPU job | Initial volume, frequency, resumption | Data owner |
| Application to external dependency | Destination, authentication method, acceptable delay | Application owner |
| Results to retention destination | Final volume and acceptance check | Deliverables owner |
Measure the transfer that matters to your schedule
Take a representative sample, with a number and size of files close to the planned work. A single archive and thousands of small files place different demands on the process. Measure import and export separately, to the destinations actually selected. Keep the useful volume, elapsed time, tool, parameters, and test conditions so you can compare a second run.
A tool such as iperf3 measures a network flow between a client and a test server. Its documentation distinguishes in particular the normal direction and the reverse direction. Such a test requires two authorized endpoints; on its own, it does not prove the speed of a file copy, which also depends on storage, processing, and the protocol. Start with the application transfer your schedule actually depends on.
Turning a measurement into a transfer window
Entirely fictional example: 600 GB must be exported. Here, 1 GB equals 1,000 MB, and throughput is expressed in MB per second. At 120 MB/s of useful throughput, the division 600,000 ÷ 120 gives 5,000 seconds, or 1 h 23 min 20 s. With a more cautious assumption of 70 MB/s, it gives about 8,571 seconds, or 2 h 22 min 51 s. Neither of these throughputs describes a Capordia offering.
If the team adds 45 minutes to finalize the package and check its receipt, the second assumption takes about 3 h 08. It can reserve a 3 h 10 slot, then separately add whatever buffer it deems necessary. This window remains conditional: a change in volume, number of files, or transfer conditions requires redoing the calculation. Do not replace this estimate with the theoretical throughput of an interface.
| Assumption | Transfer time alone | With 45 minutes of preparation and checking |
|---|---|---|
| 120 MB/s useful | 1 h 23 min 20 s | 2 h 08 min 20 s |
| 70 MB/s useful | About 2 h 22 min 51 s | About 3 h 07 min 51 s |
Prepare access and resumption without opening more than necessary
First validate the destination and the host identity against the expected information, then the permissions and the working path. An access denial is not resolved by sharing the command account password in a shared document. Access to the environment and login to the Capordia account serve distinct functions; record their owners without copying their secrets.
If your procedure uses OpenSSH SFTP, transfers go through SSH. Its documentation also states that a partial resumption assumes the fragment already present matches the source file. If the source file has changed, resuming blindly can produce an incorrect copy. So freeze the version to be transferred, identify partial files, and check the result before declaring the delivery complete.
Diagnosing a wait through observable steps
If files arrive but the application does not respond, examine the application flow rather than changing the entire configuration. Distinguish name resolution, connection opening, authentication, reading of the first data, and complete transfer. Record the time, direction, and the exact useful message. Keep identifiers, tokens, and content data out of anything shared with support.
If the copy starts and then slows down, compare a second run under the same conditions and look at the neighboring steps: reading at the source, preparing the archive, writing at the destination. Observing that the GPU is underutilized is not enough to conclude that the network is responsible. The diagnostic file must state what is waiting for what, and which observation would make it possible to distinguish between the possible causes.
Separating external access from GPU-to-GPU exchanges
The network used to reach the application and the internal communications of a multi-card computation meet distinct needs. The CUDA guide describes an explicit distribution of data and computations across devices, with access options that depend on the system. Neither the number of cards nor a successful file copy from your workstation proves that distributed processing works.
So describe the expected scenario: independent tasks assigned to each card, or processing that exchanges data between them. Then check the path your software actually uses. Reception is complete when the required flows work, the checks are recorded, and someone knows how to resume an interrupted transfer. The accepted conditions then become part of the deployment file.
Questions to decide
Why distinguish MB/s and Mb/s in planning?
A byte contains eight bits. With the decimal units in the example, 70 MB/s corresponds to 560 Mb/s. Mixing the two multiplies or divides the estimate by eight. Record the unit with each measurement and calculate from the usable transfer throughput.
Should both directions of a transfer be tested?
Yes, if the project imports data and then exports results. The paths, destinations, and conditions may differ. A good import measurement does not guarantee that the final retrieval will fit in the same window; test the direction each deadline depends on.
Does an encrypted transfer remove the need to check the files?
No. Transport and package validation answer different questions. Also check the expected files, their integrity, and that they open from the destination. A bad file selection can be transferred correctly yet remain unusable.