Virtualserver aaand a problem

    Hey,


    Since virtual server is retrieving data from pacs soooo soo long...


    8-10 seconds per 1 slice, lets say its 1800 slice study.. then it will take more than 2 hours.


    If I retrieve studys manually using conquest interface, no problem... study comes at steady 8-10 mbit/s (11 up/down connection)


    Is there a way to configure virtualserver to act same way?


    problem:


    12.02.2009 11:38:52 [KLIINIKTDK]


    12.02.2009 11:38:52 [KLIINIKTDK] UPACS THREAD 541: STARTED AT: Thu Feb 12 11:38:51 2009


    12.02.2009 11:38:52 [KLIINIKTDK] Calling Application Title : "WFM1TLN "


    12.02.2009 11:38:52 [KLIINIKTDK] Called Application Title : "KLIINIKTDK "


    12.02.2009 11:38:52 [KLIINIKTDK] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 100000


    12.02.2009 11:38:52 [KLIINIKTDK] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1


    12.02.2009 11:38:52 [KLIINIKTDK] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.2" 1


    12.02.2009 11:38:54 [KLIINIKTDK] Written file: D:\kliiniktdk\dicom\xxxxxxxxxxxx\1.2.840.113619.2.55.3.279719183.503.1224665112.674.3_0003_000070_12344279000218.dcm


    12.02.2009 11:38:54 [KLIINIKTDK] UPACS THREAD 541: ENDED AT: Thu Feb 12 11:38:54 2009


    12.02.2009 11:38:54 [KLIINIKTDK] UPACS THREAD 541: TOTAL RUNNING TIME: 3 SECONDS


    12.02.2009 11:38:56 [KLIINIKTDK] Virtual server - Grabbed 1.2.840.113619.2.55.3.279719183.503.1224665112.962.70 from WFM1TLN


    12.02.2009 11:38:57 [KLIINIKTDK]


    12.02.2009 11:38:57 [KLIINIKTDK] UPACS THREAD 542: STARTED AT: Thu Feb 12 11:38:57 2009


    12.02.2009 11:38:57 [KLIINIKTDK] Calling Application Title : "WFM1TLN "


    12.02.2009 11:38:57 [KLIINIKTDK] Called Application Title : "KLIINIKTDK "


    12.02.2009 11:38:57 [KLIINIKTDK] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 100000


    12.02.2009 11:38:57 [KLIINIKTDK] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1


    12.02.2009 11:38:57 [KLIINIKTDK] Presentation Context 1 "1.2.840.10008.5.1.4.1.1.2" 1


    12.02.2009 11:39:00 [KLIINIKTDK] Written file: D:\kliiniktdk\dicom\xxxxxxxxxxxxx\1.2.840.113619.2.55.3.279719183.503.1224665112.674.3_0003_000071_12344279000219.dcm


    12.02.2009 11:39:00 [KLIINIKTDK] UPACS THREAD 542: ENDED AT: Thu Feb 12 11:39:00 2009


    12.02.2009 11:39:00 [KLIINIKTDK] UPACS THREAD 542: TOTAL RUNNING TIME: 3 SECONDS


    12.02.2009 11:39:01 [KLIINIKTDK] Virtual server - Grabbed 1.2.840.113619.2.55.3.279719183.503.1224665112.962.71 from WFM1TLN


    12.02.2009 11:39:02 [KLIINIKTDK]


    whole this process takes too much time......


    manual copy = 10-25 minutes per study


    virtual server retrieve = 2.5+ hours.... same study



    halp!


    ty!

    Hi,


    why is your application getting images one at a time? The problem is that every virtual query has to do a long query of the conected server. If you get a while series at once, all queries will be assembled to one and it will be much much faster.


    To test, try to access the virtual server from another conquest server, and see what happens then. We use the virtual server all the time and it is really fast.


    Marcel

    Indeed when I retrieved only serie (76 images), there were no such mess.. just slice after slice like doing manual dicom copy.


    Though speed was around 2-3 mbit/s vs. manual copy that can do about 7-10 mbit/s but ofcourse this maybe because remote pacs is undergoing maintenance because its almost midnight around here.


    It seems to be bug.


    Is there any workaround?


    remote pacs admins are complaining over us also because every slice we recieve = 1 job for their server. If other clients retrieve like 2000 slice study they make only 1 job.. but because of this bug its like 2000 job sessions per study that causes massive queue in remote pacs and they are kinda mad :P

    Hi,


    we have not observed the issue because we read almost all our data series by series. The problem is that the virtual server code gets an unsorted list of requests, which is than has to reassemble in one or more moves. The logic is:


    if all images belong to same patient, study and series, move all at once (specifying patient/study/series and a list of sops), otherwise move image by image.


    I can change the code, and send you a prerelease, but that would be experimental, since it is a fairly major change. Would you test it for me?


    Marcel

Participate now!

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

Register Yourself Login