Today I used a Pynetdicom SCP program to test this issue and got the same results (dicom transfer much slower than scp), so it's not a problem of DCMTK.
Anyway, if someone has any idea how to track this issue I'll be glad to hear.
Did you already check what the maximum throughput of your network connection is (i.e. theoretically). Maybe, your "scp" tool compresses the transferred file by default,
J. Riesmeier wrote: ↑Tue, 2019-05-14, 19:52
Did you already check what the maximum throughput of your network connection is (i.e. theoretically). Maybe, your "scp" tool compresses the transferred file by default,
Well, I don't know. How can I check that on Linux (Ubuntu 16.04 Server).
BTW, I did the test against a virtual machine running on a standard i7 PC on a remote location and it took the same time storescp and scp, so, it looks like the problem is on the Digital Ocean (and Vultr) droplets.
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local BBB.YYY.ZZZ.AAA port 5001 connected with XXX.YYY.ZZZ.AAA port 49134
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-18.6 sec 3.00 MBytes 1.35 Mbits/sec
------------------------------------------------------------
Client connecting to BBB.YYY.ZZZ.AAA, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.104 port 49134 connected with BBB.YYY.ZZZ.AAA port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-11.3 sec 3.00 MBytes 2.23 Mbits/sec
I don't know why [ 3] and [ 4} differ (1.35mbits/sec and 2.23mbits/sec), but anyway copying the file with scp gives similar results, and using dcmsend/storescp takes twice as long.
This is what I've meant in my first posting: use the latest version of the DCMTK tools. We've changed a few things in the networking module "dcmnet", which should enhance the performance on recent Linux systems (e.g. don't disable Nagle algorithm and don't set TCP send/receive buffer length by default).