we have been testing PACONE v5.1.1 (premimum) is a semi production mode over the last 30 days.
our testing scenario is as follows:
test hardware:
--Intel p4 2.8 mhz
-- 80 gig hard drive
-- 1 gig ram
-- intel 10/100 network interface (running 100 mhz full duplex)
test software :
--- MS window 2000 server (sp4)
--- Apache v 2.05
--- PACone v5.1.1
--- PHP 5.05
--- MySQL 5.0
test environment:
1. auto routing from local modalities (CT,RG,US) to remote PACS via PACSONE.
2. auto routing via VPN to remotes PACS.
Problems:
1. Auto routing comsumes vast amount of bandwidth on local net
2. sometime ct scan images fail to route except head scouts.
3. Image take long time to reach remote PACs versus another PACs we are using for routing (nova PAcs)
Note: both AETITles of the local modalities and the remote PACS are known to each other.
the remote PACS does not know the AEtitle of the local PACONE.
Please advise.
A
automatic routing with PACONE
This seems to be a typical problem when trying to push a large imaging volume through a narrow-band network link. But for a fixed amount of imaging volume, the network transfer time is inversely proportional to the available bandwith of the network link, i.e., the bigger the network pipe, the faster the images will be delivered.
1. If you want to reduce the amount of bandwidth the routing of images can consume, then it will take longer to route the same imaging volume.
2. To speed-up the delivery of images, you'll need to increase the network bandwidth, e.g., upgrade to Gigabit-Ethernet or even 10-GigE from your current 100 Mbps LAN.
The alternative would be reducing the imaging volume being transferred through the network, by compressing the original images being transferred. This solution requires the destination AE being capable of receiving images in the Dicom compression transfer syntaxes. If you know for sure the destination AE supports Dicom compression transfer syntaxes, then you can change the Preferred Transfer Syntax definition for the destination AE from the Dicom AE page of PacsOne to one of the following transfer syntaxes for lossless compression:
Dicom JPEG Lossless Compression
Dicom RLE Compression
This method will make PacsOne compress the images being routed before transferring the compressed image through the network.
1. If you want to reduce the amount of bandwidth the routing of images can consume, then it will take longer to route the same imaging volume.
2. To speed-up the delivery of images, you'll need to increase the network bandwidth, e.g., upgrade to Gigabit-Ethernet or even 10-GigE from your current 100 Mbps LAN.
The alternative would be reducing the imaging volume being transferred through the network, by compressing the original images being transferred. This solution requires the destination AE being capable of receiving images in the Dicom compression transfer syntaxes. If you know for sure the destination AE supports Dicom compression transfer syntaxes, then you can change the Preferred Transfer Syntax definition for the destination AE from the Dicom AE page of PacsOne to one of the following transfer syntaxes for lossless compression:
Dicom JPEG Lossless Compression
Dicom RLE Compression
This method will make PacsOne compress the images being routed before transferring the compressed image through the network.
As suggested, i have set the maximum connection =1 and preferred transfer= 'JPEG lossless' to show improvement in the transfer performance of the images, but to no avail. ( i.e. a slow down of LAN performance and a number of "failed SOP instances".
Question: In Auto routing, should the AETitle of the pacsone be known to destination SCP( a NovaPacs system) . Of course the aAETitle's of each of the transferring modalities and the SCP (NovaPacs) are known to each other.
The pacsone is run in a semi-parallel fashion to another system (Nova PACS which does not have this problem.
Question: In Auto routing, should the AETitle of the pacsone be known to destination SCP( a NovaPacs system) . Of course the aAETitle's of each of the transferring modalities and the SCP (NovaPacs) are known to each other.
The pacsone is run in a semi-parallel fashion to another system (Nova PACS which does not have this problem.
Yes, you should make the AE Title of PacsOne known to any AE that PacsOne connnects to (sending to or receiving from). Otherwise, the connection request from PacsOne may be rejected by the remote AE if the AE Title of PacsOne is unknown to that AE.dwilljch2 wrote: Question: In Auto routing, should the AETitle of the pacsone be known to destination SCP( a NovaPacs system) . Of course the aAETitle's of each of the transferring modalities and the SCP (NovaPacs) are known to each other.
To make a fair comparison, you should run PacsOne and NovePACS on the same host, so that both software can share the same networking and computer resources. Then the difference is purely software related and it's more like apple-to-apple comparison.dwilljch2 wrote: The pacsone is run in a semi-parallel fashion to another system (Nova PACS which does not have this problem.
This usually means this remote AE has included some extra/bogus data element in the C-ECHO-RSP response sent back to PacsOne.
If you could send the current version of the php/dicom.php script under the directory where PacsOne Server is installed to pacsone@pacsone.net, we can add some debugging statement to dump the content of the C-ECHO-RSP received from this remote AE, which should reveal what data element is the culprit.
If you could send the current version of the php/dicom.php script under the directory where PacsOne Server is installed to pacsone@pacsone.net, we can add some debugging statement to dump the content of the C-ECHO-RSP received from this remote AE, which should reveal what data element is the culprit.