Live data from Hacker News

A Desperate Plea for a Free Software Alternative to Aspera (2018)

ccdatalab.org

41–50 of 172 posts

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#41
The 'proof' shown that aspera is 200x faster shows an ETA of 2:15 compared to 00:09. First of all, this is 15x faster, not 200.

I tried downloading the file using axel -n 32, and it took 1:28, which is only 9x slower. Curious though, when it started out with all threads running it was transferring data at 29594.2KB/s and hit 50% after only a few seconds, but by the end with only a few threads left running it was only doing 5625.8KB/s.

It looks like the performance varies a lot, possibly due to multiple interfaces or wan links being used.. or issues with their server.

Using axel -n 64 over http I was able to fetch it in 50s, which is only 5x slower, and most of that time was spent from 98 to 100% as the last few connections finally finished.

A smarter client that more aggressively re-fetched chunks being downloaded over slow connections would likely match the same performance.

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#44
Ex Aspera Dev here. I did the encryption and early parallel work.

There is a lot of good science behind fasp. An advantage it has over IETF protocols is that both ends trust one another. Another advantage, until recently, was out-of-order delivery.

The protocol totally ignores drops, for flow control. Instead, it measures change in transit time. The receiver knows, the sender needs to know, but the useful lifetime of the measurement is less than the transit time. This should make an engineer think "control theory!", and did. So, the receiver reports a stream of transit time samples back to the sender, which feeds them into a predictor, which controls transmission rate. Simple, in principle, but the wide Internet is full of surprises.

If you think this wouldn't be able to go a thousand times faster than TCP, you have never tried moving a file to China or India over TCP. :-) (Customers used to report 5% drop rates.) Drops and high RTT are devastating to traditional TCP throughput on high-packet-rate routes; read about "slow-start" sometime, and do the math. Problem is that for untrusted peers, drops are the only trustworthy signal of congestion. Recent improvements where routers tag packets to say "I was really, really tempted to drop this!" help some.

Torrents get the out-of-order delivery and the lower sensitivity to drops, but its blocks are too big.. Others commented that opening lots of connections gets around some TCP bottlenecks, but that helps much only when the drop rate isn't too high (i.e. not to India or China).

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#45

Why not use torrents over wireguard? From an engineering perspective I'd personally be hard pressed to come up with a more optimal solution for private big data transfer. If Aspera is as good as the parent suggests it's probably because they are operating a bittorrent-like network of geo-distributed peers. It would be very cheap to emulate that using cloud computing providers, especially if you are discarding the dat…

Aspera uses multiple UDP streams to push data. The special sauce is measuring the packet loss quickly enough to make sure your not over saturating the link Apart from that, its a fairly simple protocol.

Maybe you could make your own special sauce by tweaking LEDBAT [1]. There’s an open source implementation in uTP.

[1] https://en.m.wikipedia.org/wiki/LEDBAT

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#46
post #12

Have you tried https://github.com/openrq-team/OpenRQ or https://github.com/harmony-one/go-raptorq or https://github.com/cberner/raptorq (the last seems to have excellent decoding/encoding performance)? (Raptor codes (a type of FEC) can essentially transfer over UDP at the underlying line rate, even if packet drop is high . In other words, if it is a 1 gbit/s link, with 5% packet loss, you will be able to send over 90…

You don't need 5% packet loss on a high latency 1Gbps link to trash performance. Even .1% packet loss is enough to cut throughput massively on long fat networks (LFNs).

Erasure coding helps, but it demands much more CPU than simply having a very wide window for retransmits. For bulk data transfer of files, retransmitting any part of a 1GB window is trivial.

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#47

I think this lists some alternatives... https://www.chpc.utah.edu/documentation/data_services.php I'm curious. How fast are these compared to netcat/socat/mbuffer?

It mentions rclone with the parallel option of "--transfers=N". I wonder how well that does.

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#48
post #20

There are other wan accelerators out there - like Riverbed. But, I think Aspera uses some specialized compression for genomics data, and genomics compression is not easy. My suggestion would be to talk to the telco that provides your wan. If you are using a direct internet connection my suggestion would be : don't.

Riverbed always stank.

Aspera never did in-flight compression when I was there. In-flight compression got even less interesting around 2010 when the long fiber links got faster than customers' (shared) storage systems. Users have good reasons to compress at rest, before starting a transfer.

Re: A Desperate Plea for a Free Software Alternative to Aspera (2018)

#50
post #9
post #6

I have seen this software before. I suppose the speed boost results from using multiple parallel connections, meaning it could make better use of aggregate links and multipath networks? Is there anything else to it?

It does what it says and it’s expensive. There’s a couple of commercial packages like this - two that come to mind are vcinity and Signiant. A solution can be made but every time I look at the market you find very few customers with a real need to move terabytes that can’t solve their problem with a snowball-style solution. Those that do usually also have the economics to justify a commercial package.

Don't know about vcinity, but Signiant was always a marketing-heavy, engineering-light organization. Their focus was on user convenience features, and they almost ignored actual transit engineering.
Post reply on HN