SoylentNews is people
SoylentNews
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.
(Score: 4, Informative) by RedBear on Saturday August 01 2015, @09:08PM
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
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.
When the dust settled America realized it was saved by a porn star.
(Score: 3, Interesting) by RedBear on Saturday August 01 2015, @11:14PM
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
So you think =)
(Score: 2) by RedBear on Thursday August 06 2015, @03:20AM
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
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...