diffserv

7 ms·

1.
by diffserv 3y ago
Thanks for bringing this up! It was a good reminder for me to donate. May he rest in peace.
2.
by diffserv 5y ago
A few quick thoughts---I stayed around for 3-4 mins so please read this from the perspective of a (techy) user didn't explore much: The good: The UI is simple and clean. Definitely feels like something that you can start with. The bad
3.
by diffserv 5y ago
WHO's responsibility is not to a single person. Their policies are designed for the society as a whole. Minimizing the possibility of infection for critical jobs is much more valuable than minimizing the infection probability to a si
4.
by diffserv 6y ago
This. And one of the main reasons that the paper from Google are routinely of high caliber is due to the internal review processes and your peers. Publishing a piece of work for the sake of publishing by ignoring the processes that are put
5.
by diffserv 6y ago
The statement that "Academic debate is, in fact, done through conferences and journals" is not strictly true. Specially given that a lot of reviews in more popular conference are very hit and miss. You can submit the same paper
6.
by diffserv 7y ago
Can you expand on the the privacy implications? How is this different than picking up the phone and having your convo go through ATT/Verizon networks? or using your ISP? Both parties can "legally" work with authorities to wi
7.
by diffserv 7y ago
Do you have numbers or papers that support your argument? That these applications are bottlenecked by the network? There is a 2015 paper [1] that argues that improving network performance isn't gonna help MapReduce/data analytics
8.
by diffserv 7y ago
I am genuinely curious to see what types of "compute-intensive" applications fit the bill here. Outside of storage workloads (syncing data, etc.), why would you need a 100x improvement in data transfer rates between the machines?
9.
by diffserv 7y ago
> I could ask them to go look up papers in Oakland, CCS and NDSS over the last couple of years and see if anything catches their fancy. Isn't this exactly the major thing that is wrong with research today? Limiting work/creati
10.
by diffserv 7y ago
You are assuming that everybody in this system is honest: researchers, funders, and companies. None of these entities need to be honest to do research or to come up with topics. This is a big fallacy with academic research: nobody needs t
11.
by diffserv 7y ago
Unpopular opinion, but they aren't that far off with regards to academia. Academia has little scientific agenda at its core—most things boil down to money. If you want to make a case for your idea on any topic, put money on that topic
12.
by diffserv 8y ago
Thanks for the answers: 1) Are you using or relying on DMA or SPDK to copy packet data? A single core, to my understanding, (assuming 10 concurrent cache lines in flight and 70~90ns of memory access time) doesn't have the bandwidth to
13.
by diffserv 8y ago
I completely agree with your observation. It's not that the Ph.D. prepares you for it, but that most people that pursue Ph.D. have that attribute. I don't think all Ph.D. students or any ordinary engineer can take a vaguely defin
14.
by diffserv 8y ago
Hey, Anuj. Your repo is really nice for an academic paper. Thank you for that. It's rare to see a "networked system's" repositories that has readable code. I mainly checked large-tput example: A few questions— 1) For
15.
by diffserv 8y ago
Just to restate what I said---you cannot use this in its current state in production (or industry), ever. And by the time it becomes useful, it becomes a natural solution because the infrastructure supports it. Every person that works on k
16.
by diffserv 8y ago
That is hardly the state of the art: they are basically sacrificing all abstractions that are rightly so required in the name of speed. This is no different than using vanilla DPDK with no congestion and flow control and being able to pro
17.
by diffserv 8y ago
> Instead, we see a thriving software industry that largely ignores research, and a research community that writes papers rather than software. I have actively followed the NSDI and SIGCOMM community, and this is, for the most part, true