Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday August 01 2015, @07:25PM   Printer-friendly
from the now-that-is-fast dept.

Research Scientists to Use Network ("Pacific Research Platform") Much Faster Than Internet

A series of ultra-high-speed fiber-optic cables will weave a cluster of West Coast university laboratories and supercomputer centers into a network called the Pacific Research Platform as part of a five-year $5 million dollar grant from the National Science Foundation.

The network is meant to keep pace with the vast acceleration of data collection in fields such as physics, astronomy and genetics. It will not be directly connected to the Internet, but will make it possible to move data at speeds of 10 gigabits to 100 gigabits among 10 University of California campuses and 10 other universities and research institutions in several states, tens or hundreds of times faster than is typical now.

The challenge in moving large amounts of scientific data is that the open Internet is designed for transferring small amounts of data, like web pages, said Thomas A. DeFanti, a specialist in scientific visualization at the California Institute for Telecommunications and Information Technology, or Calit2, at the University of California, San Diego. While a conventional network connection might be rated at 10 gigabits per second, in practice scientists trying to transfer large amounts of data often find that the real rate is only a fraction of that capacity.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: -1, Troll) by Anonymous Coward on Saturday August 01 2015, @08:50PM

    by Anonymous Coward on Saturday August 01 2015, @08:50PM (#216840)

    The Internet should be only for smart folk like me, without the taint of Facefuck and Twatter and Soystain.

  • (Score: 0) by Anonymous Coward on Saturday August 01 2015, @08:57PM

    by Anonymous Coward on Saturday August 01 2015, @08:57PM (#216844)

    It will not be directly connected to the Internet

    If it isn't airgapped, it is part of the internet. Hell, with the most recent security research, being airgapped is no guarantee. They can certainly try to keep traffic regulated on their segments of the internet, but these are universities.

    If I was a grad student in a lab with a 10-100gb connection to my fellow grad students, there will be torrents or FTP servers up the next weekend I have out of the lab.

    Even if I wasn't a grad, I would try very hard to get access to those fat pipes. These are universities that have no Information Assurance research program, so it would be pretty easy.

  • (Score: 4, Informative) by RedBear on Saturday August 01 2015, @09:08PM

    by RedBear (1734) on Saturday August 01 2015, @09:08PM (#216848)

    The challenge in moving large amounts of scientific data is that the open Internet is designed for transferring small amounts of data, like web pages, said Thomas A. DeFanti, a specialist in scientific visualization at the California Institute for Telecommunications and Information Technology, or Calit2, at the University of California, San Diego. While a conventional network connection might be rated at 10 gigabits per second, in practice scientists trying to transfer large amounts of data often find that the real rate is only a fraction of that capacity.

    This reminds me of the conversation around 5K or 9K Jumbo Frames and how it has basically died out amongst people with extensive networking experience. Because while it all sounded great on paper, unless you had a fully compatible implementation in every hardware device on your network and a fairly narrow set of use cases (i.e., transferring almost entirely nothing but huge files or something like that), the extra performance that was supposed to result from Jumbo Frames usage just never materialized in the real world, and frequently it even caused performance issues. Meanwhile switches and NICs got faster embedded processing and now there is no apparent advantage to Jumbo Frames. If you need more than Gigabit you go to 10-Gigabit now that it's relatively affordable. But you don't mess with Jumbo Frames.

    People keep trying to "optimize" things like packet size in networking only to come back to the table years later and say, "Well, we thought this would work great and provide a huge performance boost, but for about 37 different secondary and tertiary reasons, in real world usage it doesn't even work quite as well as doing it the old way. Here's a 500-page report detailing why it's so hard to achieve the expected results."

    By enlarging packet size you need better CRC checks which either slows down processing or requires more space in the packet, depending on the complexity of the CRC calculation. Then you have to re-send much larger packets when one gets dropped or fails the CRC check, which damages overall performance more than smaller packets would. On top of that you've sacrificed the flexibility of being able to more easily multi-plex the smaller packet sizes, which tends to introduce bottlenecks in performance if there is more than one connection involved. The only time this kind of optimization seems to provide any performance benefit at all is when you have the specific use case of transferring huge monolithic files over a dedicated connection that will never be multi-plexed with any other connection. Which is kind of the antithesis of most real-world computer usage.

    Reality is weird like that. It almost never works quite the way you expect it to. Sometimes doing the exact opposite of what seems to make sense is what actually improves performance.

    (Take with huge grain of salt. Not a certified networking expert.)

    --
    ¯\_ʕ◔.◔ʔ_/¯ LOL. I dunno. I'm just a bear.
    ... Peace out. Got bear stuff to do. 彡ʕ⌐■.■ʔ
    • (Score: 4, Interesting) by Snotnose on Saturday August 01 2015, @09:54PM

      by Snotnose (1623) on Saturday August 01 2015, @09:54PM (#216859)

      Back in the mid-90s I was consulting for a company that used a bunch of PCs to hold commercials encoded with MPEG-1. We needed to move these files around fairly often (every 10 minutes or so). As it was Linux, and both the ethernet drivers and the hardware supported larger packet sizes, I experimented with making them. Turned out making the packets up to 4.5k (largest supported) made essentially 0 difference in the transfer time.

      What finally solved out congestion problems was the introduction of network switches. Saw em at Comdex, ordered a couple, and all our congestion issues went away.

      Fun fact. We were running on '486 boxes. We tried Pentiums but they did nothing except cost more. We were I/O bound, the CPU was idling.

      --
      Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
      • (Score: 3, Interesting) by RedBear on Saturday August 01 2015, @11:14PM

        by RedBear (1734) on Saturday August 01 2015, @11:14PM (#216885)

        Back in the mid-90s I was consulting for a company that used a bunch of PCs to hold commercials encoded with MPEG-1. We needed to move these files around fairly often (every 10 minutes or so). As it was Linux, and both the ethernet drivers and the hardware supported larger packet sizes, I experimented with making them. Turned out making the packets up to 4.5k (largest supported) made essentially 0 difference in the transfer time.
        What finally solved out congestion problems was the introduction of network switches. Saw em at Comdex, ordered a couple, and all our congestion issues went away.
        Fun fact. We were running on '486 boxes. We tried Pentiums but they did nothing except cost more. We were I/O bound, the CPU was idling.

        Exactly. The switch, unlike the hub, does a tremendously better job at multiplexing packets together from different connections and isolating connections from being impacted by collisions with all the other connections on the network. Proper scheduling and multiplexing is what really lets things flow as well as they possibly can.

        What's really interesting is that 20 years later we are still basically I/O limited by the hardware we use to store data (even SSDs) rather than by the CPU or the network (although we have gone from 10-Megabit to 1-Gigabit network speeds in the meantime). You basically have to create a RAM disk in order to successfully saturate even a 1-Gigabit connection for very long. Most of the time, in practice, the only place you'll get a boost from going to 10-Gigabit is in heavily used trunk lines connecting large numbers of machines. But still, the packet size remains the same.

        Even with 100-Gigabit networking I doubt they will be able to get any reliable performance gains from increasing packet size beyond possibly a maximum of 3K (twice the current standard packet size), even though the connection is orders of magnitude faster. I wouldn't try even that except between the two 100-Gigabit endpoints, and would expect it to end up a total wash or cause a tiny decrease in performance. I have little doubt that trying to increase the packet size by an order of magnitude to 15K to match the order of magnitude speed increase would be an absolute disaster.

        I would be willing to put good money on the probability that eventually some clever mathematician will come up with a mathematical proof that says there are exponentially diminishing returns with any increase (or decrease) in packet size from what we use right now. Being able to slice digital things up into suitably small pieces seems to be one of the essential cornerstones that allows us to do anything useful with any type of digital technology, and 1.5K seems to be a sweet spot in network packet size that we really have had a hard time improving upon. And it's definitely not for lack of trying.

        (Again, not a networking expert, just interested in the field. Follow your doctor's orders regarding total salt intake.)

        --
        ¯\_ʕ◔.◔ʔ_/¯ LOL. I dunno. I'm just a bear.
        ... Peace out. Got bear stuff to do. 彡ʕ⌐■.■ʔ
        • (Score: 0, Redundant) by CyprusBlue on Sunday August 02 2015, @02:11AM

          by CyprusBlue (943) on Sunday August 02 2015, @02:11AM (#216909)

          So you think =)

          • (Score: 2) by RedBear on Thursday August 06 2015, @03:20AM

            by RedBear (1734) on Thursday August 06 2015, @03:20AM (#218935)

            I shall take that as a compliment.

            --
            ¯\_ʕ◔.◔ʔ_/¯ LOL. I dunno. I'm just a bear.
            ... Peace out. Got bear stuff to do. 彡ʕ⌐■.■ʔ
      • (Score: 0) by Anonymous Coward on Sunday August 02 2015, @04:17PM

        by Anonymous Coward on Sunday August 02 2015, @04:17PM (#217035)

        In my home network, I am using jumbo frame packet sizes of 4088 bytes where possible on wired connections. Not all of my hardware has the option; some don't do JF at all and some only allow 9000+ sizes.

        I found that the MTU of 4088, despite the fact that some hardware did not support it [those continue to use 1500) was the "sweet spot" after doing much testing. My original goal of the testing was to determine if my firewall had a bottleneck (I had modified it to some extent and wished to see how it handled the routing between different subnets across multiple interfaces, without first worrying about actual access-lists or security sorts of stuff... the firewall has to perform first, otherwise applying security just makes the performance worse...)

        What I had found is that it was difficult to come to a standard for the home network, but I got close enough and a performance boost as well. The various network cards, installed in machines of various ages and operating systems, had few common denominators, but making sure they were consistent, that the switches connecting them were configured appropriately, and that any localized bottlenecks were taken care of--I did see an improvement.

        Note that you can't expect to hit gigabit network speeds (well, over 100mbps anyway) on average on 486/pentium class hardware without a good NIC and storage that supported higher speed IO, like a RAID 5 or RAID 10 or something.

        CPU speed did make a difference; gigabit speeds do cause the CPU to become quite busy. I have seen hosts max out their CPU and drop packets when using a cheap card trying to go gigabit on an otherwise well designed network. The network is nearly always blamed...

        Thinking of your experience, I'd have to think that setting jumbo frames on a network consisting of hubs would make the performance markedly worse, so I have to believe your performance was not very good to begin with. There would be little to no buffering on such equipment and it'd rely entirely on the hosts and their nics. There were certainly some high end cards available back then (server grade gigabit cards from then can still out perform integrated nics in consumer stuff today), but jumbo frames on a hub based network? I'd think you'd have seen an improvement if you REDUCED the MTU size to something smaller... not make it bigger. So much has to be retransmitted if a big packet like that has a CRC error or collision. Adding the switches was, even without needing any facts... would be the biggest bang for your buck. Jumbo frames only add single digit percent returns (on gigabit). I couldn't imagine you being able to realize a gain on hubs due to the problems inherent in a collision domain like that.

        If you remember dial-up, which I am sure you do, think of the differences between xmodem and ymodem and jmodem and zmodem -- they all had different packet sizes, and squeezed out more CPS rates with various methods of CRC or error control. Jmodem sent larger blocks and could give a 2400bps connection something like 266cps compared to zmodem's 232 or so. xmodem was pretty crummy in comparison and ymodem was a generic 'works on most systems and was better than xmodem' ymodem-g gave you a few extra cps, but nothing like jmodem.

        But, if you had a crummy connection, a cheap uart like an 8250, or some really chintzy modem/serial cable -- basically if you looked too hard, jmodem would have issues and frustrate you.

        Not too different than jumbo frames...

  • (Score: 1) by kc on Saturday August 01 2015, @11:03PM

    by kc (5066) on Saturday August 01 2015, @11:03PM (#216878)

    The fine article did not actually mention which institutions are part of the network:

    "...Pacific Research Platform, which currently includes Caltech, CENIC, ESnet, NASA Ames Research Center and the NASA Research and Engineering Network (NREN), San Diego State University, San Diego Supercomputer Center, Stanford, UC Berkeley, UC Davis, UC Irvine, UC Los Angeles, UC Riverside, UC San Diego, UC Santa Cruz, USC, and the University of Washington."

    source; http://cenic.org/news/item/high-performance-big-science-pacific-research-platform-debuts-at-cenic-2015 [cenic.org]

    • (Score: 0) by Anonymous Coward on Sunday August 02 2015, @12:39PM

      by Anonymous Coward on Sunday August 02 2015, @12:39PM (#216991)

      ... nor does it mention that the project essentially comes down to linking [ucop.edu] the DMZ [es.net]'s [pdf] of those universities/research institutions by means of 3 existing networks: CENIC’s California Research & Education Network (CalREN [cenic.org]), the Department of Energy’s Energy Science Network (ESnet), and Pacific Wave, while separating the general usage [students & profs general applications] part from a research tier.

      The CalREN network -- at least the High Performance Research part -- runs on Cisco cat6509's in the core, Brocade's at the distribution layer. That HPR part will function as the core of this setup [see slide 24 here [cenic.org] (ppt)], which essentially comes down to linking California's research centers at 100Gbps, overlaid with a mesh of cheap ($5k - $7k/node) data transfer nodes, each equipped with 2 40Gbps NICs [slide 22, and here [es.net]], transferring data disk-to-disk at 37Gbps (probable typo in press statement [cenic.org]).

      If I interprete the slides correctly -- there's a vid which might go into more detail here [youtube.com] -- this is currently Layer 2 only, with the ambition to migrate to L3. An upscale to terabit per second speeds might be the greater ambition, if the subtitle "The bisection bandwidth of a cluster interconnect, but deployed on a 10 campus scale" on slide 3 is to be believed.

  • (Score: 0) by Anonymous Coward on Sunday August 02 2015, @04:50AM

    by Anonymous Coward on Sunday August 02 2015, @04:50AM (#216931)

    "speeds of 10 gigabits to 100 gigabits"? Those are not speeds. Those are amounts of data. A transfer rate needs to be an amount of data per unit time. This sounds like one of our ISP's nonsense (Century link, I'm thinking of your "1 gig" ads). You can do better.

    Assuming they meant per second, is this total backbone bandwidth? Is this the connection to each location? Is this the amount each location can transmit at once?

    They are saying faster than the internet, and claiming an impressive "speed" of up to 12.5 GB (100 gigabits): thats less ram than I have on hand. If they meant per second, 100 gb/s thats 1 ten-thousandth of top fiber transfer rates (1 petabit per second, source http://www.theregister.co.uk/2012/09/23/ntt_petabit_fibre/ [theregister.co.uk] ), and less than 1/1000th of average internet traffic (167 terabits per second, source https://what-if.xkcd.com/31/) [xkcd.com] not to mention peak load or even capacity.

    How the hell would anyone is that faster than the internet? If they mean actual speed, parts of the internet (microwave links) are significantly faster than fiber (light is slower in glass). I don't expect much for 5 million dollars for the network, but I do expect decent reporting from the media.

    • (Score: 0) by Anonymous Coward on Sunday August 02 2015, @12:52PM

      by Anonymous Coward on Sunday August 02 2015, @12:52PM (#216992)

      The people who actually are behind it do not claim that this is faster than the Internet -- journalist's need for spectacular semi-quote there -- they merely state that the resulting network will be qualitatively better than the commodity Internet [slide 28 here [cenic.org]]. Which is true ofcourse, for any network with a decent speed, built on leased lines and running on your own network equipment.

      As for the actual speeds, and (very) high level overview of the network structure, see my earlier reply to kc. The thing that rather surprises me is that only now they're talking about 100Gbps interconnecting these research institutions: I've participated in a 40Gbps VPLS interconnect implementation in 2009, on account of a client which was far less prestigious than Berkeley University or the San Diego Supercomputing Centre; the 100Gbps IEEE standard was released already in 2010.

    • (Score: 2) by isostatic on Sunday August 02 2015, @02:34PM

      by isostatic (365) on Sunday August 02 2015, @02:34PM (#217009) Journal

      There's your problem. Decent reporting from the media? On tech subjects in the general press?

  • (Score: 2) by joshuajon on Monday August 03 2015, @05:12PM

    by joshuajon (807) on Monday August 03 2015, @05:12PM (#217468)

    This reminds me of Internet2 [wikipedia.org]. Perhaps they should call it Internet3?