Slicer binary download is extremely slow

I started it about 20 min ago, and it gets slower and slower. Downloading from BWH on a wired connection. As I am writing this, the bandwidth dropped further to 3.5 Kb/s.

image

After I wrote the initial message, I checked the bandwidth on the connection, and it hovers under 10 Mbps, which is low. Perhaps something else is going on here.

I’ve tried downloading Slicer now. Both the stable and nightly versions downloaded in about 45 seconds.

Downloading at home right now takes less then a minute.

Sounds like a BWH network problem.

–Mike

I believe there is some kind of anti-virus or other scanner on the BWH firewall that gets very bogged down with big downloads.

For comparison, is this download fast on BWH network ?
See https://github.com/Slicer/Slicer/releases/download/v4.5.0-1/Slicer-4.5.0-1-linux-amd64.tar.gz

Download of the nightly from Midas: 5m51s total time (today it is much faster!) ← total download size 179M (effective bw 0.5 MB/s)
Download of the stable from GitHub: 2m41s total time ← total download size 255M ( effective bw 1.59 MB/s)

So GitHub download (apparently served from Amazon) is over 3 times faster than download from Kitware, as measured on the internal BWH network, as of today.

Not that I have any objection to github, but just to note that the github download is served over https, so it may not be directly comparable – if scanning Steve mentioned is the issue, it is unlikely to be happening for an https download. From Andras message it sounds like Kitware-hosted downloads are fast elsewhere, which has also been my experience when downloading at home.

I just downloaded the nightly in about 50 seconds. It may be related to some setting on your machine or in your network.

@ihnorton IMHO, for a user downloading Slicer, I believe time is very directly comparable.

Anyway, I just reported the times to respond to @jcfr request.

Few points to note though:

  • the firewall issue at Partners is hardly unique, and will be common in the hospitals, companies, and other restricted environments. But indeed I have no data to prove or disprove how common this issue is in firewalled locations.
  • arguably, many of our users are operating from such closed environments, and those are the users we should aspire to keep happy.

@cpinter it may indeed be unique to my machine or network, but I have not changed anything I can think of recently, and have no interest or time to contact hospital IT and explain what is going on, and why it is important for them to debug this issue.

I’ve logged the issue with Partners. Partners antivirus scanning has been upgraded since the recently ransomware attacks, so that might be the cause (and not surprisingly so).

–Mike