DICOM buffersize

While investigating the performance of dgate.exe I found that the speed is limited by the current buffer size in pdata.cxx, which is set to 4096 bytes. By enlarging this BlockSize in PDataTF::Write() to e.g. 262144 I observed a speedup of approximately 40% on a local DICOM server for a test case of 680 slices.

I tried to find some references for the optimal buffer size and found this link: https://stackoverflow.com/ques…ecv-in-the-socket-library, where 256kB is advised.

Do you think it is a good idea to increase the buffer size in a future version?

Lennert.

Thank you Marcel!

I applied this change in pdata.cxx:

BOOL    PDataTF ::      Write(Buffer    &Link)
        {
        // Generate P-DATA-TF Messages.
        UINT    BlockSize, SentSize, TotalSize, TLength;


        TotalSize = VRBuffer.GetOutgoingSize();
        BlockSize = 262144; // was 4096;
(..)
}

To take advantage of this code you may also want to change ReadBlock() in buffer.cxx (currently this is a hard-coded value of 10240) and the #define DEFAULT_BREAK_SIZE of 8192 or 32600, combined with a new build of CqDicom.dll.

Hi Marcel,

In the code I found another somewhat arbitrary number related to buffer sizes. In pdu.cxx in InterogateAAssociateRQ() and also in Connect() there is this statement:

MaxSubLength.Set(16384); // we can do all DICOM can handle

This number seems to be inspired by the example value on http://dicom.nema.org/medical/…ml/part07/sect_D.3.3.html. The Conquest DICOM server itself does not take this value into account as far as I can tell. Other implementations don't accept larger buffers in e.g. PDataTF::Write(Buffer &Link), like we encountered while writing data to Pinnacle with a "BlockSize" of 262144 bytes. To be able to write to both Pinnacle and Conquest DICOM server with the same code in CqDicom.dll, would it be possible to use MaxSubLength.Set(262144) instead in a future version?

Best regards,

Lennert.

Hi Marcel,

Good to know that an update to this "MaxSubLength" is already in scope. Is your plan to adjust the buffer sizes for data transfer accordingly, or is this mainly to improve communication with external DICOM software?

Next time, I will try to make it to ESTRO!

Best regards,

Lennert.

I found the discussion on http://forum.image-systems.biz/viewtopic.php?f=33&t=44345 about the PDU size of 16384.

As Conquest DICOM Server does not take the value of MaxSubLength into account I am not surprised that changing this value to 32768 had no effect. The buffer sizes marked in yellow of 4108 bytes are most likely due to the aforementioned "BlockSize" value being 4096 bytes. Apparently, 12 bytes are added somewhere else. When running a version of dgate64.exe with BlockSize increased to 256KB the "Process Monitor" program provided by SysInternals indeed shows larger buffers being used:

13:27:20.6558062 dgate64.exe 183252 TCP Send WS0206.nki.nl:1052 -> WS0206.nki.nl:1234 SUCCESS Length: 262144, startime: 5951544, endtime: 5951544, seqnum: 0, connid: 0

For the shipped version of dgate64.exe this was:

13:29:56.2398665 dgate64.exe 193828 TCP Send WS0206.nki.nl:1093 -> WS0206.nki.nl:1234 SUCCESS Length: 4108, startime: 5953100, endtime: 5953100, seqnum: 0, connid: 0