Posts by ljaszcza

Well, I lasted longer (I think) but hung again.

I will dig around the mysql forums and see what I can find.

Anyone with other ideas/experience they can share?

LJJ

No, hung up again. Hmm. This is a relatively fast new machine, server 2003 sp2.

Ok, tcptimedwaitdelay is set as low as possible 1e (30)
maxuserports is fffe (65534)
And I still hang during large drag/drops.

I will try adding:

MaxHashTableSize = 65536 (Decimal)
MaxFreeTcbs = 16000 (Decimal)

see if that makes a difference.

Also, I was thinking. The dicomini setting: tcpiptimeout. I should probably reduce that back to the default 300, right? Extending it will potentially make my problem worse.

Any other ideas?

LJJ

That's where that was. I knew I read about the disconnects. You may want to make that a sticky.

Anyhow, the registry changes :
Code:
REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"MaxUserPort"=dword:0000fffe
"TcpTimedWaitDelay"=dword:0000001e

were already in place.

I did change my dicom.ini tcpiptimeout from 300 to 900 and trying it again.
LJJ

got it, thanks.

I need to throw out an issue.
I am running a mysql 5/conquest 14beta system.
When I drag/drop directories, the system often hangs after some number of files. The problem seems to occur more often with one hospital, but the problem is sporadic. That is, we hang on file x, I reboot, file x goes next time. The institution is not unique in that I get films from several similarly equipped institutions (centricity/radworks, toshiba aquillion CT, HD4000 US).

The problem is that the instance of conquest stops resopnding in the middle of processing files. A look at Mysql administrator shows multiple connections. If I let the system sit, the number of connections increases until mysql stops accepting new connections. Stopping/starting the conquest service or mysql service does not solve the problem. I am using the modified my.ini as set forth in the manual. The problem requires a reboot. The problem seems to occur when the system has a large number of small files to process (large CT/MRI sets).

I suspect it may be a mysql issue (rapid disconnects?) but am not good enough at mysql troubleshooting/optimization. I have been fighting with this since I tried to rebuild my image files in noncompressed form with conquest 12c.

Anyone have any ideas or solutions?

LJJ

I have a suspicion that this is a mysql problem

I am trying out conquest 14beta. On startup of the GUI I get a message that says something like "added missing / to mirrordisk, please fix dicom.ini"

My dicom.ini has the following:
# Configuration of mirror disk(s)
MIRRORDevices = 1
MIRRORDevice0 = \\n5200\usbhdd\fairdicom\three

I don't see what I am supposed to fix... Anyone have insight? I am mirroring to a NAS drive.
LJJ

Has anyone gotten a Kodak (lumisys) ls75 film scanner to work with k-pacs?
I don't have the original CD and can't locate a twain driver anywhere. I am running XP.
If anyone can help, please write!
Thanks,
L.J.J

No problem with the Fuji Carbon or Mammo CR solution...
LJJ

Marcel,
I just double checked my dicom.ini in my test conquest and the IgnoreOutOfMemoryErrors = 1 statement is absent. This is the second time that I have been really sure that I put it in and then I look and it is not there. Am I being exceedingly forgetful or can conquest parse/change dicom.ini? I am running 5 instances of conqest for various purposes so I may just have forgotten to change the test version...
So, now, I am not sure whether the IgnoreOutOfMemoryErrors = 1 flag works or not. I will write again later in the week.
But, the littleendianexplicit is disabled.
LJJ

K-pacs allows pushing of whole studies. Just select the patient name, press the (export ? I forget which) button and the whole study will go over...
LJJ

Hi Marcel,
lots of problems with NKI storage on disk and out of memory errors with the Feb10 14alpha and ignorememoryerrors = 1 flag. The images are viewable in Conquest but pulling or pushing them out uncompressed yields out of memory errors. The issue seems to happen with decompression from NKI. I am converting to noncompressed storage until the memory issues get resolved.
Leszek

Hi Marcel,
I am running into a lot of new memory out problems with latest Feb10 alpha of conquest 14.
I thought that jpeg may be the problem so I switched to NKI storage on disk. This is what I get when I try to send a series of scanned films to efilm. So, MAG0 storage is NKI, transmission UN, debug log on:

[FAIRLIGHT1] MyPatientRootRetrieveGeneric :: RetrieveOn
[FAIRLIGHT1] Sending file : F:\dicom\CB8269\1.22.333.4444.55555.20071203101357.1.1_0001_000001_12033432312934.v2
[FAIRLIGHT1] Image Loaded from Read Ahead Thread, returning TRUE
[FAIRLIGHT1] ***VR:ReAlloc out of memory allocating -536805378 bytes
[FAIRLIGHT1] MyPatientRootRetrieveGeneric :: RetrieveOn
[FAIRLIGHT1] Sending file : F:\dicom\CB8269\1.22.333.4444.55555.20071203101357.1.1_0001_000002_12033432312935.v2
[FAIRLIGHT1] Image Loaded from Read Ahead Thread, returning TRUE
[FAIRLIGHT1] ***VR:ReAlloc out of memory allocating -536805378 bytes
[FAIRLIGHT1] MyPatientRootRetrieveGeneric :: RetrieveOn
[FAIRLIGHT1] Sending file : F:\dicom\CB8269\1.22.333.4444.55555.20080108102240.1.1_0001_000001_12033432312936.v2
[FAIRLIGHT1] Image Loaded from Read Ahead Thread, returning TRUE
[FAIRLIGHT1] ***VR:ReAlloc out of memory allocating -536805378 bytes

So, a set of dicom images is sent and stored by conquest, they are 2.5meg CR images. When I try to push them or pull them to a workstation the above problem occurs. It is confusing as other similar image sets transfer correctly.

This problem also occurred with CT. Both modalities have been problem free for a year or more with older versions of conquest. I have the Ignoreoutofmemoryerrors = 1 in dicom.ini. I think the problem is with compression and conquest 14alpha Feb10 (although all conquest >12c have been problematic. I will try to store uncompressed on MAG0 and see if it helps. Any comments?

LJJ

Well, I use a mysql system. Including downloading and installing mysql, setup is 1-2hours on a basic windows xp box. The biggest hassle is putting together an optimized mysql.ini file...
I have been very happy with maintenance. The system needs none really. I use diskkeeper to maintain the ntfs disk automatically. The mysql does not have any restrictions like MS SQL and has been entirely trouble free. I have disk mirroring so backup is automatic.

Now with version 13, I ran into conquest out of memory crashes but that problem is fixed with 14alpha I think. Typically, Conquest/MySQL requires no regular maintenance. I check for disk space, or unforeseen events like hardware failures, etc.

Our machine handles 1.5 million images on 27,000 patients, all modalities. I have no experience with worklist issues.
Hope this helps.
LJJ

I feel like a kid with a Christmas gift.
Thanks,
LJJ

Marcel,

Can you send me conquest 14alpha with the memory error flag disabled? I very much like the patient forwarding features but I am fighting these sporadic out of memory crashes, these are quite disruptive and so far hard to track down.

Also, for the conquest install at your institution, do you store images compressed? Just curious what kind of working environment you have...
Thanks, LJJ

I will use the 14alpha and forward any feedback.
I have been using a pretty simple forwarding scheme;

ExportConverter0 = forward patient age -360+0 modality CR to FAIRLIGHT5

for testing. This has worked quite well. I will have time next week to try some more complex scenarios. If you care to send more documentation of new export options I will try them out.

I did try to forward patient by modality %m but ran into problems with a couple of CT scanners. They send images one at at time over a fairly slow link (1 minute per image) and I was seeing hundreds of images forwarded by conquest on a 30 image head CT. I think I can minimize the problem by setting the delays and moving the problem machines to a dedicated instance of Conquest...
Thanks, Leszek

Hello Marcel

Thanks for the update. Well, --checklargestmalloc: seems unchanged from 13b. I get 910mb on one machine (4gb installed) and 980mb on an older machine with 2gb memory installed. I will see if things are more stable over this week.
I also switched to NKI for storage. I have seen some slowdowns in transmission of multiframe US and feel that the problem may lie in JPEG handling of large files. I transfer the 3D raw data along with the images too.
I will write again later in the week and update you.
Anything else to know about 14alpha?
Thanks, LJJ

I am running into somewhat sporadic out of memory errors in conquest 13b. I do not recall this problem with 12c or earlier. The problem occurs with both of my GE US machines. It seems to happen with 3D/multiframe data sets although the problem is somewhat sporadic ie, several cine or 3D sets will go through, another won't. I get the malloc error message and the server restarts.
This is actually another problem as the server only restarts if the GUI is running. If not, the service uninstalls, does not start, and I get phone calls that the system is down...
I am having a hard time trouble shooting this issue as it is somewhat inconsistent. I almost wonder whether this is some sort of hardware issue. But, I did not see problems before v13 so I am left uncertain.
Right now I am storing with JPEG losless on disk. The US sends uncompressed. I did read the sticky on "out of memory errors" and implemented the suggestion. After that fix, the issue became less frequent but still happens daily.
Does anyone have experience with a similar problem or ideas?
Thanks,
LJJ

PS Marcel, the 13b patient forwarding is working well as far as I can tell. I have not written you as I am somewhat uncertain if the above problem relates to the patient forwarding. I think I will put the two US machines to a 12c install and see what happens. Hopefully I will get a chance to do this over this weekend. ***Readers, this refers to an unreleased version of Conquest***

Thanks Marcel,
I will wait for an email...
Leszek

[FAIRLIGHT] A-ASSOCIATE-RQ Packet Dump
[FAIRLIGHT] Calling Application Title : "FAIRLIGHT "
[FAIRLIGHT] Called Application Title : "FAIRLIGHT "
[FAIRLIGHT] Application Context : "1.2.840.10008.3.1.1.1"
[FAIRLIGHT] Number of Proposed Presentation Contexts: 1
[FAIRLIGHT] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.1.2"
[FAIRLIGHT] Server Command := 0021
[FAIRLIGHT] Message ID := 0005
[FAIRLIGHT] C-Move Destination: "FAIRLIGHT5 "
[FAIRLIGHT] (QualifyOn) (mapped) IP:192.168.10.73, PORT:5678
[FAIRLIGHT] MyPatientRootRetrieveGeneric :: SearchOn
[FAIRLIGHT] Query On Image
[FAIRLIGHT] Issue Query on Columns: DICOMImages.SOPClassUI, DICOMImages.SOPInstanc, DICOMSeries.Modality, DICOMSeries.SeriesInst, DICOMStudies.StudyDate, DICOMStudies.PatientID, DICOMStudies.StudyInsta,DICOMImages.ObjectFile,DICOMImages.DeviceName
[FAIRLIGHT] Values: DICOMSeries.Modality = 'CR' and DICOMStudies.StudyDate >= '20060511' and DICOMStudies.StudyDate <= '20080101' and DICOMStudies.PatientID = 'WTF790' and DICOMStudies.StudyInsta = '1.22.333.4444.55555.20080101123946.1' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
[FAIRLIGHT] Tables: DICOMImages, DICOMSeries, DICOMStudies
[FAIRLIGHT] Records = 2
[FAIRLIGHT] Number of images to send: 2
[FAIRLIGHT] MyPatientRootRetrieveGeneric :: RetrieveOn
[FAIRLIGHT] Locating file:MAG0 WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000001_1199210653002e.dcm
[FAIRLIGHT] Locating file:MAG0 WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000002_1199210706002f.dcm
[FAIRLIGHT] Sending file : F:\fairdicom\WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000001_1199210653002e.dcm
[FAIRLIGHT] Image Loaded from Read Ahead Thread, returning TRUE
[FAIRLIGHT] [recompress]: recompressed with mode = un (strip=1)
[FAIRLIGHT] MyPatientRootRetrieveGeneric :: RetrieveOn
[FAIRLIGHT] Sending file : F:\fairdicom\WTF790\1.22.333.4444.55555.20080101123946.1.1_0001_000002_1199210706002f.dcm
[FAIRLIGHT] Image Loaded from Read Ahead Thread, returning TRUE
[FAIRLIGHT] [recompress]: recompressed with mode = un (strip=1)
[FAIRLIGHT] C-Move (PatientRoot)
[FAIRLIGHT] UPACS THREAD 212: ENDED AT: Wed Jan 02 17:07:29 2008
[FAIRLIGHT] UPACS THREAD 212: TOTAL RUNNING TIME: 0 SECONDS