Skip navigation
All Places > Cloud Solutions > Blog

Cloud Solutions

7 posts

A pathologist’s report after reviewing a patient’s biological tissue samples is often the gold standard in the diagnosis of many diseases. For cancer in particular, a pathologist’s diagnosis has a profound impact on a patient’s therapy. The reviewing of pathology slides is a very complex task, requiring years of training to gain the expertise and experience to do well.

Even with this extensive training, there can be substantial variability in the diagnoses given by different pathologists for the same patient, which can lead to misdiagnoses. For example, agreement in diagnosis for some forms of breast cancer can be as low as 48 per cent, and similarly low for prostate cancer. The lack of agreement is not surprising given the massive amount of information that must be reviewed in order to make an accurate diagnosis. Pathologists are responsible for reviewing all the biological tissues visible on a slide. However, there can be many slides per patient, each of which is 10+ gigapixels when digitized at 40X magnification. Imagine having to go through a thousand 10 megapixel (MP) photos, and having to be responsible for every pixel. Needless to say, this is a lot of data to cover, and often time is limited.

To address these issues of limited time and diagnostic variability, we are investigating how deep learning can be applied to digital pathology, by creating an automated detection algorithm that can naturally complement pathologists’ workflow. We used images (graciously provided by the Radboud University Medical Center) which have also been used for the 2016 ISBI Camelyon Challenge1 to train algorithms that were optimized for localization of breast cancer that has spread (metastasized) to lymph nodes adjacent to the breast.

The results? Standard “off-the-shelf” deep learning approaches like Inception (aka GoogLeNet) worked reasonably well for both tasks, although the tumor probability prediction heatmaps produced were a bit noisy. After additional customization, including training networks to examine the image at different magnifications (much like what a pathologist does), we showed that it was possible to train a model that either matched or exceeded the performance of a pathologist who had unlimited time to examine the slides.


Left: Images from two lymph node biopsies. Middle: earlier results of our deep learning tumor detection. Right: our current results. Notice the visibly reduced noise (potential false positives) between the two versions.

In fact, the prediction heatmaps produced by the algorithm had improved so much that the localization score (FROC) for the algorithm reached 89%, which significantly exceeded the score of 73% for a pathologist with no time constraint2. We were not the only ones to see promising results, as other groups were getting scores as high as 81% with the same dataset. Even more exciting for us was that our model generalized very well, even to images that were acquired from a different hospital using different scanners. For full details, see our paper “Detecting Cancer Metastases on Gigapixel Pathology Images”.


A closeup of a lymph node biopsy. The tissue contains a breast cancer metastasis as well as macrophages, which look similar to tumor but are benign normal tissue. Our algorithm successfully identifies the tumor region (bright green) and is not confused by the macrophages.

While these results are promising, there are a few important caveats to consider.

  • Like most metrics, the FROC localization score is not perfect. Here, the FROC score is defined as the sensitivity (percentage of tumors detected) at a few pre-defined average false positives per slide. It is pretty rare for a pathologist to make a false positive call (mistaking normal cells as tumor). For example, the score of 73% mentioned above corresponds to a 73% sensitivity and zero false positives. By contrast, our algorithm’s sensitivity rises when more false positives are allowed. At 8 false positives per slide, our algorithms had a sensitivity of 92%.
  • These algorithms perform well for the tasks for which they are trained, but lack the breadth of knowledge and experience of human pathologists — for example, being able to detect other abnormalities that the model has not been explicitly trained to classify (e.g. inflammatory process, autoimmune disease, or other types of cancer).
  • To ensure the best clinical outcome for patients, these algorithms need to be incorporated in a way that complements the pathologist’s workflow. We envision that algorithm such as ours could improve the efficiency and consistency of pathologists. For example, pathologists could reduce their false negative rates (percentage of undetected tumors) by reviewing the top ranked predicted tumor regions including up to 8 false positive regions per slide. As another example, these algorithms could enable pathologists to easily and accurately measure tumor size, a factor that is associated with prognosis.

Training models is just the first of many steps in translating interesting research to a real product. From clinical validation to regulatory approval, much of the journey from “bench to bedside” still lies ahead — but we are off to a very promising start, and we hope by sharing our work, we will be able to accelerate progress in this space


After installing the latest Mellanox OFED (MLNX_OFED_LINUX-2.0-3.0.0) and configuring it for SR-IOV, per ophirmaor 's community post (see: Mellanox OFED Driver Installation and Configuration for SR-IOV,, I moved on to installing a KVM (Kernel-based Virtual Machine) so that I can create and run virtual machines. I happen to have a server in my lab with CentOS 6.4 so I found the following post on HowtoForge extremely useful – see: Virtualization With KVM On A CentOS 6.4 Server | HowtoForge - Linux Howtos and Tutorials ( More to come...

Written by: Paul Garrison on July 16, 2013, Nimbix Blog


Nimbix supports a variety of interconnect options ranging from our standard 1GB/s Ethernet to 56Gb/s FDR InfiniBand. As with most things one size does not fit all. Not all applications need or can benefit from InfiniBand, but for many of them there is a noticeable performance benefit. Especially HPC applications that leverage parallel processing such as climate research, molecular modeling, physical simulations, crypto analysis, geophysical research, automotive and aerospace design, financial modeling, data mining and more.


Our deployment of InfiniBand offers low-latency, high-bandwidth, high message rate, transport offload to facilitate extremely low CPU overhead, Remote Direct Memory Access (RDMA), and advanced communications offloads. It takes advantage of the world’s fastest interconnect, supporting up to 56Gb/s and extremely low application latency (as low as 1 microsecond).


So what kind of difference can InfiniBand make? Latency and bandwidth are the two most common performance parameters used in comparing between interconnects. Mellanox Technologies (A leading supplier of end-to-end InfiniBand and Ethernet interconnect solutions) has facilitated the testing of its InfiniBand solutions via the Compute Cluster Center operated by the HPC Advisory Council.


Here is a benchmark from Mellanox’s website that helps highlight the differences:



Mellanox 56Gb/s FDR IB

Intel 40Gb/s QDR IB

Intel 10GbE NetEffect NE020


6.8 GB/s

3.2 GB/s

1.1 GB/s





Message Rate

137 Million msg/sec

30 Million msg/sec

1.1 Million msg/sec


Source: Mellanox Technologies testing; Ohio State University; Intel websites


InfiniBand availability in the cloud opens up new application opportunities for customers. A great real world example is illustrated
in our recent participation in the Ubercloud HPC Experiment. Nimbix worked with Simpson Strong-Tie, Simulia Dassault Systems, DataSwing Corporation, NICE Software and Beyond CAE to leverage our InfiniBand enabled cloud infrastructure on NACC to accelerate heavy duty ABAQUS structural analysis:


The job: Cast-in-Place Mechanical Anchor Concrete Anchorage Pullout Capacity Analysis
Materials: Steel & Concrete
Procedure: 3D Nonlinear Contact, Fracture & Damage Analysis
Number of Elements: 1,626,338
Number of DOF: 1,937,301
Run time:
Single 12 core system = 29 hours 03 minutes 41 seconds
InfiniBand enabled 72 core parallel computing cluster = 05 hours 30 minutes 00 seconds


Certainly performance increase is driven by the ability to bring more processing cores to the problem, but the compute nodes must have the low latency switch interconnect provided by InfiniBand. Without it, this kind of application cannot be successfully scaled to take advantage of more compute horsepower. So the availability of InfiniBand in a high performance compute cloud opens up new application options for end users who wish to leverage available cloud resources.


In summary, not every application needs InfiniBand, but as with most things in this world options are important. That is why Nimbix offers a range of solutions around interconnection of both our NACC cluster and the custom turn-key clusters we deploy for our clients.


Credit: Nimbix Blo-

Guest blog by: Alon Harel


If your job is related to networking, be it a network admin, an R&D engineer, an architect, or any other job involving networks, it is very likely you have heard people around you (or GASP! maybe even heard yourself) express doubts about the proliferation of Software Defined Networking (SDN) and OpenFlow. How many times have you encountered skepticism about this new revolutionary concept of decoupling control and data planes and “re-inventing the wheel”? Many people used to think “this is hype; it will go away like other new technologies did, and it will never replace the traditional network protocols…” Well, if you perceive SDN/OpenFlow only as a replacement for the current network distributed protocol, these doubts may be turn out to be valid. The concept of saying “OpenFlow is here to replace the old strict protocols” is pretty much the message one gets from reading the old white papers regarding OpenFlow. These papers used to describe the primary motivation for moving to OpenFlow as the determination to introduce innovation in the control plane (that is, the ability to test and apply new forwarding schemes in the network).


This long preface is the background for the use case we present below. This use case is not about a new forwarding scheme, nor is it about re-implementing protocols; rather, it is a complementary solution for existing traditional networks. It is about adding network services in an agile way, allowing cost-efficient scalability. It is innovative and fresh and, most importantly, it could have not been done prior to the SDN era. Its simplicity and the fact that it relies on some very basic notions of OpenFlow can only spark the imagination about what can be done further using the SDN toolbox.


RADWARE’s security appliance, powered by Mellanox’s OpenFlow-enabled ConnectX®-3 adapter, brings a new value proposition to the network appliance market, demonstrating the power of SDN by enabling the addition of network services in a most efficient and scalable way.


Security and attack mitigation service is applied for pre-defined protected objects (servers) identified by their IP address. Prior to SDN, the security appliance had to be a ‘bump in the wire’ because all traffic destined for the protected objects must traverse through it. This, of course, dictates network physical topology, limited by the appliance’s port bandwidth and imposing high complexity when scale comes into play.


RADWARE’s DefenseFlow software is capable of identifying abnormal network behavior by monitoring the amount of bytes and packets of specific flows destined for the protected objects. The monitoring is performed by installing specific flows in the forwarding hardware only for the sake of counting the amount of data traversing it. Flow configuration and counter information is retrieved via standard OpenFlow primitives. The naïve approach would be to use the OpenFlow switches to accommodate the flows (counters); however, the limited resource capacity of commodity switches (mainly TCAM, which is the prime resource for OpenFlow) rules out this option. (Note that a switch may be the data path for hundreds or thousands of VMs, each with several monitored flows). Thus, the viability of the solution must come from somewhere else. Enter Mellanox’s OpenFlow-enabled ConnectX-3 SR-IOV adapter.


ConnectX-3 incorporates an embedded switch (or eSwitch) enabling VM communication to enjoy bare metal performance. The HCA driver includes OpenFlow agent software, based on the Indigo-2 open source project, which enables the eSwitch to be controlled using standard OpenFlow protocol.


Installing the flows (counters) on the edge switch (eSwitch) makes a lot of sense. First, each eSwitch is responsible only for a relatively small amount of protected objects (only those servers running on a specific host), therefore the scale obstacle becomes a non-issue. Moreover, more clever or sophisticated monitoring (for example, event generation when a threshold is crossed) can easily be added, offloading the monitoring application (DefenseFlow in this case).


You might think, “What’s new about that? We already have Open vSwitch (OVS) on the server which is OpenFlow capable.” Well, when performance is the name of the game, OVS is out and SR-IOV technology is in. While in SR-IOV mode, VM communication is performed by interfacing the hardware, directly bypassing any virtual switch processing software; therefore, in this mode OVS’s OpenFlow capabilities cannot be used (as it is not part of the data path).


Let’s take a look at this practically by describing the setup and operation of the joint solution. The setup is based on standard servers equipped with Mellanox’s ConnectX-3 adapter and OpenFlow-enabled switch and with RADWARE’s DefensePro appliance and DefenseFlow software, which interacts with the Floodlight OpenFlow controller.


SDN bog iamge1.png

Figure 1 – Setup


Here’s a description of the joint solution operation, as depicted in Figure 2:

  • DefenseFlow installs the relevant flows on each ConnectX-3 adapter.
  • The security appliance does not participate in the normal data path.
  • ConnectX-3 counts traffic matching the installed flows.
  • Flow counters are retrieved from ConnectX-3.
  • Once an attack is identified, only relevant traffic is diverted to the security appliance (where it is cleared of malicious flows and inserted back toward its destination).



SDN bog iamge2.png

Figure 2 -Joint Solution


I would argue that every skeptic seeing this example use case and the added value it brings to existing network environments using these very basic OpenFlow knobs, would have to reconsider his SDN doubts…

If you are an OpenStack user or have customers with OpenStack deployments, please take 10 minutes to respond to our first User Survey or pass it along to your network. Our community has grown at an amazing rate in 2.5 years, and it’s time to better define our user base and requirements, so we can respond and advocate accordingly.


Below you’ll find a link and instructions to complete the User Survey by April 1, 2013. It takes 10 minutes. Doing so will help us better serve the OpenStack user community, facilitate communication and engagement among our users as well as uncover new OpenStack users that might be willing to tell their stories publicly.



All of the information you provide is confidential to the Foundation and will be aggregated anonymously unless you clearly indicate we can publish your organization’s logo and profile on the OpenStack User Stories page.


Make sure to tune in to the User Committee when they present the aggregate findings of this important survey at the OpenStack Summit, April 15-18, in Portland, OR. For those unable to attend, we’ll share the presentation and have a video of the session to view after the event.


Please help us promote the survey, and thank you again for your support!



Atlantic.Net is a global cloud hosting provider that offers Atlantic.Net can now offer customers more robust cloud hosting services through a reliable, adaptable infrastructure, all at a lower cost in comparison to traditional interconnect solutions.

Why Atlantic.Net Chose Mellanox

  • Price and Cost Advantage

Expensive hardware, overhead costs while scaling, as well as administrative costs can be avoided with Mellanox’s interconnect technologies and thereby reduce costs 32% per application.

  • Lower Latency and Faster Storage Access:

By utilizing the iSCSI RDMA Protocol (iSER) implemented in KVM servers over a single converged InfiniBand interconnect adapter, iSER delivers lower latency and is less complex, resulting in lower costs to the user.

  • Consolidate I/O Transparently

LAN and SAN connectivity for VMs on KVM and Atlantic.Net’s management environment is tightly integrated; allowing Atlantic.Net to transparently consolidate LAN, SAN, live migrations and other traffic.

The Bottom Line


By deploying Mellanox’s InfiniBand solution, Atlantic.Net can support high volume and high-performance requirements– on-demand – and offer a service that scales as customers’ needs change and grow. Having built a high performance, reliable and redundant storage infrastructure using off-the-shelf commodity hardware, Atlantic.Net was able to avoid purchasing expensive Fibre Channel storage arrays, saving significant capital expenses per storage system.



Written By: Eli Karpilovski, Manager, Cloud Market Development


The new open source cloud orchestration platform called OpenStack is the promise of flexible network virtualization, and network overlays are looking closer than ever. The vision of this platform is to enable the on-demand creation of many distinct networks on top of one underlying physical infrastructure in the cloud environment. The platform will support automated provisioning and management of large groups of virtual machines or compute resources, including extensive monitoring in the cloud.


There is still a lot of work to be done, as there are many concerns around the efficiency and simplicity of the management solution for the compute and storage resources. A mature solution will need to incorporate different approaches to interact within the intra-server provisioning, QoS and vNIC management. For example, by leaning on local network adapters that are capable of managing the requests utilizing OpenFlow protocol, or by using a more standard approach which is managed by the switch. Using only one method, might create performance and efficiency penalties.


Learn how Mellanox’s OpenStack solution offloads the orchestration platform from the management of individual networking elements, with the end-goal of simplifying operations of large-scale, complex infrastructures