Posts by blub_smile

  • Export Convertes (again) - DICOM routing

    Hi


    No it is not working with incoming folder, but with drag-n-drop it is fine. I can remember it was working once before, and as far as I can recall I did not change anything - just did not have any time recently to continue testing on my routing.


    Today I tried v.17d and .17e


    dicom.ini :


  • Export Convertes (again) - DICOM routing

    Hi!


    I have another question regarding export converters. My forwarding per series works just fine when either the data is received via DICOM network or per drag and drop to the GUI.


    However it somehow does not work if I copy the DICOM files to the \data\incoming\ folder - is that actually supported?


    The reason I am asking this is to create a "fail save, last resort" CD/DVD importer (i.e. if no DICOMDIR is available) - I want to use a batch script to copy all the DVD content to the "incoming" folder so that Conquest the reads the DICOM complaint files and the forwards them to our PACS.

  • Need to anonymize studies going to a certain AET

    Hi


    I need to anonymize studies which are going to be sent from one of my Conquest server to one specific client.
    Since I am a NOOP when it comes to converters and LUA I need a little help :P


    this is what I have come up with so far:


    ExportCalledAE0 = PACS
    ExportCallingAE0 = REMOTEHOST
    ExportConverter0 = anonymize_script.cq
    ExportConverter0 = forward compressed as jk to REMOTEHOST


    Would that work or is there a major flaw in my logic?


    thx for the help

  • dgate performance and regen

    Write speed in MB/s is not relevant for DB for that IOPs is mor einteresting and those are low for 7.2K driver so DB usually need 10 or 15K drives. But since all is good now there is no need to argue about that :-)

  • dgate performance and regen

    Hi


    Glad to hear!


    Your HDD speeds where subterranean - with decent HDD 10k rpm for DB and OS with Conquest on another drive the speed should have been around 20-40 images/s - so not too far from your speed with SSD now as at a certain point network speed (small files) and overhead accumulates.


    With SSD you could try sending a large study from 2 clients at once - if your RAID is fast speed will still go up...

  • dgate performance and regen

    I did only change the basic stuff:


    [code][Basic settings


    Here are 3 settings that you should always look at. If you do not, you are very likely to run into problems very quickly.


    innodb_buffer_pool_size: this is the #1 setting to look at for any installation using InnoDB. The buffer pool is where data and indexes are cached: having it as large as possible will ensure you use memory and not disks for most read operations. Typical values are 5-6GB (8GB RAM), 20-25GB (32GB RAM), 100-120GB (128GB RAM).


    innodb_log_file_size: this is the size of the redo logs. The redo logs are used to make sure writes are fast and durable and also during crash recovery. Up to MySQL 5.1, it was hard to adjust, as you wanted both large redo logs for good performance and small redo logs for fast crash recovery. Fortunately crash recovery performance has improved a lot since MySQL 5.5 so you can now have good write performance and fast crash recovery. Until MySQL 5.5 the total redo log size was limited to 4GB (the default is to have 2 log files). This has been lifted in MySQL 5.6.


    Starting with innodb_log_file_size = 512M (giving 1GB of redo logs) should give you plenty of room for writes. If you know your application is write-intensive and you are using MySQL 5.6, you can start with innodb_log_file_size = 4G.


    max_connections: if you are often facing the ‘Too many connections’ error, max_connections is too low. It is very frequent that because the application does not close connections to the database correctly, you need much more than the default 151 connections. The main drawback of high values for max_connections (like 1000 or more) is that the server will become unresponsive if for any reason it has to run 1000 or more active transactions. Using a connection pool at the application level or a thread pool at the MySQL level can help here./code]

  • dgate performance and regen

    Hi


    Regen speed depends on the read speed of the RAID where the DICOM data is stored and on the database type and speed of the driver the DB is on.


    Though I use windows my regen speeds with CT/MRI images where between 230-400 images/s (average around 300)- depending on image size and or if it was a continuous or more random read.


    DB: MySQL
    DB drive: Intel SSD
    32GB RAM


    I can't think of any reason why write speed of Conquest would drop using Linux and MADM with so much free space left. So I am pretty sure it is related to DB performance.


    I can pull my MySQL setting on the weekend and pot them here. Otherwise you can do some research on the internet regarding optimal MySQL settings - isn't that many settings that are needed

  • Large studies number - low speed

    I have never seen an issue with query speed when using MySQL on a proper machine.
    Even MySQL standard parameters performed ok on a DB size of 25GB.


    As for receiving sped I have seen rates between 10and over 100 images/s - that just depends on network speed and receiving PC and software - some DICOM softwares are faster receiving noncompressed DICOM files


    EDIT:
    However I remember having performance issues when I tried postgres but I cannot remember if it was during query or actually receiving studies

  • All studies transfer

    I once moved to a new server with a volume of roughly 4TB of dicom data.


    The best way was just via drag'n'drop the aold storage directory into the new Conquest server interface. This way your data will be moved to the new server and directories including the change in compression (v2 vs std dicom) - takes a while though even 1Gb connection

  • Prefetcher option

    Hi


    I just tested the "prefetcher" option and set:


    Prefetcher = 1


    I cannot see any RAM or CPU load difference to the setting of =0 when doing queries - no matter if the query return 1, 10, or 200 results?
    Do I have to set it higher, i.e. 20 ?

  • Export Convertes (again) - DICOM routing

    Hi


    Can I also select multiple Calling AE's seperated by ";" like this in one ExportConverter / Rule:


    Code
    ExportConverters                  = 1

    ExportModality0                   = CT

    ExportCalledAE0                   = PACS

    ExportCallingAE0                  = SOURCE; SOURCE2

    ExportConverter0                  = forward compressed as jk to DESTINATION

  • Export Convertes (again) - DICOM routing

    Ok, that explains why Conquest waits until the study seems to be received completely.
    However I am still wondering why there is nor entry of "ExportConverter0W in the log when sending it later on.


    My setting was:
    ForwardCollectDelay = 10


    I now set it to 30 and Conquest waits longer, but nowhere near 30s more like 20s - strange but I could life with that.

  • Export Convertes (again) - DICOM routing

    Ok


    Just gave it a try and the result is little weired.


    When I use:


    Code
    ExportModality0                   = CTExportCalledAE0                   = PACSExportCallingAE0                  = SOURCEExportConverter0                  = forward compressed as jk to DESTINATION



    I get instant forwarding - output serverlog:


    Code
    02.06.2015 20:18:28 [PACS] Rewritten file: C:\0-pacstest\pacs-2\data\20075150\1.2.392.200036.9116.2.6.1.48.1214859555.1432371850.616526_0008_000040_14331808820027.dcm02.06.2015 20:18:28 [PACS] ExportConverter0.0: forward C:\0-pacstest\pacs-2\data\20075150\1.2.392.200036.9116.2.6.1.48.1214859555.1432371795.431104_0006_000035_14331808830071.dcm to DEST02.06.2015 20:18:28 [PACS] Accepted compression: jk02.06.2015 20:18:28 [PACS] ExportConverter0.0: forward C:\0-pacstest\pacs-2\data\20075150\1.2.392.200036.9116.2.6.1.48.1214859555.1432371795.431104_0006_000036_14331808830072.dcm to DEST02.06.2015 20:18:28 [PACS] Accepted compression: jk02.06.2015 20:18:28 [PACS] ExportConverter0.0: forward C:\0-pacstest\pacs-2\data\20075150\1.2.392.200036.9116.2.6.1.48.1214859555.1432371795.431104_0006_000037_14331808830073.dcm to DEST02.06.2015 20:18:28 [PACS] Accepted compression: jk02.06.2015 20:18:28 [PACS] ExportConverter0.0: forward C:\0-pacstest\pacs-2\data\20075150\1.2.392.200036.9116.2.6.1.48.1214859555.1432371795.431104_0006_000038_14331808830074.dcm to DEST02.06.2015 20:18:28 [PACS] Accepted compression: jk



    When I use:


    Code
    ExportModality0                   = CTExportCalledAE0                   = PACSExportCallingAE0                  = SOURCEExportConverter0                  = forward series compressed as jk to DESTINATION



    It waits until all data is received from SOURCE and the starts sending to DESTINATION series by series per association - so it is not sending images instantly and neither starts sending after 1st series is received!?


    And the most strange part is that there no word of "ExportConverter0" in the log while receiving and forwarding !?


    :mrgreen: - total confusion


    Looks like this - excerpt of last receiving and 1st beginning sending lines: