Researcher Shows How GPUs Make Terrific Network Monitors

← Back to Stories (view on slashdot.org)

Researcher Shows How GPUs Make Terrific Network Monitors

Posted by samzenpus on Thursday November 21, 2013 @05:28PM from the keeping-an-eye-on-things dept.

alphadogg writes "A network researcher at the U.S. Department of Energy's Fermi National Accelerator Laboratory has found a potential new use for graphics processing units — capturing data about network traffic in real time. GPU-based network monitors could be uniquely qualified to keep pace with all the traffic flowing through networks running at 10Gbps or more, said Fermilab's Wenji Wu. Wenji presented his work as part of a poster series of new research at the SC 2013 supercomputing conference this week in Denver."

67 comments

Min score:

Reason:

Sort:

Shut up! Just shut up! by Anonymous Coward · 2013-11-21 17:32 · Score: 0

This is just what we needed, *awesome* discovery.
You totally do not have to say everything that pops into your mind...
That's it? by drcheap · 2013-11-21 17:38 · Score: 4, Informative

So in violation of /. convention, I went ahead and read TFA in hopes that were would actually be something more than "we solved yet another parallel computing problem with GPUs." Nope, nothing. Not even some useless eye candy of a graph showing two columns of before/after processing times.
And the article just *had* to be split into two pages because it would have killed them to include that tiny boilerplate footer on page one. What a fail...at least it wasn't a blatant slashvertisement!
1. Re:That's it? by timeOday · 2013-11-21 17:50 · Score: 5, Funny
  
  They said it achieves a speedup of 17x, here is the graph:
  CPU: X GPU: XXXXXXXXXXXXXXXXX
2. Re:That's it? by Anonymous Coward · 2013-11-21 18:18 · Score: 1
  
  I don't think you understand how hyperthreading works.
  It doesn't let it do twice as many tasks simultaniously, it just lets it work on another task when it would otherwise be idle while waiting for some other hardware to do something.
3. Re:That's it? by Anonymous Coward · 2013-11-21 18:21 · Score: 0
  
  I was expecting exploiting PCIe's full access to physical memory and CPU caches (Yah for lack of IOMMU and thus non-virtualized DMA!). Your GPU can snoop your network data right off the CPU cache your NIC DMAs it into, and then put its analysis right back into the NIC to go out to some destination. Its fully possible to sniff traffic (and anything else in RAM) and broadcast the results without touching the CPU. Fire-wire and thunderbolt externals can do this as well, and is perhaps much more worrying.
  I was hoping for an interesting note about our horrible lack of security. I got nothing interesting. Why Intel disables the IOMMU in the K series processors is a mystery to me, but thats another story.
4. Re: That's it? by Anonymous Coward · 2013-11-21 19:14 · Score: 0
  
  I do know how it works and for some workloads it does effectively approach double the execution throughput. Sometimes though it causes cache thrashing and can actually reduce throughput.
5. Re:That's it? by VTBlue · 2013-11-21 19:40 · Score: 1
  
  A speedup of 17x over a single core. Using an 8 core Xeon (16 threads with hyperthreading) would give a similar speedup.
  From the two-page report: "When compared to a 6-core CPU (m-cpu), the speedup ratios range from 1.54 to 3.20."
  so yeah, the 17x is misleading because what network monitoring load would run on a single core?
6. Re:That's it? by Anonymous Coward · 2013-11-21 19:58 · Score: 0
  
  What a fail...at least it wasn't a blatant slashvertisement!
  It was a blatant NSA-related-government-grant-advertisement. For crap of that kind, the gubmint always has some petty cash handy, because terrists and Nashville segwity.
7. Re:That's it? by edibobb · 2013-11-21 20:01 · Score: 1
  
  In defense of the researcher (and not the author of the article), it was just a poster presented at a conference, not a published paper.
8. Re:That's it? by Anonymous Coward · 2013-11-21 20:28 · Score: 0
  
  Because IOMMU is desirable in server environments, and we want you to buy bigger beefier CPUs for your server rather than using the huge OCs you can achieve.
9. Re:That's it? by Anonymous Coward · 2013-11-21 20:31 · Score: 0
  
  Yes, and they used a tesla M2070 which has 448 cores on 40nm process, which offers less than a 14% the performance of nvidia's most recent offerings.
  If you want a less misleading comparison, try some more relevant metrics like power consumption or transistor count per performance unit over both architectures.
10. Re: That's it? by Anonymous Coward · 2013-11-21 20:32 · Score: 1
  
  lol wut? name *one* (real-world) workload where you get double the execution throughput.
11. Re:That's it? by NothingMore · 2013-11-21 20:50 · Score: 4, Informative
  
  I saw this poster at the conference and I was not impressed and in fact it was one of the weaker posters that I saw at the conference (it was light on details and had some of the information on the poster when talking about GPU's in general was not entirely accurate). It is really a poster that should not have been at SC at all. While it is interesting in the network sense the amount of data they can process is not anywhere close to the amount that is actually flowing through these large scale machines (up to 10 GB/sec per node) and there was no information about scaling this data collection (which would be needed at extreme scales) to obtain meaningful information to allow for tuning of network performance.
  This poster should have been at a networking conference where the results would have been much more interesting to the crowd attending. Also of note, IIRC the author was using a traditional GPU programming model for computation that is not efficient for this style of computation. The speedup numbers would have been greatly improved by using a RPC style model of programming for the GPU (persistent kernel with tasking from pinned pages). However this is not something I totally fault the author for not using since it is a rather obscure programming technique for GPU's at this time.
12. Re:That's it? by Anonymous Coward · 2013-11-21 21:10 · Score: 0
  
  And the article just *had* to be split into two pages because it would have killed them to include that tiny boilerplate footer on page one. What a fail...at least it wasn't a blatant slashvertisement!
  It's called browser real estate and someone has got to pay for it. Not you with that attitude it seems
13. Re:That's it? by TeXMaster · 2013-11-21 21:53 · Score: 5, Informative
  
  Yeah but with this kind of applications the real bottleneck is the fact that the discrete GPU needs to access data through the high-latency, low-bandwidth PCIe bus. For this kind of application, an IGP, even with the lower core counts, is often a much better solution, unless you manage to fully cover the host-device-host transfers with computations.
  I'd be really curious to see this thing done in OpenCL on a recent AMD APU, exploting all the CPU cores and the IGP cores concurrently.
  
  --
  "I'm never quite so stupid as when I'm being smart" (Linus van Pelt)
14. Re: That's it? by Anonymous Coward · 2013-11-21 22:12 · Score: 0
  
  one instruction memory I/O, the other computational SMID instruction. Both of those will execute in parallel t full speed without blocking each other (assuming that you have already loaded your data into the registers)
15. Re: That's it? by Anonymous Coward · 2013-11-21 23:42 · Score: 0
  
  MIPS CPUs that timeslice between the hyperthreads on a per-cycle basis anyway ...
16. Re: That's it? by loufoque · 2013-11-21 23:46 · Score: 1
  
  A Xeon also has SIMD, which gives a speed-up of 8.
17. Re:That's it? by solidraven · 2013-11-22 01:03 · Score: 1
  
  He also has no clue about ASICs, lets take a look at this line: "Nor do they offer the ability to split processing duties into parallel tasks,"
  If there is one thing you can do on an ASIC, it's parallelisation. Application specific cores are small, very small, standard multi-project wafer run technologies have a good number of metal layers so routing isn't too problematic, etc. So you can actually fit a whole lot of cores on a small silicon area in a modern technology. The main issue is the cost of the hardware designer, EEs sufficiently skilled in HDL to take on such a large project are an expensive commodity.
18. Re:That's it? by Anonymous Coward · 2013-11-22 01:14 · Score: 0
  
  I wish I didn't spend my last points on some hyperthreading discusion above. What TeXMaster said.
19. Re:That's it? by Anonymous Coward · 2013-11-22 01:19 · Score: 0
  
  Most OSs(Windows, Linux, *BSD) create a new memory allocation for each packet. It may be hard for your GPU to sniff traffic without help from the OS if each data packet could potential be anywhere in memory. A better zero-copy network stack in coming to FreeBSD and is being ported to Linux. Because of the zero-copy nature, the data is all in well defined places.
20. Re:That's it? by hairyfeet · 2013-11-22 01:21 · Score: 2
  
  But at what cost? The power of the high end GPUs like the top Tesla units are frankly insane while the power of both AMD and Intel CPUs has been going down. Last I checked those top o the line GPUs sucked so much juice you could probably run a 32 core Intel and still use less juice and require less cooling.
  
  --
  ACs don't waste your time replying, your posts are never seen by me.
21. Re: That's it? by KingMotley · 2013-11-22 04:05 · Score: 1
  
  That isn't a real world workload. I typically see 10-30% increase from hyperthreading, which isn't nothing, but it's not a 100% speed bump either.
22. Re:That's it? by Anonymous Coward · 2013-11-22 04:17 · Score: 0
  
  The power of the... top Tesla units [is] frankly insane...
  
  And prone to catch fire if you look at them funny
23. Re: That's it? by Anonymous Coward · 2013-11-22 04:34 · Score: 0
  
  That isn't a real world workload. I typically see 10-30% increase from hyperthreading, which isn't nothing, but it's not a 100% speed bump either.
  ^ THIS
  OP obviously decided to "baffle with bullshit" rather than honestly reply (doesn't work so good on this forum)
24. Re:That's it? by gentryx · 2013-11-22 04:46 · Score: 1
  
  However this is not something I totally fault the author for not using since it is a rather obscure programming technique for GPU's at this time.
  Good point. I guess this will change once Kepler GPUs are widely adopted and CUDA 6.0 is published: With Kepler you can spawn Kernels from within the GPU and unified virtual addressing will make it easier to push complex data structures into the GPU (according to the poster these appears to be some preprocessing happening on the CPU).
  
  --
  Computer simulation made easy -- LibGeoDecomp
25. Re:That's it? by Anonymous Coward · 2013-11-22 06:04 · Score: 1
  
  As a PhD in computer networking, I'll tell you, it would have been easy to publish on SC, than other reputable networking conferences. This article to me is non news.
26. Re: That's it? by Anonymous Coward · 2013-11-22 06:22 · Score: 0
  
  Mining Bitcoins, I see 3.8Mh/sec using all 8 (virtual) cores, vs 2.2 using only the 4 physical cores. Is this not hyperthreading?
The Poster PDF by Ayrezyle · 2013-11-21 18:07 · Score: 1

http://sc13.supercomputing.org/sites/default/files/PostersArchive/post161.html
not new by postmortem · 2013-11-21 18:07 · Score: 2

NSA already does this, how else you think they process all that data?
1. Re:not new by Anonymous Coward · 2013-11-21 18:15 · Score: 1
  
  millions of gnomes!
2. Re:not new by Anonymous Coward · 2013-11-21 18:22 · Score: 1
  
  Field programmable gnome arrays are going to be the next big thing in computing.
3. Re:not new by jovius · 2013-11-21 18:24 · Score: 1
  
  With a pinch of salt?
4. Re:not new by Anonymous Coward · 2013-11-21 18:46 · Score: 0
  
  NSA already does this, how else you think they process all that data?
  Alien technology, acquired from a brief alliance with the Greys.
5. Re:not new by bob_super · 2013-11-21 20:15 · Score: 1
  
  They don't "process" it.
  "Processing" is bad, it's like "collecting".
  They don't collect or process, they just "store" it. Nothing to worry about citizen. Move along, now.
6. Re:not new by JustOK · 2013-11-21 23:19 · Score: 2
  
  Fuck that. If I have to go into a field to program the gnome arrays, I'm not doing it.
  
  --
  rewriting history since 2109
7. Re:not new by VortexCortex · 2013-11-22 02:16 · Score: 1
  
  Thus the old system was abandoned, and Gnome3 was born.
8. Re:not new by KingMotley · 2013-11-22 04:09 · Score: 1
  
  Distributed cluster of lawn gnomes.
9. Re:not new by Anonymous Coward · 2013-11-22 06:24 · Score: 0
  
  Principally, in software, with this: http://www.narus.com/
  They used to use Cell processors, now they use normal CPUs, and for the fast paths they use GPUs, FPGAs and some custom ASICs.
  For the "full-take feeds" they just flat-out grab everything and search through it later using Hadoop.
10. Re:not new by Anonymous Coward · 2013-11-22 07:50 · Score: 0
  
  I have integrated Intel GPU. Take that, NSA! Ha Ha!
11. Re:not new by Anonymous Coward · 2013-11-23 11:40 · Score: 0
  
  [Citation needed]
wishful thinking by Anonymous Coward · 2013-11-21 18:23 · Score: 1, Insightful

"Compared to a single core CPU-based network monitor, the GPU-based system was able to speed performance by as much as 17 times"
Shouldn't "researchers" know better how to execute benchmarks in such a way that a comparison between a CPU and a GPU actually makes sense and is not misleading? Why didn't they compare it to a 12 or 16 core CPU to show that it is only marginally better and requires programming in OpenCL or CUDA? Why didn't they take a 2P system and show that it is actually performing worse? In that case they could have drawn the correct conclusion that it actually makes no sense to use GPUs for this purpose! It is sad that even among Fermilab researchers wishful thinking bends results.
1. Re:wishful thinking by Anonymous Coward · 2013-11-21 19:32 · Score: 1
  
  Shouldn't "researchers" know better how to execute benchmarks in such a way that a comparison between a CPU and a GPU actually makes sense and is not misleading?
  If the goal is hard science, then that would make sense. But when the goal is to wow the press, grab attention, and whore in the media, then no... that would be the opposite of what you'd want.
2. Re:wishful thinking by Guy+Harris · 2013-11-21 20:40 · Score: 1
  
  Why didn't they compare it to a 12 or 16 core CPU to show that it is only marginally better and requires programming in OpenCL or CUDA?
  "Compared to a six core CPU, the speed up from using a GPU was threefold." If the 12-core CPU is twice as fast, that's 1.5x, and for a 16-core, that's 1.12x.
3. Re:wishful thinking by Anonymous Coward · 2013-11-21 23:46 · Score: 0
  
  That's not the "correct" conclusion. The correct conclusion relies on a cost-benefit analysis of not only coding time, but also number of 16-core CPUs you have to buy (yeah, real low end of the market, those) compared to how much GPU metal you need, across however many nodes you want, and the consequent energy usage and cooling costs.
  The result is: if you want to do this, this is how fast it is. If you already have a 16-core CPU in your desktop at home and you want to play network monitor then of course it makes more sense to code in C on your own machine, but that's not what "researchers" are usually interested in.
4. Re: wishful thinking by loufoque · 2013-11-21 23:56 · Score: 2
  
  In practice, most people who publish results of a new algorithm ported to GPU do not have a version well-optimized for CPU, or aren't that good at optimization in the first place. I've had several cases where I could make the CPU version faster than their GPU version, despite them having claimed a x200 speed-up with the GPU.
  If you have a fairly normal algorithm in terms of data access and your speed-up is bigger than 4, you're probably doing it wrong.
GPU replaces CPU by harshal.tawade · 2013-11-21 18:52 · Score: 0

Now I think, I should buy a GPU only and no need to spend money on CPU. Going to save some money.
1. Re:GPU replaces CPU by gl4ss · 2013-11-21 19:35 · Score: 1
  
  yeah so you'd be buying a cpu?
  msg me when someone writes an os for it.
  pyramid3d? blast from the past?
  
  --
  world was created 5 seconds before this post as it is.
Talk URL by TheSync · 2013-11-21 18:57 · Score: 1

Here is a URL to a presentation on the issue of GPU-Based Network Monitoring.
BTW, with PF_RING and a DMA-enabled NIC driver (PF_RING DNA), one should have no problems capturing 10 Gbps on a single CPU modern server. I can capture/playback 4.5 Gbps no problem using this with four 10kRPM HDDs - 8 drives should give you 10 Gbps rate capture/playback.
1. Re:Talk URL by Anonymous Coward · 2013-11-21 19:57 · Score: 0
  
  is it cheaper?
2. Re:Talk URL by cez · 2013-11-22 03:15 · Score: 1
  
  I just demo'd Fluke Networks's TruView system that does 10Gb/s stream to disk, 24 TB array of 26 1TB hard drives... was very nice, not cheap though. 2 Xenon 16 Core CPUs if memory servers and a whole crap load of pretty analysis and correlations between Netflow & SNMP data... scary cool with the VOIP module.
  
  --
  Walk with Music;
Network Processors ? by Anonymous Coward · 2013-11-21 19:25 · Score: 0

What about network processors ? They usually have an ARM CPU for the control plane, and a large number of custom processing units for the data plane. That's what this solution should be compared to, not a standard x86 CPU!
1. Re:Network Processors ? by Shatrat · 2013-11-22 02:53 · Score: 1
  
  You can't buy a custom ASIC off the shelf at Fry's, but you can buy a CPU or a GPU. I don't think it's an apples to apples comparison if you throw in custom hardware.
  
  --
  09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
GPU keylogger by Anonymous Coward · 2013-11-21 19:29 · Score: 0

http://www.cs.columbia.edu/~mikepo/papers/gpukeylogger.eurosec13.pdf
a lot more if you just Google...
Aaaand now we're buying Big Brother off-the-shelf. by Anonymous Coward · 2013-11-21 19:36 · Score: 0

I have always told my friends and family that PC gamers and the drive for faster gaming rigs led to the computer and microprocessor revolution of the 90s and early 2000s. I told them gamers saved the world.
Now we have apparently doomed it as well.
Well..... it was fun while it lasted.
Link to the full paper by mkaushik · 2013-11-21 20:06 · Score: 1

http://lss.fnal.gov/archive/2013/conf/fermilab-conf-13-035-cd.pdf
They're using M2070 (Fermi) GPUs. Kepler would perform even better, the latest one has > 6GB of memory.
Sorry, but ... (wrong tool for the job) by Ihlosi · 2013-11-21 21:12 · Score: 2

... the main task of GPUs is floating point calculations, and I doubt you need many of those when monitoring networks. Wrong tool for the job.
It's like saying that GPUs are "terrific" for Bitcoin mining, until you realize that they require one or more orders of magnitude more power for the same amount of processing than specialized hardware. And network monitoring is probably a common enough task that it's worthwhile to use hardware tailored to this particular job.
1. Re:Sorry, but ... (wrong tool for the job) by Anonymous Coward · 2013-11-21 23:51 · Score: 0
  
  No they're probably using all those well-known statistical methods that work in the integer field.
2. Re:Sorry, but ... (wrong tool for the job) by Anonymous Coward · 2013-11-22 00:47 · Score: 0
  
  If you wanted to calculate SNMP statistics then having floating-point helps. This is the most compute intensive part of network monitoring. Your packets coming whizzing in as simple 1D arrays of bytes (stored by the network card as a ring buffer), but the actual statistics calculations for source, destination, packet size, protocol, packet type fields are random access and involve hash bucket indexing, floating point value calculations for time, averages, minimum and maximum values.
  The RFC (Request For Comments) documents describe these in detail. They are the network industries equivalent to OpenGL extension specifications:
  http://tools.ietf.org/html/rfc1757
  http://tools.ietf.org/html/rfc4898
  SNMP organises statistics into tables (like texture arrays) and you can have tables of tables (like arrays of arrays). These would be built up automatically as time progressed, and eventually you would have a whole hierarchical tree of data. This would be replicated across entire networks and be retrievable by any remote client if it had permission (much like GLX).
I'd like a regex computing device by Anonymous Coward · 2013-11-21 21:16 · Score: 0

I'd like specialized hardware for regex on large amounts of data.
1. Re:I'd like a regex computing device by Ihlosi · 2013-11-21 21:36 · Score: 2
  
  Get an FPGA development system and implement your hardware in the FPGA, then ask a chip manufacturer to turn it into an ASIC. Expect to pay bucketloads of money on the way, though. It's only feasible if either costs are not an issue or you expect the resulting device to be mass-proced (six or better yet seven digit numbers manufactured per yeat).
2. Re:I'd like a regex computing device by Anonymous Coward · 2013-11-21 22:48 · Score: 0
  
  I believe some Freescale QorIQ (Power based) have this kind of engine running in parallel with the core.
In Soviet Russia, your TV watches YOU! by Thor+Ablestar · 2013-11-21 21:30 · Score: 1

As I understand, there are at least 2 purposes for monitoring the network: debugging and spying. I believe that due debugging is already built-in. But spying is a concern, especially since the Russian authorities have required the ISPs to preserve ALL data traffic in their network for 12 hours for further investigation. What about NSA?
... and NICs will make great GPUs too by Anonymous Coward · 2013-11-21 22:21 · Score: 0

In the other news researcher shows how Network Gear makes terrific GPUs!
US vendors like Cicso (due to the NSA cleverness) seriously consider entering the gaming business now.
And all NICs from now on, in addition to the new (whistling) blower will feature HDMI and display ports as well.
Re:Aaaand now we're buying Big Brother off-the-she by jones_supa · 2013-11-22 03:38 · Score: 1

Not so fast, buddy-boy. We still have positive efforts like Folding@home which tap the power of GPUs.
Breaking news by viperidaenz · 2013-11-23 07:58 · Score: 1

massively parallel system is suited to massively parallel tasks.