Slow Upload Speed
We have an off-site pacsone server and another offsite pacs server (not sure of the brand). When we send studies to pacsone, we typically get 20 secs per image, yet the same study going to the other pacs is very fast. Since they are both using the exact same upload link (broadband cable), this should not be a limiting factor. My question is, where could this bottleneck occur? It would seem that it would be hardware related, i.e. a Pentium 4 3.0 GHz with 1G of RAM is going to be slower than a Dual Xeon 3.0GHZ with 4G RAM. But I read on other thread that the actual DICOM send/retrieve is neither CPU nor RAM intensive. So would it be hard drive access? Or is it really that a faster server will yield better results? I need to have this figured out as quickly as possible. Thanks!
You need to make sure you are actually comparing apples to apples here, i.e., when sending studies to PacsOne or the other PACS, in order to compare the transfer speed from the source AE to the 2 destination AEs, you need to make sure the traffic goes through identical network path from the source to the destination. So using the same upload link may or may not make the network paths identical because are other network elements involved, e.g., routers, switches, etc.
The best (maybe the only) way to compare the transfer speed is to have PacsOne and the other PACS plugged-in side by side into the same LAN switch or hub, then connect that switch/hub in whatever path to the source AE. This way, the traffic path from the source to the destination (PacsOne or the other PACS) is identical except for the last hop, which can be ignored since the latency difference among the switch/hub ports should be indistinguishable.
The best (maybe the only) way to compare the transfer speed is to have PacsOne and the other PACS plugged-in side by side into the same LAN switch or hub, then connect that switch/hub in whatever path to the source AE. This way, the traffic path from the source to the destination (PacsOne or the other PACS) is identical except for the last hop, which can be ignored since the latency difference among the switch/hub ports should be indistinguishable.
Solved!!
You are right, apples to apples. After investigating the machine in question, I found the other PACS provider only gives the illusion of speed. They send the images to a locally running vpn client, which of course means that EFilm sends them very quickly to the same machine. I was able to look at the queue and as expected, the actual upload times were similar to pacsone. Thanks again for the reply, but let this serve as a warning to others to make sure you really are comparing "apples to apples".