multi threading

  • Hi,


    You are right: channel is only for import converters.


    The export converters have a separate thread for each line in dicom.ini, but one thread per line. So my previous post was wrong.


    Import converters run on the same thread as the association so if you recieve on 10 threads it will export on 10 threads, hence the channel * to keep a separate channel (which keeps the connection open as long as possible) per thread.


    As regards the poor performance I think you are 'choking' the server by opening 10 assocations at once and export converters do not like this. How many cores do you have?


    Marcel

  • It is performing great with tremendous speed no matter how many I send at once (I have tried up to four, 2 CT, 1 DR, 1 US). This has a XEON CPU E-2670, which is eight cores. If we go to production with this, I will have 4 instances of Conquest running and each one will have many incoming at once. I could see where I may have 20 or more incoming spread across the 4 instances, including MG, MRI, CT, US, DR. I watch the performance and with the 32 gigs and SSD drive, it is extremely fast.


    It is the multi-threading I need. Not sure how to implement it. Along with the data coercion


    If I understand correctly, if my sending AET does 5 associations, then Conquest will send in 5? I don't see that on the incoming AET, I only see 1 at a time.

  • Hi,


    Good to hear the performance is good. The latter multithreading type only accurs with (non-delayed) ImportConverters. I guess we could try to develop a muli-threaded forwarder in lua. You would use e.g.


    process study after 60 by forwarder.lua(%VStudyInstanceUID,%u,TARGET)


    And then start multiple instances from there using servercommand("luastart:......"). But this requires a bit of puzzling out. Especially how to split the move into 5-10 separate ones without duplication. I think I once did that once by filtering on the last character of SOPInstanceUID.


    Marcel

  • I got it working! attached is my dicom.ini. It received and sent with multi-threading. It sent as it came in. I want it to do it at study level though, so I added another line. Seems to be working great. I setup to not use anything with the export converters. Please check it and tell me if this is right. I see in incoming AET with multi-threading. I am not sure it is doing it at the study level though, I don't think so.


    All I need now is how to data coercion.

  • It is ok to store. I don't keep the images anyway in Conquest. I see the move command is working, but it is not removing from MAG0. How do I get that to happen automatically. I would like all data in MAG0 deleted at 3:00 am every day, 7 days a week.

  • Marcel, I tried taking the command out of the import converters for sending at study level and unblocked the other one (ForwardAssociationLevel = STUDY) and it still forwards at the image level. Is it not possible to forward

    at the STUDY level when using ImportConverters?

  • Hi,


    Did you leave the channel * in there? If not it would try to pump eveything through the same channel likely making it close the channel very often. Import converters do use ForwardAssociationLevel and should be written as:


    forward compressed as JS to AE org %u channel *


    Marcel

  • yes, channel * is in there. I can see it forwarding (barely, it is so fast) image by image and not at study level. I tried with ForwardAssociationLevel = STUDY not blocked and then I blocked it and put in the

    ImportConverters: ImportConverter0 = forward study to RSAPACS


    I took out the "org %u" as for now I want them to go out with Conquest AET.


    The images go out over multiple channels (multi-thread) fine. I can see all the different channels and I can also see it coming in multiple threads on the incoming PACS.


    Again, it seems that as soon as Conquest receives the image from a study it turns around and sends it. It does wait until the entire study has been received and then send the study out using multi-threading.


    Where should the command to do at study level be? In the ImportConverters or the other way?

  • Hi,


    Maybe it is fine. It forwards image by image but over the same association as much as possible. That makes it as fast as it can go. Logging maybe 'constipated' to see what actually goes on enable log to file only.


    Marcel

  • oh, it is difficult to read, alright. BUT, I have had outbound studies going out from the PACS go at image level (as an experiment) and it is way too much. We have about 600 studies a day going out to at least 3 destinations at once, using multi-threading directly from the PACS and it creates such a log jam. We had to go back to study level, but that is ok from the PACS, as it does multi-threading. It is the incoming we need to control. So, I HAVE to have it at the study level and I can't seem to make it work. It works great using ExportConverters, but using ImportConverters it seems to ignore the FowardAssociationLevel = STUDY (as you stated) and if I put in the ImportConverters using what I read in the manual as using the list provided for all importconvert "I" and exportconverter "E" commands as "ImportConverter0 = forward study to RSAPACS" it does not pay attention to it. I have the next ImportConverter command as "ImportConverter1 = forward compressed as JS to RSAPACS channel *". It seems to ignore the first command and do it at image level. Do I have to reverse them?

  • I can't seem to get "Clear image database" to do anything. If I click it, it just goes to "Clearing database" and then "[AET] Initializing Tables" but does nothing else and the data directory for that AET still has all the studies in it. I have to manually delete them and then regen a single device

  • attached is the dicom.ini (as txt file) and the log. I have it set now to NOT tell it the compression as I have Conquest already set to store anything from AET in "JS" compression, so I don't need it to change the compression when sending. I also have the "channel *" in there.


    I unblocked the "ForwardAssociationLevel = STUDY".


    Does Conquest read the FowardAssociationLevel = Study command BEFORE the ImportConverter0 command? Is that what is wrong, I have to move the ImportConverter0 command in the dicom.ini BEFORE the ForwardAssociationLevel = STUDY command?

Participate now!

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