looking for a way to speed up study sending

    Hi everyone


    We have a doctor in a remote location connected via vpn. He has a decent net - speed test showing around 40/8Mbit connection with ping oscillating in 15-25ms range (stable, no packet drops).

    The problem is the speed - it's nowhere near the network cap. From what I can see it's about 2-3 images per second (700-800kb/s)

    At the same time I can download the same study at a rate of 20+ images per second (5-6Mb/s).


    Same vpn, same client (radiant), same server (1.4.19d1). The only real difference is that I'm much closer so much better ping to the server (100/100Mbit with 2ms ping).


    The interesting thing is that he can do a little trick using Horus/Osirix - they have an option to download a single series - so basically he can order the download of each series separately >at the same time< making whole process parallel and thus MUCH faster.


    So clearly it IS possible to download the study faster (I can do it, and he can do it using this trick) so the network bandwidth is not the problem. Nor the server, nor the client..

    The only thing left is latency and network overhead.


    Now the 100$ question - is there a way to speed up sending? Some setting maybe? Some way to make it parallel? Is dicom standard really this sensitive to latency or am I missing sth here?

    Hi,


    because DICOM uses handshaking per block, the latency is the issue. Larger block sizes would help. What PDU size does it report on communication? You can try (for a test), 1.5.0 from github (link in top post), this will likely accept larger block sizes.


    Of course, you could also instruct conquest to send data in parallel, using multiple moves at once. But currently it would not do that by itself.


    Marcel

    Thx for quick answer


    Pretty much all the clients report 16k PDU except for Efilm which uses 64k PDU size.

    Is it possible to force larger blocks? or is this one of those things which has to be negotiated and accepted by both sides (server and client)?

    This is becoming a real issue because with each passing year more and more doctors prefer to work from remote locations.

    Right now it's sometimes (if a client has about 50ms latency) faster to zip whole study, download it via shared folder and then unpack it than send it via dicom protocol. :(


    I'll try 1.5.0 and compare the results.


    Patryk

    Unfortunately I can't see any difference using 1.5.0 (unless I should do sth more than the usual .exe/dll replacements)

    Quote


    you could also instruct conquest to send data in parallel, using multiple moves at once.

    This sounds interesting... Could you please elaborate a bit about this? Would it be possible to respond to a clients query with parallel move?? like, for example, send each series simultaneously?

    I'm not sure how would it work... can this be done using lua? If possible this would speed up sending considerably (not so long ago I was experimenting with this a bit and found out that speed gain from using 4 parallel 'lines' gave me close to 4x the speed. I expected to hit some diminishing returns at this point but no - the gain was almost linear.

    Hi,


    would it be possible to add a conquest dicom server at the remote site, setting up the central site as VirtualServerFor0 in dicom.ini there and having the remote viewer work from the remote conquest? This would allow more control over the communication, such as change the PDU size. In addition it would be maybe possible to prefetch data. By the way, conquest 1.5.0 would request a PDU size of 32k (e.g. for the return connection of C-MOVE), so apparently radiant limits it to 16k.


    Marcel

    Hi,


    it is in theory possible to intercept a move request with ([lua]RetrieveConverter0), and then spawn in response multiple moves (using servercommand('luastart:code') where each move is passed in the code string. But this is far from trivial and requires a lot of lua coding. Version 1.5.0 is better equipped because DICOM objects there have a 'Serialize' method to write them out as text.


    'Pseudocode' in dicom.ini:


    [lua]RetrieveConverter0 = if Association.Calling == 'SLOWAE' then dofile ('parralelize_move.lua') end


    And for parralelize_move.lua:


    Not tested at all! To try I would use two conquest dicom servers and print out info along the way.


    Marcel

    Thank you for all the help.


    I'll start with second server on the remote location - 32k PDU should help ( I hope ).

    As for the lua I do understand what you are trying to do here but I'm not sure I'm brave enough to do it this way.

    I was hoping that this would a bit easier (like an option in dicom.ini :) ) but oh well.. if first solution won't work then I might still try the lua parallelization.


    Thx again!

    I have come across this as well.

    We are storing everything in j2 compression, which is a lot smaller than uncompressed. But some of our review stations and clients have issues with certain images, so the only good way for us to send them is uncompressed.

    In the local office, that is no issue, but for remote sites this was unworkable.


    So to fix this, we set up a Conquest server on each of the machines that will accept all images as j2, and forward them uncompressed to client.

    Works very well for us and sped up transfers a lot.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login