At one of our sites, the Conquest PACS system has days where it will just slow to a crawl. Specifically, any images from the various ultrasound modalities will suddenly trickle to the server. Pulling images from PACS is fine, it is just that the images are not there to pull in a timely fashion.

We noticed in the Conquest logs multiple repeating entries similar to:

UPACS THREAD 0: ENDED AT: Thu Oct 19 09:23:58 2006
UPACS THREAD 0: TOTAL RUNNING TIME: 0 SECONDS

We also discovered that by turning off one specific ultrasound machine, the log messages would go away, and things would speed up. Now we are trying to figure out why/how this one GE Voluson is causing issues with Conquest.

This problem seemed to occur out of the blue. Things were working fine for the longest time. Also, we have Volusons at other clinics, and do not have this problem. My colleague suggested using a packet sniffer called Wireshark, and that has unlocked some more clues about this problem.

Those THREAD 0 log entries in Conquest are a result of the Voluson sending TCP Window Request packets to Conquest. Research has told me that the TCPWR packet is essentially used by the receiving system to acknowledge a specific amount of data has been received, and to send the next chunk.

Monitoring a normally functioning system illustrates this very well. When a modality sends data to PACS, PACS will reply with a bunch of TCPWR packets. Also, when PACS sends images to a review station, that review station will likewise reply with TCPWR packets. So this tells me something is wrong with the Voluson, since it is sending PACS the TCPWR packet, repeatedly, without receiving any data to prompt such a packet.

GE has been made aware of the problem and of the issue with TCPWR packets. Hopefully they can solve the problem in short order, although I expect it will not a straightforward process to figure out this particular issue.

Bookmark to: