DICOM @ OFFIS

For what it is worth, the operators tell me that data are mosaic'ed whenever possible, depending on the series. Therefore, I doubt we can improve speed by reducing the number of data chunks sent for the whole dataset: | series | files | +----------------------------------------------+-------+ | 0000...

Yes, I had already tried --bit-preserving , but I can try again in this context. Here is an excerpt of the verbose log file: [...] 2022-06-22 09:54:16.964 DEBUG: DUL: disabling Nagle algorithm as requested at runtime (TCP_NODELAY=1) 2022-06-22 09:54:16.965 DEBUG: Association Received: 10.15.1.69 202...

We experimented with a much larger dataset to obtain meaningful timing values: 000001_AAHScout 000002_AAHScout-MPR 000003_t2-loca 000004_b1-map-xfl-sag-Amplitude 000005_b1-map-xfl-sag-Phase 000006_b1-map-xfl-sag-B1-Ampli-CP-mode 000007_b1-map-xfl-sag-VR 000008_b0-gre-field-mapping 000009_b0-gre-fiel...

I have started testing C-STORE requests, from the console of our 7 T Siemens MRI running syngo MR B17 on Windows XP, to our test storescp instance. I started with our test storescp logs set to DEBUG , which shows the Max PDU size sent by the Siemens console is 262144: [...] 2022-06-22 09:54:16.964 D...

I am not certain I can install DCMTK on the Siemens MRI consoles. In any case, between my Linux machine and the Linux storescp server, currently running DCMTK 3.6.7: $ storescu --debug neurospin-dicom.xxxxx.xxx.xx 1104 --scan-directories 000021_mp2rage-iso0.65-iPAT2-angulated-UNI-Images [...] D: ===...

Ok, probably Siemens uses a hard-configured DICOM packet size, no matter what the SCP offers. I plan on testing against the Siemens MRI consoles in the next few weeks. Would you be able to recommend a simple way to identify this hard-configured DICOM packet size? Just try different -pdu arguments?

I have just tried -pdu 100000 , in conjunction with TCP_NODELAY=1 or not, it has no visible effect. The next step would be to test these same storescp options when sending data from the Siemens consoles. Unfortunately I need to be in front of the MRI consoles to send data, I cannot do that remotely,...

Finally I have tested setting TCP_NODELAY again and I do see better transfer rates, together with --ignore 104 MB/s or approximatively 830 Mb/s for the large dataset and an impressive × 4 improvement for the small dataset (although the transfer speed remains much lower due to the startup overhead I ...

Option --bit-preserving does not help further improve transfer rates from the Linux machine. I guess it won't help much with Siemens consoles either. Plus it is not compatible with --sort-on-patientname which we use with --eostudy-timeout . Option -dhl does not seem to be helping either in this case.

Option --ignore does have a radical effect. Data transfer speeds now exceed SSH speeds, typically: $ time storescu neurospin-dicom.xxxxx.xxx.xx 1104 --scan-directories 000017_mbep2d-iPAT3-MB2-1pt2mm-AP-run2 real 0m21.488s user 0m1.300s sys 0m1.779s $ $ time storescu neurospin-dicom.xxxxx.xxx.xx 1104...

Following up with your suggestions in thread Slow transfer rates (this time with actual measurements).

Oh, it looks like gdcmscu doesn't like the documented long --input option, I have to use the short -i option instead. With that bug out of the way, I get similar transfer rates, with gdcmscu actually a bit slower on larger data: $ time gdcmscu --store neurospin-dicom.xxxxx.xxx.xx 1104 --recursive -i...

Any way, sending data from my Linux machine is indeed faster than from the Siemens consoles. I still plan on testing some of the storescp options suggested in the previous thread.(--bit-preserving, --max-pdu, --ignore, TCP_NODELAY) when executing C-STORE operations from my Linux machine, just in cas...

I am restarting the Slow transfer rates thread, this time including measurements of transfer rates between a Linux Ubuntu client machine and the CentOS 6.5 server running storescp (initially DCMTK 3.6.6 and now DCMTK 3.6.7). I will be sending two series of DICOM files: 000017_mbep2d-iPAT3-MB2-1pt2mm...

I'm not so certain any more that TCP_NODELAY saved the day. That's what operators had told me, but then I've compared the figures they had sent back in February (without TCP_NODELAY) and in May (with TCP_NODELAY), and they seem similar to me, not to say that it's worse with TCP_NODELAY :( I intend t...